5i' 3.4 ASE for CUG service with centralized administration of CUG data 3.4.1 General 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. Two similar but different procedures are defined for CUG vali- dation 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) opera- tion is defined for each of these procedures. 3.4.2 Procedures 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 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 parame- ters, concerning the calling user. 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. 3.4.3. Operations 3.4.3.1 Description of operations 3.4.3.1.1 CUG Check 1 This operation is used between the originating exchange of a call and a dedicated point for CUG validation check of the calling user. 3.4.3.1.2 CUG Check 2 This operation is used between the terminating exchange of a call and a dedicated point for CUG validation check of the called user. Blanc H.T. [T3.730] TABLE 3/Q.730 Validation check of CUG call concerning the calling user _______________________________________________________________________________________________________________________________________ Indication from calling user Calling user class CUG call with index CUG | | A call with index CUG | | A call without index Non-CUG call _______________________________________________________________________________________________________________________________________ CUG with pref. { CUG call | ua) | uc) IC: specified CUG } { CUG call | ua) | uc) IC: specified CUG } { CUG call | ua) IC: preferential CUG } CUG call IC: preferential CUG _______________________________________________________________________________________________________________________________________ CUG without pref. { CUG call | ua) | uc) IC: specified CUG } { CUG call | ua) | uc) IC: specified CUG } Return Error cause ##62 Return Error cause ##62 _______________________________________________________________________________________________________________________________________ CUG | | AI with pref. { CUG | | A | ua) | uc) IC: specified CUG } { CUG | | A | ua) | uc) IC: specified CUG } { CUG | | A | ua) IC: preferential CUG } { CUG | | A | ub) IC: preferential CUG } _______________________________________________________________________________________________________________________________________ CUG | | AI without pref. { CUG | | A | ua) | uc) IC: specified CUG } { CUG | | A | ub) | uc) IC: specified CUG } Non-CUG call Non-CUG call _______________________________________________________________________________________________________________________________________ CUG | | AE with pref. { CUG call | ua) | uc) IC: specified CUG } { CUG | | A | ub) | uc) IC: specified CUG } { CUG | | A | ub) IC: preferential CUG } { CUG call | ub) IC: preferential CUG } _______________________________________________________________________________________________________________________________________ CUG | | AE without pref. { CUG call | ua) | uc) IC: specified CUG } { CUG | | A | ub) | uc) IC: specified CUG } Non-CUG call Return Error cause ##62 _______________________________________________________________________________________________________________________________________ No CUG Return Error cause ##50 Return Error cause ##50 Return Error cause ##50 Non-CUG call _______________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OAE Outgoing access, explicit request required OAI Outgoing access, implicit outgoing access for all calls IC Interlock code of the CUG selected Note - 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. | ua) In case of OCB (outgoing calls barred) within the CUG, Return Error with cause ##53. | ub) In case of OCB within the CUG, the call is interpreted as a non-CUG call. | uc) In the case where the specified index does not match any of the registered indices, Return Error with cause ##90. Tableau 3/Q.730 [T3.730], p. 1 Blanc H.T. [T4.730] TABLE 4/Q.730 Validation check of CUG call concerning the called user ___________________________________________________________________________________________________________________________________________________________________________________________________________ Class of called user CUG CUG | | A CUG call indication in IAM CUG match check No ICB ICB No ICB ICB | No CUG ___________________________________________________________________________________________________________________________________________________________________________________________________________ CUG with OA not allowed Match CUG call Return Error cause ##55 CUG call Return Error cause ##55 No match Return Error cause ##87 Return Error cause ##87 Return Error cause ##88 ___________________________________________________________________________________________________________________________________________________________________________________________________________ CUG with OA allowed Match CUG call Return Error cause ##55 CUG | | A call Non-CUG call No match Return Error cause ##87 Non-CUG call Non-CUG call | | | | | | | | ___________________________________________________________________________________________________________________________________________________________________________________________________________ Non-CUG - | | | | | | | | | | | Return Error cause ##87 | | | | | | | | | Non-CUG call | | | | | | | | | | Non-CUG call ___________________________________________________________________________________________________________________________________________________________________________________________________________ IA Incoming access OA Outgoing access ICB Incoming calls barred Match { The interlock code in the received IAM matches one of the CUGs to which the called user belongs. } No match { The interlock code does not match any of the CUGs to which called user belongs. } ___________________________________________________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau 4/Q.730 [T4.730], p. 2 Blanc Figure 4/Q.730, p. 3 Figure 5/Q.730, p. 4 3.4.3.2 Parameters of operations and outcomes 3.4.3.2.1 CUG Check 1 H.T. [T5.730] _______________________________________________________________________________________________________ CUG Check 1 Timer = x seconds Class = 1 Code = 00000001 _______________________________________________________________________________________________________ Parameters with Invoke Optional/ Mandatory Reference (S) _______________________________________________________________________________________________________ { CallingUserIndex CUGCallIndicator CallingPartyNumber } O M M 3.4.3.3.1 3.4.3.3.2 3.4.3.3.3 _______________________________________________________________________________________________________ Parameters with Return Result _______________________________________________________________________________________________________ { CUGInterlockCode CUGCallIndicator } M M 3.4.3.3.5 3.4.3.3.2 _______________________________________________________________________________________________________ Linked Operations _______________________________________________________________________________________________________ Not applicable _______________________________________________________________________________________________________ Errors _______________________________________________________________________________________________________ UnsuccessfulCheck 3.4.3.3.7 _______________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table [T5.730], p. CUGCheck1 OPERATION PARAMETER SEQUENCE { CallingUserIndex OPTIONAL, CUGCallIndicator, { CallingPartyNumber } RESULT SEQUENCE { CUGInterlockCode CUGCal- lIndicator } ERRORS { UnsuccessfulCheck } ::= 1 Blanc 3.4.3.2.2 CUG Check 2 H.T. [T6.730] _______________________________________________________________________________________________________ CUG Check 2 Timer = x seconds Class = 1 Code = 00000010 _______________________________________________________________________________________________________ Parameters with Invoke Optional/ Mandatory Reference (S) _______________________________________________________________________________________________________ { CUGInterlockCode CUGCallIndicator CalledPartyNumber } M M M 3.4.3.3.5 3.4.3.3.2 3.4.3.3.4 _______________________________________________________________________________________________________ Parameters with Return Result _______________________________________________________________________________________________________ { CalledUserIndex CUGCallIndicator } O M 3.4.3.3.6 3.4.3.3.2 _______________________________________________________________________________________________________ Linked Operations _______________________________________________________________________________________________________ Not applicable _______________________________________________________________________________________________________ Errors _______________________________________________________________________________________________________ UnsuccessfulCheck 3.4.3.3.7 _______________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table [T6.730], p. CUGCheck2 OPERATION PARAMETER SEQUENCE { CUGInterlockCode, CUGCallIndicator, { CalledPartyNumber } RESULT SEQUENCE { CalledUserIndex OPTIONAL, CUGCallIndi- cator } ERRORS { UnsuccessfulCheck } ::= 2 3.4.3.3 Parameter coding 3.4.3.3.1 The CallingUserIndex is the local index at the calling user to identify a particular CUG he belongs to. H.T. [T7.730] ___________________________________________________________________ CallingUserIndex Code = 10000001 ___________________________________________________________________ Contents Meaning ___________________________________________________________________ IA5 Character String { One IA5 character represents one digit of the CUG index value } ___________________________________________________________________ | | | | | | Table [T7.730], p. CallingUserIndex ::= [1] IMPLICIT LocalIndex LocalIndex ::= IA5 STRING -- The maximum number of digits is four. .bp 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. H.T. [T8.730] __________________________________________________________________ CUGCallIndicator Code = 10000010 __________________________________________________________________ Contents Meaning __________________________________________________________________ 00000000 Non-CUG call 00000001 Non-CUG call 00000010 CUG call with outgoing access 00000011 { CUG call without outgoing access } __________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table [T8.730], p. CUGCallIndicator ::= [2] IMPLICIT CallIndicator CallIndicator ::= INTEGER { NonCUGCall (0), NonCUGCall(1), outgoingAccessAllowedCUGCall (2), outgoingAccessNo- tAllowedCUGCall (3) } 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 S 3.8 of Recommendation Q.763. The code of this parameter is "10000011". 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 S 3.7 of Recommendation Q.763. The code of this parameter is "10000100". 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 S 3.13 of Recommendation Q.763. The code of this parameter is "10000101". 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 S 3.4.3.3.1. The code of this parameter is "10000110". 3.4.3.3.7 Errors H.T. [T9.730] _____________________________________________ UnsuccessfulCheck Code = 00000001 _____________________________________________ Parameters _____________________________________________ Cause 3.4.3.3.8 _____________________________________________ | | | | | | | | | | | | | | | | | | Table [T9.730], p. UnsuccessfulCheck Error PARAMETERS { Cause } ::= 1 3.4.3.3.8 The Cause indicates the reason why the CUG check is unsuccessful. H.T. [T10.730] ______________________________________________________________________________________________________ Cause Code = 10000111 ______________________________________________________________________________________________________ Contents binary (decimal) Meaning ______________________________________________________________________________________________________ 00110010 (50) { Requested facility not subscribed } 00110101 (53) { Outgoing calls barred within CUG } 00110111 (55) { Incoming calls barred within CUG } 00111110 (62) { InconsistencyInDesignatedOutgoingAccessInformationAndSubscriberClass } 01011010 (90) Non-existent CUG 01010111 (87) Called user not member of CUG 01011000 (88) Incompatible destination 01101110 (110) Inconsistency in data ______________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table [T10.730], p. Cause ::= [7] IMPLICIT CauseCode CauseCode ::= INTEGER { requestedFacilityNotSubscribed(50), out- goingCallsBarredWithinCUG(53), incomingCallsBarredWithinCUG(55), inconsistencyInDesignatedOutgoingAccessInformationAnd Subscriber- Class(62), nonExistentCUG(90), calledUserNotMemberofCUG(87), incom- patibleDestination(88), inconsistencyInData(110) } 4 General description of the Calling Line Identity Presenta- tion and Restriction service Calling Line Identification Presentation (CLIP) is a supple- mentary service offered to the called party which provides the cal- ling party's ISDN number, possibly with additional address informa- tion (i.e. sub-address), to the called party. Calling Line Identification Restriction (CLIR) is a supplemen- tary service offered to the calling party to restrict presentation of the calling party's ISDN number, possibly with additional address information (i.e. sub-address), to the called party. The stage 1 definitions for the CLIP and CLIR services are given in the Recommendation I.254 and the stage 2 service defini- tions 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-764 and Q.766. 4.1 Description of the Calling Line Identity Presentation (CLIP) service 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 Cal- ling Line Identity Restriction (CLIR) facility active [see S 4.2 below] or the complete number of the calling party is not available at the destination exchange. The Calling Line Identity (CLI) is generally the ISDN number of the calling party (with possible additional address information, i.e. sub-address) which may be provided by the network or partly by the calling party. 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). 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. 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. 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 "user provided verified and passed". 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 "network provided". 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 "network provided". The CLI sent to the called user should contain all the neces- sary 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. Information indicating that a subscriber has the user access to the CLIP facility is available in the exchange to which the sub- scriber is connected. 4.1.1 Call set-up procedure 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. 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. 4.1.1.1 The Calling Line Identity is included in the Ini- tial Address Message When the CLI is available for insertion in the IAM the sys- tematic 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. In this situation, to avoid unnecessary unsuccessful requests for the CLI, the following procedures are recommended: 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 "calling party number parameter" should not be included in the IAM. 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 "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. The CLI is sent to the called party in accordance with the user-network interface protocol. 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 param- eter that presentation is restricted. 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 Parame- ter field. 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 indica- tions set. 4.1.1.2 The Calling Line Identity is not included in the Initial Address Message 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 Informa- tion Request Indicator Parameter field bit set to the calling party address requested. 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. 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 Informa- tion Indicators Parameter Field indicating the CLI is not avail- able. 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 indica- tions set. The CLI is sent to the called party in accordance with the user-network interface protocol. In the case where the destination exchange receives the "presentation restricted" or an "address not available", in the Presentation Restriction indicator of the Information message, the calling party address is not forwarded to the called party. 4.1.1.3 Message Sequence diagrams for CLIP Figures 6/Q.730 and 7/Q.730 describe the message flows for CLIP. Figure 6/Q.730, p. Figure 7/Q.730, p. 4.2 Description of the Calling Line Identity Restriction (CLIR) service Calling Line Identification Restriction (CLIR) is a user facility offered to restrict the presentation of the Calling Line Identity to the Called Party. The Calling Line Identity (CLI) is the ISDN number of the cal- ling party possibly with additional address information. Information that a subscriber has the Calling Line Identity Restriction facility is available at the exchange to which the sub- scriber is connected. 4.2.1 Normal Case 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 Mes- sage 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. 4.2.2 Abnormal Case 4.2.2.1 Override Category within an ISDN 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). 4.2.2.2 Override Category between ISDN's When a call originates in one ISDN network and terminates in another ISDN network and CLIR is applicable, the rules and regula- tions of the destination (host) network should apply. 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 res- triction whenever CLI is available at this network. As a national option the originating network can restrict the CLI to the destination network if the CLIR is applicable. 4.2.2.3 Interworking with non-ISDN or via non-ISDN On calls to or via non-ISDN networks, it cannot be guaranteed that the CLIR indication will be carried to the destination net- work. As a national option the originating network can restrict the CLI to the destination network if CLIR is applicable. 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 regula- tions. 4.2.2.4 Restriction of Additional Address Information Any additional address information provided by the calling party, i.e. sub-address, will also be subject to the CLIR supple- mentary service as indicated in the Presentation Restriction Indi- cator in the Calling Party Number Parameter field. 4.2.2.5 Message Sequence diagrams for CLIR Figure 8/Q.730 describes the message flow for CLIR. Figure 8/Q.730, p. 4.3 Nodal signalling function SDLs for CLIP and CLIR Nodal signalling function procedures for CLIP and CLIR are described in Figures 9/Q.730 to 13/Q.730. Figure 9/Q.730, p. Figure 10/Q.730, p. Figure 11/Q.730, p. Figure 12/Q.730, p. Figure 13/Q.730, p. 4.4 Interaction of CLIP with other supplementary services 4.4.1 Calling Line Identification Restriction 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. 4.4.2 Call Forwarding If the call has been redirected the CLI presented to the user will be the originating CLI. 4.4.3 Call Waiting No interaction. 4.4.4 Closed User Group No interaction. 4.4.5 Direct Dialling In No interaction. 4.4.6 User to User Information No interaction. 4.5 Interaction of CLIR with other supplementary services 4.5.1 Calling Line Identification Presentation Calling Line Identification Restriction will take precedence over Calling Line Identification Presentation. 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. 4.5.2 Call Forwarding If the call has been re-directed the CLI presented to the user will be the originating CLI. When Calling Line Identification Res- triction is applicable and activated, the calling party's ISDN number will not be presented to the "forwarded to" user unless this user has an override category. The latter is a national option. 4.5.3 Call Waiting When Calling Line Identification Restriction is applicable and activated, no number will be presented to a called user subscribing to Call Waiting. 4.5.4 Closed User Group It is an option to allow invocation of Calling Line Identifi- cation Restriction in connection with a CUG call. 4.5.5 Direct Dailling In No interaction. 4.5.6 User to User Information No interaction. 5 Direct Dialling In (DDI) 5.1 Definitions Direct Dialling In (DDI) 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. The stage 1 definition of DDI is to be found in Recommendation I.251, S A. The stage 2 description is included in Recommendation Q.81, S 1. This stage 3 description of DDI compli- ments the ISDN User Part protocol as defined in Recommendations Q.761-Q.764 and Q.766. 5.2 Procedures 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. 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. 5.2.1 Analogue PABX 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 "no indication". 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 "no indication" or "subscriber free" according to the signal received from the PABX. 5.2.2 ISDN PABX 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 "no indication". 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 "no indication". On receipt of an "alerting" indication from the PABX the des- tination local exchange sends a Call Progress Message with the Called Line Status set to "subscriber free". If tones and/or announcements are provided from the destina- tion 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 indica- tion 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. 5.3 Interactions with sub-addressing The use of DDI has no impact on the use of sub-addressing and vice versa. 6 Call Forwarding services 6.1 General description of Call Forwarding services The Call Forwarding services involve the redirection of a call originally intended for one destination, towards another destina- tion. The stage 1 definitions for the Call Forwarding services are given in Recommendation I.252 and the stage 2 descriptions are con- tained in Recommendation Q.82, S 2. 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 con- tained in Recommendations Q.761-764 and Q.766. This section does not cover the optional validation procedure of Recommendation I.252. One possible method of performing this vali- dation is to use a courtesy call at call forwarding activation time. 6.2 Definition of Call Forwarding services The Call Forwarding Unconditional service 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. The Call Forwarding Busy service 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-channels are busy for example). The Call Forwarding No Reply service 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. 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. 6.3 Procedures for Call Forwarding The following three sections detail the ISDN-User Part pro- cedures 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. 6.3.1 Call Forwarding related parameters in the Initial Address Message during Multiple Forwardings Figure 14/Q.730, p. 6.3.2 Procedures for an exchange that determines that a call it has received should be forwarded 6.3.2.1 General overview 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-exchange this parameter information is set and retained. The reason for the retention is that, if subsequent for- warding 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. 6.3.2.2 Checking the forwarding limit 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 continu- ing 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: a) Call Forwarding Busy, the cause value "user busy" is used; b) Call Forwarding No Reply, the cause value "no answer from user" is used; c) Call Forwarding Unconditional, the cause value "no user responding" is used. 6.3.2.3 Setting the parameters associated with call for- warding 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. 6.3.2.3.1 This is the first forwarding that the call has undergone There are three parameters to set: the redirection informa- tion, the called party number and the original called number. Their values are set as follows: 1) Redirection information. The redirection counter is one. The redirecting reason and redirecting indicator are set according to the forwarding conditions. 2) Original called number. This is equal to the first number that was called. 3) Called party number. This is equal to the number that the call is to be forwarded to. 6.3.2.3.2 This is the second forwarding that the call has under- gone There are three parameters to set: the redirection informa- tion, the called party number, and the redirecting number. Their values are set as follows: 1) Redirection information. The redirection counter is two. The redirecting reason and redirecting indicators are set according to the forwarding conditions. 2) Redirecting number. This is equal to the number that is doing the redirecting. 3) Called number. This is equal to the number that the call is to be forwarded to. 6.3.2.3.3 This is the third or greater forwarding that the call has undergone 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: 1) Redirection information. The redirection counter is incremented. The redirecting reason and redirecting indicators are set according to the forwarding conditions. 2) Redirecting number. This is equal to the number that is doing the redirecting. 3) Called number. This is equal to the number that the call is to be forwarded to. 6.3.2.4 Forwarding procedures at the forwarding exchange 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. 6.3.2.4.1 Call Forwarding Unconditional or Busy (Network Deter- mined) The exchange continues in the following fashion: 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 S 6.3.1. 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 con- nected 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-entered. 6.3.2.4.2 Call Forwarding No Reply The exchange continues in the following fashion: 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 S 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 - called party busy for instance, the current connec- tions should simply be left intact, until timer expiry or calling user disconnect. 2) If the original called user answers prior to receipt of alerting indication from the forwarded-to exchange, this user is awarded the call and the connection toward the forwarded-to exchange is released. 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-entered. 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. 6.3.2.4.3 Call Forwarding Busy (User Determined) The exchange continues in the following fashion: 1) An Address Complete Message with no indication of the called party's status in the backward call indicators param- eter should be returned to the calling party's exchange. 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 Mes- sage includes the parameter information as shown in S 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 - called party busy for instance, the call should be released with the cause value "user busy". 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-entered. 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 "user busy". 6.3.3 Notification procedures for the forwarding exchange 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-to number. Procedures for users subscribing to the notif- ication of forwarded-to number are for further study. 6.3.3.1 Forwarding user subscribes to redirection informa- tion presentation restricted The call progress message contains an event indicator of the "Event Information Presentation Restricted Type". The value is set according to the redirecting reason. 6.3.3.2 Forwarding user does not subscribe to redirection information presentation restricted The call progress message contains an event indicator that is not of the "Event Information Presentation Restricted" type. The value is set according to the redirecting reason. 6.3.3.3 Nofitification for Call Forwarding No Reply If Call Forwarding No Reply is in effect, and the exchange alerts the called party, the Address Complete message sent includ- ing 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-to exchange. 6.4 Interactions with other Supplementary Services where interaction has ISDN User Part impact 6.4.1 User-to-User Signalling 6.4.1.1 Description of interaction 6.4.1.1.1 Call Forwarding Busy (Network Determined) or Call Forwarding Unconditional If the forwarding party does not subscribe to a Service requested as "essential" 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 "essential", the call is cleared. The cause is "no user responding" in the case of Call Forwarding Unconditional and "user busy" in the case of Call Forwarding Busy. 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. 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 infor- mation that was contained in the original Initial Address Message. If the attempt is successful, user to user transfer will be avail- able between the calling user and forwarded to user. 6.4.1.1.2 Call Forwarding No Reply 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 "no indication" response to any User to User service requests. Any other response is a protocol error. Acceptance or rejection of User to User ser- vice requests occurs in the Connect (Answer) indication. 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 "essential" the call is cleared. The cause used in both cases is "no answer from user". 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. 6.4.1.1.3 Call Forwarding Busy (User Determined) 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 "no information" in response to any received User to User requests. If a Call is Forwarded Busy (User Determined) and one or more of any requested User to User services are essential and the for- warding 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 "essential" the call is cleared. The cause used in both cases is "user busy". 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 sub- scribes 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 indi- cator 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. 6.4.1.1.4 Message length 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. 6.4.2 Closed User Group 6.4.2.1 Description of interaction Closed User Group restrictions must be met on each leg of the call. In addition, CUG restrictions must be met end-to-end. If the call is forwarded multiple times, CUG restrictions have to be met between the calling user and every intermediate forwarding user. Calling User/Forwarded-to User: When a call is forwarded a new check of the CUG restrictions is made at the forwarded-to destina- tion. The CUG information sent to the forwarded-to destination is the same CUG information that was sent from the originating exchange. 6.4.2.2 Actions at a forwarding exchange For a subscriber who has both CUG interlock and Call Forward- ing 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 inter- lock code. The check would be done at the exchange for the decen- tralized 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 Mes- sage received, is included in the Initial Address Message transmit- ted. 6.4.2.3 Actions at a destination exchange 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. 6.4.3 Calling Line Identification Presentation 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 "Call Forwarding may occur". 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. 6.5 Message flow diagrams The messages over the access are included as examples only and are not exhaustive. Call release procedures are as per normal call. Abbreviations used in Figures 15/Q.730 to 22/Q.730 are the following: IAM Initial Address Message CPG Call Progress Message ACM Address Complete Message ANM Answer Message REL Release RLC Release Complete LE Local Exchange TE Terminal Entity TR Transit Exchange Blanc Figure 15/Q.730, p. 20 Figure 16/Q.730, p. 21 Figure 17/Q.730, p. 22 Figure 18/Q.730, p. 23 Figure 19/Q.730, p. 24 Figure 20/Q.730, p. 25 Figure 21/Q.730, p. 26 Figure 22/Q.730, p. 27 7 Time-out table Table 5/Q.730 specifies the timers to be used in conjunction with the supplementary services defined in this Recommendation. (This requires further study.) H.T. [T11.730] TABLE 5/Q.730 ________________________________________________________________________________________________________________________________________________________________________________________ Symbol Time-out value Significance Cause for initiation Normal termination At the first expiry At the following expiry Section ________________________________________________________________________________________________________________________________________________________________________________________ T 3 U-U facility request { Receipt of facility Acceptance or reject message } { "Protocol error" passed to call control } ________________________________________________________________________________________________________________________________________________________________________________________ ________________________________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 5/Q.730 [T11.730], p. ANNEX A (to Recommendation Q.730) Signalling procedure for the explicit invocation of user-to-user signalling services 1, 2 and 3 A.1 User-to-user signalling service A.1.1 General description of user-to-user service See SS 2.1 and 2.2. A.2 Procedures for user-to-user signalling associated with circuit switched calls A.2.1 User-to-user signalling, Service 1 A.2.1.1 General characteristics Service 1 allows users to communicate with user-to-user sig- nalling by transferring user-to-user information within ISDN user part messages during the call set-up and clearing phases. The user-to-user signalling service provided is not a guaranteed ser- vice. If for any reason the combination of the basic plus supple- mentary service information causes the overall maximum length of the message to be exceeded then if the User-to-user Signalling Ser- vice 1 is included the service should be rejected. A.2.1.2 User-to-user signalling, Service 1 - Explicit ser- vice request Procedures for call set-up are as described in Recommendation Q.764, S 2 with the following changes: On call set-up, the Initial Address Message will contain the user-to-user indicators parameter with Service 1 indicated as "requested essential/not essential" and Service 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. If the called user or network can support the transfer of user-to-user, a Service 1 acceptance will be returned to the ori- ginating exchange in an Address Complete or Call Progress Message for the point-to-point case or the Answer or Connect Message in the point-to-multipoint case with the indication "Service 1 provided" in the user-to-user indicators parameter. Services 2 and 3 will be indicated as "no information" in the user-to-user indicators param- eter. These explicit indications shall be forwarded to the call control at the originating exchange. User-to-user information may be contained in any of the mes- sages that may be transferred in the call set-up phase. A.2.1.3 Interworking In the case of interworking with a non-ISDN 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 If the called user or network does not understand the Ser- vice 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 rejec- tion.) If the network or called user cannot support Service 1, and it was requested with a non-essential indication, a Service 1 rejec- tion indication is returned in the Address Complete or Call Pro- gress Message with the indication "Service 1 not provided" in the user-to-user indicators parameter. 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, "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 user-to-user indicators parameter. A.2.1.5 User-to-user signalling in the call clearing phase A user-to-user information parameter may be included in the Release Message. The user-to-user 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-to-user information will be lost. A.2.2 User-to-user signalling, Service 2 A.2.2.1 General characteristics Service 2 allows the users to communicate with user-to-user signalling by transferring up to two user-to-user information mes- sages in each direction during the call setup phase. As a network option, user-to-user 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. Service 2 is only applicable when a point-to-point configura- tion exists at the user-network interface at the terminating exchange. A.2.2.2 Call set-up The Connection Request parameter will be included if CO-SCCP method is selected, or the call reference parameter if CL-SCCP method is selected. The SCCP connection confirm message will be returned if CO-SCCP method is selected. Procedures for call set-up are as described in Recommendation Q.764, S 2 with the following changes: On call set-up the Initial Address Message will contain the user-to-user indicators parameter with Service 2 indicated as "requested essential/not essential" and Services 1 and 2 indicated as "no information" will be passed to call control at the terminat- ing exchange. If the called user or network can support the transfer of user-to-user 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 user-to-user indicators parameter 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 Point-to-point calls The SCCP connection refused message will be returned if CO-SCCP method is selected. 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. If the network or called user cannot support Service 2, and it was requested with a non-essential indication, a Service 2 rejec- tion indication is returned in the Address Complete or Call Pro- gress Message with the indication "Service 2 not provided" in the user-to-user indicators parameter (Note - The Study Group XVIII service description does not allow this implicit rejection.) 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, "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 user-to-user indicators parameter. A.2.2.3.2 Point-to-multipoint calls If the call is point-to-multipoint 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-to-point procedures. The cause value in this case is code 88, "incompatible destination". A.2.2.4 Interworking In the case of interworking with a non-ISDN network, the "interworking" 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. A.2.2.5 Transfer of messages containing user-to-user infor- mation Once acceptance of Service 2 has been transmitted across the network, both of the involved users can transfer user-to-user information between themselves. Within the network the user-to-user information parameter will be carried in a User-to-user Information Message. The network provides for the transfer of these messages from the calling to the called side and vice versa. The User-to-user Information Message format can be found in Table 20/Q.763. If the Service 2 is provided, no more than two User-to-user Information Messages carrying user-to-user information parameters may be transmitted in each direction during the call set-up phase. If more than two messages are received during call set-up, 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. No transfer of user-to-user information can occur until the service is acknowledged. A.2.3 User-to-user signalling, Service 3 A.2.3.1 General characteristics Service 3 allows the users to communicate with user-to-user signalling by transferring User-to-user Information Messages in each direction during the active phase of the call. This service allows either an implicit or explicit rejection. Service 3 allows the service to be requested either during call set-up or after call set-up. However, Service 3 should not be requested after call set-up if it has been rejected during the call set-up phase. A.2.3.2 Service 3 requested during call set-up Procedures for call set-up are as described in Recommendation Q.764, S 2 with the following changes: On call set-up the Initial Address Message will contain the user-to-user indicators parameter with Service 3 indicated as "requested essential/not essential" and Services 1 and 2 indicated as "no information" exchange. The service request will be passed to the call control at the terminating exchange. If the called user or network can support the transfer of user-to-user 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 user-to-user indicators parameter 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 set-up If the called user or network does not understand the Ser- vice 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 Ser- vice 3. If the network or called user cannot support Service 3, and it was requested with a non-essential indication, a Service 3 rejec- tion indication is returned in the Address Complete, Call Progress Message, Answer or Connect with the indication "Service 3 not pro- vided" in the user-to-user indicators parameter allow this implicit rejection.) 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, "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 user-to-user indicators parameter. A.2.3.4 Service 3 requested after call set-up After call set-up 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 param- eter indicating user-to-user service and a user-to-user indicators parameter requesting Service 3 to the distant local exchange using the appropriate transport method. The facility request will contain the user-to-user indicators parameter with Service 3 indicated as "requested essential/not essential" and Services 1 and 2 indicated as "no information" 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 con- trol. On notification of the acceptance by call control the ISDN User Part will generate a Facility Accepted Message with the indi- cation "Service 3 provided" in the user-to-user indicators parame- ter indicators parameter. On the receipt of the message this expli- cit 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 set-up If the requested user or network does not understand the Ser- vice 3 request then no message is returned. This response shall be taken as an implicit rejection of the service request. If the network or requested user cannot support Service 3, and it was requested with a non-essential indication, a Service 3 rejection indication is returned in the Facility Reject Message with the indication "Service 3 not provided" in the user-to-user indicators parameter If 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 State 1 service description. A.2.3.6 Interworking In the case of interworking with a non-ISDN network an "inter- working" protocol control indicator will be returned to the ori- ginating exchange in the first appropriate message after call set-up, a Facility Reject Message is returned networks that inter- work 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 user-to-user infor- mation Once acceptance of Service 3 has been transmitted across the network, both of the involved users can transfer user-to-user information between themselves. Within the network the user-to-user information parameter will be carried in a User-to-user Information Message. The network provides for the transfer of these messages from the calling to the called side and vice versa. The User-to-user Information Message format can be found in Table 20/Q.763. A.2.4 Requesting user-to-user signalling Services 1, 2 and 3 This section describes procedures for requesting Services 1, 2 and 3. Note - User-to-user Service 1 implicit request/response pro- cedures are also found in S 2.2.1. Only explicit Service 1 requests may follow the procedure in this section. A.2.4.1 Call establishment Procedures for call establishment are described in SS A.2.1.2, A.2.2 and A.2.3.2 with the following modifications: On service request one user-to-user indicators parameter will be sent with each service being indicated as "requested, essential/non essential". If the called user can support the indicated services, then all three services will be indicated as "provided" in the user-to-user indicators parameter in the Address Complete or Call Progress Message. Alternatively, the Address Complete or Call Pro- gress Message may indicate "Service 3, no information" and "Ser- vice 3 provided" in the Answer or Connect Message as provided in S A.2.3.2. In the case that the call is to multi-point 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 If the called user or network does not understand the service requested, then the Address Complete, Call Progress, Answer or Con- nect Messages returned will not include either service(s) accep- tance or rejection. This type of response will be taken as an implicit rejection of all services. If the called user or network does not understand a specific service request, that specific service is implicitly rejected fol- lowing the procedures of SS A.2.1.4, A.2.2.3 and A.2.3.3. Alterna- tively, if the network or called user cannot support one or more service requests and the service requests were indicated as non-essential, 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, Ser- vice 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 SS A.2.1.4, A.2.2.3 and A.2.3.3. If any or all of the services requested is indicated as essen- tial and the called user or network cannot support one or more of the services, a Release Message is sent with cause code 29, "facil- ity rejected by the network", cause code 50, "requested facility not subscribed", or cause code 69, "requested facility not imple- mented" and the diagnostic containing the user-to-user indicators parameter. If the call control does not indicate Service 1, 2 or 3 accep- tance 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 In the case of interworking with a non-ISDN network, the "interworking" protocol information will be returned to the ori- ginating 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 User-to-user Information Messages The procedures for the transfer of User-to-user Information Messages is covered in SS A.2.2.5 and A.2.3.7. A.2.5 User-to-user information transport methods for Ser- vices 2 and 3 The Transport methods for Services 2 and 3 may be found in S 3 of Recommendation Q.764. A.2.6 Message flow diagrams The message flow diagrams are shown in Figures A-1/Q.730 to A-7/Q.730. For User-to-user Signalling Service 2 and 3 the figures only show ISDN user part messages required for basic call control and user-to-user signalling and are not meant to imply any particular transfer method. The parameters and indicators shown are for the User-to-user Signalling Service only, i.e. any parameters or mes- sage associated with the various transport methods are not shown. The following notes apply to Figures A-1/Q.730 to A-7/Q.730: Note 1 - In cases where an ALERTING indication is carried by a Call Progress Message the user-to-user indicators parameter and/or the user-to-user information parameter may also be tran- sported in the Call Progress Message. Note 2 - In cases where the called user is an automatic answering terminal, user-to-user indicators parameter and/or the user-to-user information parameter may be transported in a Connect Message. Figure A-1/Q.730 shows a successful use of user-to-user Sig- nalling Service 1 when explicitly requested in a point-to-point configuration. Figure A-2/Q.730 shows both the successful and unsuccessful use of user-to-user Signalling Service 2 in a point-to-point confi- guration. Figure A-3/Q.730 shows an unsuccessful use of user-to-user Signalling Service 2 in a point-to-multipoint configuration. This unsuccessful case is shown because the network reactions will be the same in all similar cases. Figure A-4/Q.730 shows both successful and unsuccessful cases for user-to-user Signalling Service 3 when the service is non-essential in a point-to-point configuration. Figure A-5/Q.730 shows a successful use of user-to-user Sig- nalling Service 3 after the call is active in a point-to-point con- figuration. Figure A-6/Q.730 shows a successful use of user-to-user sig- nalling Services 1, 2 and 3 and where all services are non-essential in a point-to-point configuration. Figure A-7/Q.730 shows successful use of user-to-user signal- ling Services 1 and 3 and unsuccessful use of Service 2 in a point-to-multipoint configuration. It should be noted again that Service 2 will not work in a point-to-multipoint configuration. The following abbreviations are used in the figures: H.T. [T12.730] __________________________________________________________ Abbreviations { User-to-user Indicator Values } __________________________________________________________ ni no information rne requested, non essential re requested, essential p provided np not provided __________________________________________________________ Abbreviations Parameter name __________________________________________________________ UUI { user-to-user information } UUI ind. user-to-user indicators __________________________________________________________ Abbreviations Message name __________________________________________________________ ACM Address Complete ANM Answer FAR Facility Request FAA Facility Accepted IAM Initial Address REL Release RLC Release Complete USR { User-to-user Information } __________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau [T12.730], p. 29 Blanc 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-to-user procedures the ISDN access protocol Recommendation Q.931 should be examined. Figure A-1/Q.730, p. 30 Figure A-2/Q.730, p. 31 Figure A-3/Q.730, p. 32 Figure A-4/Q.730, p. 33 Figure A-5/Q.730, p. 34 Figure A-6/Q.730, p. 35 Figure A-7/Q.730, p. 36 A.2.7 Interaction with other supplementary services A.2.7.1 Call forwarding services Interactions with the call forwarding services are shown in the call forwarding protocol sections. A.2.7.2 Call waiting service Interactions with the call waiting service are shown in the call waiting protocol sections. (Call waiting is for further study.) A.2.7.3 Other services There are no known interactions with services other than those listed. A.2.8 State transition diagrams The state transition diagrams may be found in the Stage 2 description of the User-to-user Service. Blanc MONTAGE: PAGE 184 = BLANCHE