5i' Recommendation Q.82 CALL OFFERING SUPPLEMENTARY SERVICES 1 Call transfer Under study. 2 Call forwarding services 2.1 Introduction 2.1.1 General This Recommendation includes stage 2 descriptions for the three versions of call forwarding services given below, when imple- mented using the "forward switching" network routing algorithm described in Recommendation Q.80. The following descriptions are for further study: - re-routing case as described in Recommendation Q.80; - the optional notification to be sent to the cal- ling user A when the value of the subscription option "calling user receives notification that his call has been forwarded" is "yes, with forwarded-to-user number"; - the optional notification to be sent to the served user Bmwhen the value of the subscription option "served user receives notification that his call has been forwarded" is "yes, with call offering information". Further details and definitions of the stage 1 description, i.e., the service description as seen from the user, can be found in Recommendation I.252. 2.1.2 Definitions call forwarding unconditional (CFU) Call forwarding unconditional (CFU) permits a user to have the network send all incoming calls, or just those associated with a specific basic service, addressed to the served user's ISDN number to another number. The served user's originating service is unaf- fected. If this service is activated, calls are forwarded no matter what the condition of the termination. Other call forwarding services provide call forwarding based on con- dition, e.g. call forwarding busy (CFB) and call forwarding no reply (CFNR). call forwarding busy (CFB) Call forwarding busy (CFB) permits a served user to have the network send all incoming calls, or just those associated with a specific basic service, which meet busy and are addressed to the served user's ISDN number to another number. The served user's ori- ginating service is unaffected. call forwarding no reply (CFNR) Call forwarding no reply (CFNR) permits a served user to have the network send all incoming calls, or just those associated with a specific basic service, which meet no reply and are addressed to the served user's ISDN number to another number. The served user's originating service is unaffected. 2.2 Call forwarding setup and release Figure 2-1/Q.82, p. 2.2.1 Information flow diagrams Call forwarding unconditional and for "network determined user busy": Figure 2-2/Q.82. Call forwarding for "user determined user busy": Figure 2-3/Q.82. Call forwarding on no reply: Figure 2-4/Q.82. Call forwarding disconnect procedure (including advice of charge): Figure 2-5/Q.82. Figure 2-2/Q.82, p. (a l'italienne) Figure 2-3/Q.82, p. (a l'italienne) Figure 2-4/Q.82 (sheet 1 of 4), p. (a l'italienne) Notes related to Figures 2-2 to 2-4/Q.82 Note 1 - The calling party number and the last forwarding number should be included if required by the "calling line identification presentation" supplementary service. Note 2 - The notification should be sent only if the B-party sub- scribes to the "calling user receives notification that his call has been forwarded" subscription option. Note 3 - The connected number is included if required by the "con- nected line Identification presentation/restriction" supplementary service. Note 4 - The forwarded-to-user will receive this information depending on his notification option, the availability of this information from the network and possible presentation restric- tions. Note 5 - This parameter may be omitted between FE4 and FE6 in order to limit the number of parameters to be passed in the network (see Table 2-6/Q.82, Note 1). Figure 2-5/Q.82 (sheet 2 of 4) A L'ITALIENNE, p. Figure 2-4/Q.82 (sheet 3 of 4) A L'ITALIENNE, p. Figure 2-4/Q.82 (sheet 4 of 4) A L'ITALIENNE, p. Figure 2-5/Q.82 p. 2.2.2 SDL diagram for FE4/FE6/FE8 Figure 2-6/Q.82 (feuillet 1 sur 8), p. Figure 2-6/Q.82 (sheet 2 of 8), p. Figure 2-6/Q.82 (sheet 3 of 8), p. Figure 2-6/Q.82 (sheet 4 of 8), p. Figure 2-6/Q.82 (sheet 5 of 8), p. (a l'italienne) Figure 2-6/Q.82 (sheet 6 of 8), p. Figure 2-6/Q.82 (sheet 7 of 8), p. Figure 2-6/Q.82 (sheet 8 of 8), p. 2.2.3 SDL diagrams for other FEs These are not explicitly shown since they are equal to basic services (CC or CCA) SDLs with small additions which can be easily derived from the information flow diagrams. 2.2.4 Definition of individual information flows Refer to information indicated in the Notes related to Fig- ures 2-2 to 2-5/Q.82 and S 2.2.5. 2.2.5 Multiple diversion address handling Figure 2-7/Q.82, p. H.T. [T1.82] TABLE 2-1/Q.82 Information carried in the SETUP req. ind ____________________________________________________________________________________________________________________________ Parameter HOP 1 HOP 2 HOP 3 HOP 4 HOP 5 HOP 6 ____________________________________________________________________________________________________________________________ Calling party number A A A A A A ____________________________________________________________________________________________________________________________ Called party number B 1 B 2 B 3 B 4 B 5 C ____________________________________________________________________________________________________________________________ Last forwarding number . B 1 Note 1 B 2 . B 3 . B 4 . B 5 . ____________________________________________________________________________________________________________________________ Original call number . B 1 B 1 B 1 B 1 B 1 ____________________________________________________________________________________________________________________________ Forwarding counter . 1 2 3 4 5 ____________________________________________________________________________________________________________________________ Last forwarding cause . V(B 1) Notes 1, 2 V(B 2) Note 2 V(B 3) Note 2 V(B 4) Note 2 V(B 5) Note 2 ____________________________________________________________________________________________________________________________ Original forwarding cause . V(B 1) Note 2 V(B 1) Note 2 V(B 1) Note 2 V(B 1) Note 2 V(B 1) Note 2 ____________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - May be omitted to limit the number of parameters being passed in the network. Note 2 - V(B 1) indicates the reason for diversion from party B 1 with a value (V) equal to: unknown/not available, user busy, no reply or unconditional when diversion occurs. Table 2-1/Q.82 [T1.82], p. H.T. [T2.82] TABLE 2-2/Q.82 Information in the backward direction ______________________________________________________________________________________ Parameter HOP 1 HOP 2 HOP 3 HOP 4 HOP 5 HOP 6 ______________________________________________________________________________________ Notification from . B 1 B 2 | | | B 3 | | | B 4 | | | B 5 ______________________________________________________________________________________ { Forwarded-to-number from } . For further study ______________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 2-2/Q.82 [T2.82], p. 2.2.6 Functional entity actions 1) Functional entity actions for FE1 - Receive indications relating to the service from FE2. 2) Functional entity actions for FE2 - Receive indications relating to the service from FE4 and forward them to FE1. 3) Functional entity actions for FE3 - No functional entity actions uniquely relating to this service are identified for FE3. 4) Functional entity actions for FE4/FE6 - Store call information and user's service alloca- tion and state. - Run periodic timers specific to the service. - Stimulate forward basic call setups to nominated numbers when service is active. - Increment service call counts and forward to next FE4/6. - Stimulate release procedures at service call count limit. - Receive and implement user's service requests from FE5/7. - Determine information to be notified backwards to other users. 5) Functional entity actions for FE5/FE7 - Receive indications relating to the service from FE4/6. - Receive and forward user's service requests to FE4/5. 6) Functional entity actions for FE8 - Receive and increment forward call counter. (Note - This is an attribute of FE4/6.) - Send forwarding indicators relating to the ser- vice of FE9 (this would be an attribute to FE6). 7) Functional entity actions for FE9 - Receive indications relating to the service from FE8. 2.3 Possible allocation of functional entities to physical locations H.T. [T3.82] ________________________________________________ A PARTY B 1 PARTY B x PARTY C PARTY ________________________________________________ | | | | | | | | | | | | FE1 FE2 FE3 FE4 FE5 FE6 FE7 FE8 FE9 _____________________________________________________________ Scenario 1 TE LE TR LE TE LE TE LE TE _____________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table [T3.82], p. Other scenarios are for further study. 2.4 Interactions with other supplementary services The interaction with supplementary services, such as calling line identification, connect-test line identification and advice of charge have been considered; interactions with other supplementary services are for further study. 2.5 Terminology and abbreviations Abbreviations used: CFU Call forwarding unconditional CFB Call forwarding on busy CFNR Call forwarding on no reply CD Call deflection CC Call control CCA Call control agent FE Functional entity TE Terminal equipment LE Local exchange TR Transit exchange NDUB Network determined user busy UDUB User determined user busy Terminology: Original called number: The number the originating party dials. Connected line number: The number of the final destination. Forwarding number: The number of the served user, i.e. the subscriber who ini- tiates the forwarding service and from where the call has been for- warded. Forwarded-to-number: The number to which a call has been forwarded. Forwarding indicator: Indicator showing that call has been forwarded and indicat- ing whether or not this information should be given to calling party. 3 Call deflection Under study. 4 Line hunting 4.1 Introduction 4.1.1 Definition Line hunting is a supplementary service which enables incoming calls to a specific ISDN number to be distributed over a group of interfaces. Note - Expansion of the line hunting service to cover the case of hunting on available ISDN numbers or addresses, rather than on interfaces is a possible extension of the service. 4.1.2 Description This description covers the form of line hunting which applies to interfaces within one node. It is an anticipated further exten- sion to enable the group of interfaces available for selection to be distributed over more than one node. The selection of an interface within a node is performed on the basis of the hunting algorithm used. (Where hunting is extended over more than one node the network routing techniques used to extend the selection to the next node may be similar to that used for the call forwarding sup- plementary service, though applied by the Administration. The pre- cise description of multi-node line hunting is for further study.) An access belonging to a line hunting group may also be addressed using an individual ISDN number. Facilities associated with the individual number are not affected by line hunting. 4.2 Definition of the functional model The additional functionality required for line hunting, over that of the basic service, is confined to a single node, as seen in Figure 4-1/Q.82. Figure 4-1/Q.82, p. 4.3 Information flow 4.3.1 Flow for single node hunting For the single node case, the information flows are those defined for the basic call as shown in Figure 4-2/Q.82. No informa- tion flows arise as a result of the hunting action. Figure 4-2/Q.82, p. 22 4.3.2 Flow for multi-node hunting This is for further study. 4.4 SDL diagrams The SDL diagrams for the entity FE1 are shown in Figure 4-3/Q.82 and Figure 4-4/Q.82. Figure 4-3/Q.82, p. 23 Figure 4-3/Q.82, p. 4.5 Functional entity actions 4.5.1 Single node hunting The FEAs attributed to entity FE1, the line hunting entity, indicated by (1) on the information flow diagram are as follows: - determine hunting algorithm; - select free interface. 4.5.2 Multi-node line hunting FEAs, in addition to the single node FEAs, which are required for hunting over more than one node are for further study. 4.6 Physical locations for functional entities The scenarios which apply to line hunting are shown in Table 4-1/Q.82. H.T. [T4.82] TABLE 4-1/Q.82 Possible line hunting scenarios _______________________________________________________________________ Functional entities Scenario CCA CC CC CC/FE1 CC CCA _______________________________________________________________________ 1) Basic rate access TE LE TR LE - TE _______________________________________________________________________ 2) Basic rate access TE LE TR NT2 - TE _______________________________________________________________________ 3) Primary rate access TE LE TR LE NT2 TE _______________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau 4-1/Q.82 [T4.82], p. MONTAGE: RECOMMANDATION Q.83 SUR LE RESTE DE CETTE PAGE