home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-12-22 | 106.7 KB | 3,517 lines |
-
-
-
- 5i'
-
- MONTAGE : FIN DE LA RECOMMANDATION I.251 EN-T | TE DE CETTE PAGE
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Recommendation I.252
-
-
-
- CALL OFFERING SUPPLEMENTARY SERVICES
-
-
-
- (Melbourne, 1988)
-
-
-
- The purpose of this Recommendation is to provide the stage 1
- description of the method defined in Recommendation I.130 using the
- means given in Recommendation I.210.
-
-
- Supplementary services are described by a prose definition and
- description (step 1.1) and by a dynamic description (step 1.3). The
- application of the attribute technique (step 1.2), as defined in
- Recommendation I.140, for supplementary services is for further
- study.
-
- This Recommendation describes the following Call Offering sup-
- plementary services:
-
- I.252.1 Call Transfer (CT)
-
- I.252.2 Call Forwarding Busy (CFB)
-
- I.252.3 Call Forwarding No Reply (CFNR)
-
- I.252.4 Call Forwarding Unconditional (CFU)
-
- I.252.5 Call Deflection (CD) (Note)
-
- I.252.6 Line Hunting (LH)
-
- Note - This service having been identified now requires
- further study; its description is not yet included.
-
-
- 1 I.252.1 - Call Transfer
-
-
-
- 1.1 Definition
-
-
- The Call Transfer supplementary service enables a user to
- transfer an established (i.e. active) call to a third party. For
- the original call, the "served user" (see S 1.2.2) may have been
-
-
-
-
-
-
-
-
-
- either the calling or called party (i.e. the call may have been
- either incoming or outgoing). This service differs from the Call
- Diversion (i.e. Call Forwarding) supplementary services in that the
- latter deal only with incoming calls that have not yet reached the
- "fully-established" state, whereas in the case of Call Transfer an
- established end-to-end connection exists.
-
-
-
- 1.2 Description
-
-
-
- 1.2.1 General description
-
-
- Three methods of Call Transfer are identified. One, called
- "Normal" Call Transfer, is described in S 1.3.2 below. The two oth-
- ers are described in S 1.3.4. Although the invocation of these
- various methods differ, the essential operation of Call Transfer is
- to transform the served user's established call into a new call
- between the other party on the established call and a third party.
- It should be noted that, in a Three-Party Service call, there are
- several stages at which the served user can effectively transfer
- the call. These are described in the Three-Party Service descrip-
- tion.
-
-
- 1.2.2 Specific terminology
-
-
-
- 1.2.2.1 Served user, other parties
-
-
- During the invocation and active phases, the service is under
- the control of the "served user", i.e. the one for whom the service
- was subscribed. This user is also referred to as "user A". Other
- parties associated with this service are defined as follows:
-
- - user B is the other party in the original call
- (A<- B);
-
- - user C is the "third party" - the other party in
- the subsequent call (A | (raC).
-
-
- 1.2.3 Qualifications on the applicability to telecommunica-
- tion services
-
-
- This supplementary service is considered meaningful when
- applied to the Telephony teleservice and the speech and 3.1 kHz
- audio bearer service. Furthermore, it may also be meaningful when
- applied to other services.
-
-
-
-
-
-
-
-
-
-
-
- 1.3 Procedures
-
-
-
- 1.3.1 Provision/withdrawal
-
-
- The Call Transfer supplementary service is subscribed to by
- prior arrangements with the service provider. Subscription can be
- made for "Normal Call Transfer" and/or for either of the alternate
- procedures (i.e. "Single-Step Call Transfer" or "Explicit Call
- Transfer") offered by the service provider.
-
- Withdrawal of the service is made by the service provider upon
- request by the subscriber or for service provider reasons.
-
-
- 1.3.2 Normal procedures
-
-
-
- 1.3.2.1 Activation/deactivation/registration
-
-
- None identified.
-
-
- 1.3.2.2 Invocation and operation
-
-
- The served user, user A, can transform an established call
- with user B into (effectively) a call from user B to a third party,
- user C. When the served user (user A) asks the service provider to
- begin the "Normal" Call Transfer, the service provider puts the
- already established call (with user B) on hold. User A then
- proceeds to establish the second call (to user C). Upon request
- from user A to complete the Call Transfer, the service provider
- would connect users B and C together while removing the connections
- between user A and the other two users. (The extent to which the
- service provider re-uses the resources from the A<- B and A | (raC
- calls to form the B | (raC call is a service provider option.)
-
- Note - In the resulting call B | (raC, user C will have all
- the relevant characteristics of the called party, but user B will
- not necessarily have all the characteristics of the calling party,
- depending on whether user B called user A and also depending on
- which service or supplementary service is under consideration.
-
- In some networks, user A can request completion of the Call
- Transfer either during or after the establishment of the connection
- to user C.
-
- The service provider will optionally notify users B and C of
- the transfer and, depending on interworking conditions and the sup-
- plementary services subscribed to by users B and C, will indicate
- to user B the number of user C and will indicate to user C the
- number of user B.
-
-
-
-
-
-
-
-
-
- 1.3.3 Exceptional procedures
-
-
-
- 1.3.3.1 Activation/deactivation/registration
-
-
- None identified.
-
-
- 1.3.3.2 Invocation and operation
-
-
- The service request would be rejected if the user invoking the
- service has not subscribed to the Call Transfer service (or the
- requested service option). The user would be notified of the cause
- for rejection and the original call A<- B would remain in the state
- it was in before the transfer request was received.
-
- If user A's attempt to establish a connection to user C is
- unsuccessful, (e.g. user C is busy), user A will be so informed and
- will be able either to retrieve the original call A<- B or to
- attempt a new connection (e.g. to C or to another party) (see
- Figure 2/I.252).
-
- The transfer request would be rejected if the network is
- unsuccessful in connecting users B and C (e.g. when user C is busy,
- when there is network congestion, or when transfer restrictions are
- violated). The user would be notified of the cause for rejection
- and the two calls would remain in the states they were in before
- the request was received.
-
-
- 1.3.4 Alternative procedures
-
-
-
- 1.3.4.1 Activation/deactivation/registration
-
-
- None identified.
-
-
- 1.3.4.2 Invocation and operation
-
-
-
- 1.3.4.2.1 Single-Step Call Transfer
-
-
- In this procedure, the served user can transfer an established
- call (with user B) to another user (user C) without first estab-
- lishing a call to user C. When invoking a Single-Step Call
- Transfer, the served user would indicate to the service provider
- the address of user C. The service provider would then establish a
- connection between users B and C, and disconnect the served user,
- user A, from the original call with user B. It should be noted that
-
-
-
-
-
-
-
-
-
- the service provider is not required to reinstate the call A<- B if
- a Single-Step Call Transfer to user C fails. It is also necessary
- to notify user B of the progress of the establishment of the call
- to user C, particularly if the call A<- B cannot be reinstated.
-
-
- 1.3.4.2.2 Explicit Call Transfer
-
-
- In this procedure, the served user A puts the already esta-
- blished call (with user B) on hold and then proceeds to establish
- another call (to user C) or to accept an incoming call (from
- user C). If user A's attempt to establish a connection to user C is
- unsuccessful (e.g. user C is busy), user A will be so informed and
- will be able either to retrieve the original call A<- B or to
- attempt a new connection (e.g. to user C or to another party) (see
- Figure 4/I.252).
-
- User A then explicitly requests that the call with user B be
- transferred to user C. (By contrast, in the Normal Call Transfer
- procedure, the service provider "knows" that the two calls [A<- B
- and A | (raC] are related; requesting completion of Normal Call
- Transfer for call A | (raC implicitly means "connect user C with
- user B".) The remainder of the procedures are identical to Normal
- Call Transfer (with the possible exception of the failure pro-
- cedures.)
-
-
- 1.4 Network capabilities for charging
-
-
- This Recommendation does not cover charging principles.
- Future Recommendations in the D-Series are expected to contain that
- information.
-
- It shall be possible to charge the subscriber accurately for
- the service.
-
-
- 1.5 Interworking requirements
-
-
- User B and user C may not be able to receive each other's
- address if one (or both) of the calls exits from the ISDN network.
- The different scenarios are shown in the following tables. The
- tables assume that B is the originator of the call to A. The net-
- work may not be able to recognize user identification if one or
- both of the calls requires interworking with non-ISDN network(s).
-
-
- For illustrative purposes, assume that user B originates a
- call to user A, and user A initiates the call transfer service to
- connect user B to user C. The different scenarios are shown in the
- following tables:
-
-
- H.T. [T1.252]
-
-
-
-
-
-
-
-
-
- i) Users A, B and C are in ISDN
-
- ___________________________________________________________________________________
- {
- Address information available to
- } Address of A Address of B Address of C
- ___________________________________________________________________________________
- User A - YES YES
- ___________________________________________________________________________________
- User B YES - YES
- ___________________________________________________________________________________
- User C YES YES -
- ___________________________________________________________________________________
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
- Tableau i) [T1.252], p. 1
-
-
-
- H.T. [T2.252]
- ii) Users A and B are in ISDN. User C is in another network
-
- ___________________________________________________________________________________
- {
- Address information available to
- } Address of A Address of B Address of C
- ___________________________________________________________________________________
- User A - YES YES
- ___________________________________________________________________________________
- User B YES - YES
- ___________________________________________________________________________________
- User C NO NO -
- ___________________________________________________________________________________
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
- Tableau ii) [T2.252], p. 2
-
-
-
- H.T. [T3.252]
- iii) Users A and C are in ISDN. User B is in another network
-
- ___________________________________________________________________________________
- {
- Address information available to
- } Address of A Address of B Address of C
- ___________________________________________________________________________________
- User A - NO YES
- ___________________________________________________________________________________
- User B YES - NO
- ___________________________________________________________________________________
- User C YES NO -
- ___________________________________________________________________________________
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
- Tableau iii) [T3.252], p. 3
-
-
-
- H.T. [T4.252]
-
-
-
-
-
-
-
-
-
- iv) User A is in ISDN. Users B and C are in another network
-
- ___________________________________________________________________________________
- {
- Address information available to
- } Address of A Address of B Address of C
- ___________________________________________________________________________________
- User A - NO YES
- ___________________________________________________________________________________
- User B YES - NO
- ___________________________________________________________________________________
- User C NO NO -
- ___________________________________________________________________________________
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
- Tableau iv) [T4.252], p. 4
-
-
-
- 1.6 Interaction with other supplementary services
-
-
-
- 1.6.1 Call Waiting
-
-
- Assume served user A has an established call with user B and
- wishes to transfer user B to user C, and users A, B and C all have
- subscribed to the Call Waiting Service. If a call from user D is
- received while:
-
- i) user A is invoking Normal Call Transfer
-
- - If user D calls user A at any time before A
- requests the completion of the transfer of user B to user C, then
- user A shall receive a call waiting indication. When user B is
- transferred to user C, a B-channel would normally become idle, ena-
- bling user A to accept the waiting call.
-
- - If user D calls user B, then user B can use nor-
- mal call waiting procedures to accept the waiting call (preferably
- once the transfer to user C is completed). If user B had a call
- waiting indication while the call was established with user A, the
- call waiting indication shall not be affected by the transfer of
- user B to user C.
-
- - If user D calls user C during the transfer pro-
- cess (i.e. while user C is engaged on an active call with user A),
- the call waiting indication shall be presented to user C. User C
- could then use Normal Call Waiting procedures to accept the waiting
- call (preferably once the call transfer is completed).
-
- ii) user A is invoking Single-Step Call Transfer
-
- - User A may receive a call waiting indication any
- time before or during the transfer invocation. Once the Single-Step
- Call Transfer is invoked, then user A is disconnected from user B,
- thus, causing a B-channel to normally become idle, enabling user A
-
-
-
-
-
-
-
-
-
- to accept the waiting call.
-
- - User B may receive a call waiting indication any
- time before or during the transfer invocation. User B could then
- use Normal Call Waiting procedures to accept the waiting call
- (preferably once the transfer is completed). If the transfer is not
- successful (e.g. user C is busy), then user B would normally
- release the call, causing a B-channel to become idle and enabling
- user B to accept the waiting call.
-
- - If the call from user D arrives at user C's serv-
- ing office after the call from A, user C would receive a call wait-
- ing indication. The call waiting indication shall not be affected
- by the transfer of user B to user C. User C could then use Normal
- Call Waiting procedures to accept the waiting call (preferably once
- the transfer is completed). If the call from user D arrives before
- the call from user A, the call from user A will receive call wait-
- ing treatment.
-
- iii) user A is invoking Explicit Call Transfer
-
- - The interaction for users A, B, or C with call
- waiting are the same as for i) above.
-
-
-
- 1.6.2 Call Transfer
-
-
- It shall be possible for both users (user A and user B) in a
- normal call, who have each subscribed to the Call Transfer Service,
- to simultaneously transfer the call. That is, if user A and user B
- are active in an established call, user A could transfer the call
- to a user C and user B could transfer the call to a user D. Call
- progress signals and other notifications will be delivered to the
- appropriate party at the time the signal is received. See
- Figure 1/I.252.
-
-
- Figure 1/I.252, (N), p.
-
-
-
- 1.6.3 Connected Line Identification Presentation (COLP)
-
-
- Assume that user A has an established call with user B and
- wishes to transfer this call with user B to user C. Except in the
- case where user C prohibits the presentation of his/her number,
- user C's number shall be presented:
-
- - to user B upon the successful completion of the
- transfer to user C (independent of the type of transfer procedure
- invoked by user A) provided that user B has subscribed to COLP;
-
- - to user A when user A is using the Normal or
- Explicit Call Transfer procedures and has subscribed to COLP. The
-
-
-
-
-
-
-
-
-
- reached party's number will not be presented to user A if user A
- invokes the Single-Step Call Transfer procedure.
-
- Note - Number presentation may not be possible if interwork-
- ing with a non-ISDN network is involved in the call transfer.
-
-
- 1.6.4 Connected Line Identification Restriction (COLR)
-
-
- Assume that a user A has an established call with a user B and
- wishes to transfer this call with user B to a user C.
-
- If user C has subscribed to COLR, then user A shall not
- receive user C's number when user A invokes any Call Transfer pro-
- cedure and user B shall not receive user C's number during the
- transfer of user B to user C.
-
-
- 1.6.5 Calling Line Identification Presentation (CLIP)
-
-
- For Normal and Explicit Call Transfers, user A shall have his
- number presented to user C and user B shall have his number
- presented to user C unless:
-
- 1) user A or B has number presentation restric-
- tions; or
-
- 2) the call transfer process requires interworking
- with a non-ISDN network.
-
- For Single-Step Call Transfer, if user C has subscribed to
- CLIP he shall receive the number of user B unless:
-
- 1) User B has address presentation restrictions; or
-
- 2) the call transfer process requires interworking
- with a non-ISDN network.
-
- User C may also receive user A's address as a " redirecting
- party " unless:
-
- 1) User A has address presentation restrictions; or
-
- 2) the call transfer process requires interworking
- with a non-ISDN network.
-
-
-
- 1.6.6 Calling Line Identification Restriction (CLIR)
-
-
- Assume that a user A has an established call with a user B and
- wishes to transfer this call with user B to a user C.
-
- If user A has subscribed to CLIR, then user C shall not
-
-
-
-
-
-
-
-
-
- receive a calling number when user A invokes any Call Transfer pro-
- cedure. If user B has subscribed to CLIR, then user C shall not
- receive a calling number during the transfer of user B to user C.
-
-
- 1.6.7 Closed User Group (CUG)
-
-
- The intention of CUG is to allow some connections and prohibit
- others; call transfer must not compromise this intention.
-
- Assume that a user A has an established call with user B and
- wishes to transfer this call with user B to a user C. When consid-
- ering CUG requirements and restrictions, the transfer process (all
- three procedures) should be considered as three separate call pro-
- cessings:
-
- 1) when users A and B established their original
- connection, if user A and/or user B was a member of a CUG, then CUG
- requirements must have been met before the two parties were con-
- nected;
-
- 2) when user A invokes a transfer procedure, both
- user A and user C must meet CUG requirements before the call can be
- completed, if either user A or user C is a member of a CUG;
-
- 3) finally, the transfer connection of user B to
- user C must first meet all CUG requirements (if either user B
- and/or user C is a member of a CUG) before the two parties can
- establish communications.
-
- The above requirements insure that CUG security is not
- violated. They prevent, for example, a user A who meets CUG
- requirements with user C from transferring a user B who does not
- meet CUG requirements with user C.
-
-
- 1.6.8 Conference Calling
-
-
- Refer to Recommendation I.254, S 1.6.2, ineraction with Call
- Transfer.
-
-
- 1.6.9 Direct-Dialling-In
-
-
- No impact, i.e. neither supplementary service affects the
- operation of the other supplementary service.
-
-
- 1.6.10 Call Divertion (i.e. Call Forwarding Services)
-
-
- In general, if the served user attempts to establish a call to
- a party that is forwarding calls, the forwarded-to party will be
- alerted and may be transferred to. Specific procedures are
-
-
-
-
-
-
-
-
-
- described below.
-
- The count for the number of forwarding "hops" should be
- cleared each time a call transfer occurs.
-
- Assume that a user A has an established call with a user B and
- wishes to transfer this call with user B to a user C:
-
-
- 1.6.10.1 Call Forwarding Busy (CFB)
-
-
- User C, which has subscribed to CFB, may be busy on another
- call when user A's call is received. The call from user A would
- then be routed to another user D. For Normal and Explicit Call
- Transfers, user A would, in general, be aware of the forwarding and
- could make a decision as to whether or not the transfer of user B
- should be completed to the forwarded-to user D. For Single-Step
- Call transfer, user B would be connected to the forwarded-to
- user D.
-
-
-
- 1.6.10.2 Call Forwarding No Reply (CFNR)
-
-
- User C, who has subscribed to CFNR, may have a free access but
- does not answer user A's call. Upon expiration of the CFNR timer,
- user A's call would be routed to another user D. For Normal and
- Explicit Call Transfers, user A would, in general, be aware of the
- forwarding and could make a decision as to whether or not the
- transfer of user B should be completed to the forwarded-to user D.
- For Single-Step Call Transfer, user B would be connected to the
- forwarded-to user D.
-
-
- 1.6.10.3 Call Forwarding Unconditional (CFU)
-
-
- If user C has subscribed to CFU, then user A's call will be
- routed to another user D. For Normal and Explicit Call Transfers,
- user A would, in general, be aware of the forwarding and could make
- a decision as to whether or not the transfer of user B should be
- completed to the forwarded-to user D. For Single-Step Call
- Transfer, user B would be connected to the forwarded-to user D.
-
-
- 1.6.11 Line Hunting
-
-
- No impact, i.e. neither supplementary service affects the
- operation of the other supplementary service.
-
-
- 1.6.12 Three-Party Service
-
-
-
-
-
-
-
-
-
-
-
- The forms of call transfer given in Table 1/I.252 are applica-
- ble to the indicated states of Three-Party Service.
- H.T. [T5.252]
- TABLE 1/I.252
-
- ______________________________________________________________________________________________
-
-
- Call transfer
-
- {
- Normal Single-step Explicit
- ______________________________________________________________________________________________
- Active/held {
- YES | fB^a^)
- } NA YES
- ______________________________________________________________________________________________
- Three-way conversation YES | ua) NA {
- NA
-
- a)
- See Figure 4/I.254, three-party service dynamic
- description.
- }
- ______________________________________________________________________________________________
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Table 1/I.252 [T5.252], p.
-
-
-
- 1.6.13 User-to-User Signalling (UUS)
-
-
- Prior to transfer: Prior to beginning a transfer user A can
- employ UUS services 1, 2 and 3 normally.
-
- During transfer: UUS services 1, 2 and 3 are only allowable
- between user A and user B and/or between user A and user C.
- User-to-user information (UUI) sent by user B will be delivered to
- user A, not user C. UUI cannot be transferred between users B and C
- during this time. The delivery of service 3 UUI cannot be
- guaranteed during transfer.
-
- After completion of transfer: Only if user B and user A both
- request service(s) 1, 2 and/or 3, is that service(s) available for
- use between users B and C after the transfer is completed. If user
- A did not request a given service in the set-up to user C, user B
- will be informed that he can no longer employ that service on this
- call. If user A requested a particular service in the set-up to
- user C, but the service was not requested by user B in the initial
- set-up message to user A, user C will be informed at the completion
- of the transfer that he can no longer employ the service.
-
- Note 1 - The procedures to be followed if transfer of charge
- is permitted are for further study.
-
- Note 2 - The procedures to be followed if the number of
- allowable messages has been reached by any party are for further
- study.
-
-
-
-
-
-
-
-
-
- 1.6.14 Multiple Subscriber Number
-
-
- No impact, i.e. neither supplementary service affects the
- operation of the other supplementary service.
-
-
- 1.6.15 Call Hold
-
-
- Parties held by users A, B and C, before invoking a transfer
- process will continue to be held by the parties after the transfer
- process. For example, if user B places his call to user A on hold
- during user A's transfer of the call to user C, the resulting call
- from user B to user C shall remain held by user B until it is
- retrieved by user B. The only exception to this is the Explicit
- Call Transfer procedure when user A transfers user B to user C. In
- this case, user B will no longer be held by user A after the
- transfer is completed.
-
- Special case: Assume users A and B were in an active call and
- user A places user B on hold, and user B places user A on hold. If
- user A transfers user B to user C by invoking the Explicit Call
- Transfer procedure, then the transfer shall take effect with the
- resulting call between users B and C remaining held by user B and
- the held call between user A to user B shall be discarded (i.e.
- user B cannot retrieve user A after the transfer).
-
-
- 1.6.16 Advice of Charge
-
-
- Refer to Recommendation I.256, SS 2.1.6.2, 2.2.6.2, 2.3.6.2,
- Interaction with Call Transfer.
-
-
- 1.7 Dynamic description
-
-
- The dynamic description of this service is shown in
- Figure 2/I.252.
-
-
- 2 I.252.2 - Call Forwarding Busy
-
-
-
- 2.1 Definition
-
-
- Call Forwarding Busy (CFB) permits a "served user" (see
- S 2.2.2) to have the network send to another number all incoming
- calls for the served user's ISDN number (or just those associated
- with a specified basic service) which meet busy at the served
- user's ISDN number. The served user's originating service is unaf-
- fected.
-
-
-
-
-
-
-
-
-
-
- Note - In normal situations, the CFB service is provided on a
- per access basis. (In these situations, there is a one-to-one rela-
- tionship between ISDN number and access.) However, the network may
- recognize multiple numbers on a single interface; in addition, it
- may not undertstand a complete ISDN number (e.g. DDI). In these
- cases, the CFB service is offered on the basis of the part of the
- ISDN number which the network can recognize.
-
-
- 2.2 Description
-
-
-
- 2.2.1 General description
-
-
- For a given ISDN number, this service (including options) may
- be subscribed to for each basic service to which the user(s) of the
- number subscribes, or collectively for all the basic services to
- which the user(s) subscribes. Since subscription is on an ISDN
- number basis, the same Call Forwarding subscriptions will apply to
- all terminals using this number.
-
- Note - In this service description, it is assumed that a sin-
- gle ISDN number is not shared across multiple interfaces. A single
- ISDN number may, however, be shared by multiple terminals on the
- same interface. Procedures permitting an ISDN number to be shared
- across multiple interfaces are for further study. For multiple
- access installations, it may be possible for the user to specify,
- on activation, if the service is applicable to a specific access or
- all accesses associated with that installation.
-
- The served user can request a different forwarded-to number
- for each basic service subscription parameter value to which he has
- subscribed.
-
- An indication that the CFB service is activated on a number
- may, as an option, be given to the user who has forwarding
- activated, each time an outgoing call is made. This may take the
- form of a special indication in the proceed response.
-
-
-
- Figure 2/I.252, (N), p. 7
-
-
-
-
-
- Figure 3/I.252, (N), p. 8
-
-
-
-
-
- Figure 4/I.252, (N), p. 9
-
-
-
-
-
-
-
-
-
-
- 2.2.2 Specific terminology
-
-
- A served user is a user of a particular ISDN number who is
- requesting that calls to his number be forwarded. This user may
- also be referred to as the forwarding user or the called user.
-
- A forwarded-to user is a user to whom the call shall be for-
- warded.
-
-
- 2.2.3 Qualifications on the applicability to telecommunica-
- tions services
-
-
- No restrictions identified.
-
-
- 2.3 Procedures
-
-
-
- 2.3.1 Provision/withdrawal
-
-
- CFB shall be provided after pre-arrangement with the service
- provider.
-
- The service can be offered with three subscription options.
- Options apply separately to each basic service subscribed to on
- each ISDN number. For each subscription option, only one value can
- be selected. Subscription options are summarized below:
-
-
- Subscription options Value
-
- Served user receives notification that call has been forwarded -
- No - Yes, with call offering information
- (see S 2.3.2.2) Calling user receives notification that
- his call has been forwarded - No - Yes,
- with or without forwarded-to user number Served user
- receives notification that CFB is currently activated - No
- - Yes
-
-
- 2.3.2 Normal procedures
-
-
-
- 2.3.2.1 Activation/deactivation/registration
-
-
- Same as for Call Forwarding Unconditional (CFU), see S 4.
-
-
- 2.3.2.2 Invocation and operation
-
-
-
-
-
-
-
-
-
-
- The following illustration clarifies the CFB procedures.
- Assume that A calls B1, who forwards the call to B2, . | | , Bm, .
- | | , Bx. The final receiver of the call is C.
-
-
- Figure, (N), p.
-
-
-
-
-
- 2.3.2.2.1 Served user Bm's perspective
-
-
- If CFB is active and the served user is Network Determined
- User Busy (NDUB) or User Determined User Busy (UDUB), then an
- incoming call to the served user will be forwarded. In case of
- NDUB, the call is not offered to the served user.
-
- In the case of UDUB, the call will have been offered to the
- served user. Normal call set-up information will already have been
- provided to the served user. When the forwarding attempt is
- started, the served user will receive notification that a call has
- been forwarded. No further notification is given.
-
- When an incoming call is forwarded without being offered to
- the served user (i.e. NDUB condition), the served user, as a sub-
- scription option, may receive notification of the call forwarding
- (but will not be able to answer the incoming call). This notifica-
- tion is given as soon as the forwarding attempt is started.
-
- This notification includes the following information (on the
- call that has been forwarded):
-
- 1) indication that a call has been forwarded;
-
- 2) telecommunications service information (e.g.
- bearer capability, higher layer compatibility);
-
- 3) user-to-user information;
-
- 4) Bm's number;
-
- 5) calling party number A (if CLIP applicable).
-
- If multiple forwardings have occurred and the served user is
- authorized to receive additional information, he may also receive:
-
- 6) originally called number B1;
-
- 7) cause for original forwarding;
-
- 8) last forwarding number B | m - 1);
-
- 9) cause for last forwarding.
-
-
-
-
-
-
-
-
-
-
-
- 2.3.2.2.2 Forwarded-to user C's perspective:
-
-
- The forwarded-to user C will receive an indication that the
- call has been forwarded.
-
- As an option he may also receive:
-
- 1) originally called number B1;
-
- 2) cause for original forwarding;
-
- 3) last forwarding number Bx;
-
- 4) cause for last forwarding.
-
- (Depending on the use of other supplementary services, the
- forwarded-to user C may also receive information such as the cal-
- ling party A number and user-to-user signalling. See the descrip-
- tions of interactions with other supplementary services.)
-
-
- 2.3.2.2.3 Calling user A's perpective :
-
-
- As a subscription option, the served user Bm can request that
- the calling user receive a notification that the call has been for-
- warded and, as an additional subscription option, that notification
- can include the forwarded- to number B(m+1). Transfer of the
- forwarded-to user number will not take place if number restrictions
- at the forwarded-to user exist.
-
-
- 2.3.3 Exceptional procedures
-
-
-
- 2.3.3.1 Activation/deactivation/registration
-
-
- Same as CFU (see S 4).
-
-
- 2.3.3.2 Invocation and operation
-
-
- Call forwarding applies only to subscribed basic services.
- Calls to an ISDN number requesting a basic service which is not
- subscribed to, will never be forwarded.
-
-
- Within an ISDN, or tandem ISDNs, the total number of all for-
- wardings for each call should be limited. The maximum number of
- such connections should be limited to a value between 3 and 5 for
- each call. This is to prevent infinite looping.
-
- If the limit is reached and an attempt is made to forward the
-
-
-
-
-
-
-
-
-
- call an additional time, then the forwarded call shall be treated
- as follows:
-
- If the forwarded call cannot be completed to the forwarded-to
- destination, then the network will clear the forwarded leg of the
- call. Specifically, if CFB has been invoked, and CNFR has not
- occurred, then the call would be cleared back towards the calling
- user, and the calling user would be sent a cause to indicate that
- the call has been forwarded but not completed (i.e. because of net-
- work congestion, invalid number, facility not available, etc.). If
- the forwarded call cannot be completed and if CFNR has occurred,
- then the call should only be cleared back as far as the CFNR
- exchange and the calling user will, in the case of a telephony
- call, continue to receive inband ringing tone.
-
-
- 2.3.4 Alternative procedures
-
-
-
- 2.3.4.1 Activation/deactivation/registration
-
-
- None identified.
-
-
- 2.3.4.2 Invocation and operation
-
-
- None identified.
-
-
- 2.4 Network capabilities for charging
-
-
- This Recommendation does not cover charging principles. Future
- Recommendations in the D-Series are expected to contain that infor-
- mation.
-
- It shall be possible to charge the subscriber accurately for
- the service.
-
-
- 2.5 Interworking requirements
-
-
- Same as CFU (see S 4).
-
-
- 2.6 Interaction with other supplementary services
-
-
- The ways in which Call Forwarding Busy interacts with other
- supplementary services are in general identical to the ways in
- which Call Forwarding Unconditional interacts with other supplemen-
- tary services. Thus, if the interactions are described to be "same
- as CFU", the CFU text should be taken verbatim, except that the
-
-
-
-
-
-
-
-
-
- expression "Call Forwarding Unconditional" should be replaced by
- "Call Forwarding Busy".
-
-
- 2.6.1 Call Waiting
-
-
- Calling user: same as CFU (see S 4).
-
- Called user: No interaction. That is, if the user is not NDUB,
- Call Waiting will take place. If the user is NDUB, Call Forwarding
- Busy will take place.
-
- Forwarded-to user: A forwarded call can invoke Call Waiting.
-
-
- 2.6.2 Call Transfer
-
-
- Same as CFU (see S 4).
-
-
- 2.6.3 Connected Line Identification Presentation
-
-
- Same as CFU (see S 4).
-
-
- 2.6.4 Connected Line Identification Restriction
-
-
- Same as CFU.
-
-
-
- 2.6.5 Calling Line Identification Presentation
-
-
- Same as CFU (see S 4).
-
-
- 2.6.6 Connected Line Identification Restriction
-
-
- Same as CFU (see S 4).
-
-
- 2.6.7 Closed User Group
-
-
- Same as CFU (see S 4).
-
-
- 2.6.8 Conference Calling
-
-
- Same as CFU (see S 4).
-
-
-
-
-
-
-
-
-
- 2.6.9 Direct-Dialling-In
-
-
- No impact, i.e. neither supplementary service affects the
- operation of the other supplementary service.
-
-
- 2.6.10 Call Diversion (i.e. Call Forwarding) services
-
-
-
- 2.6.10.1 Call Forwarding Busy
-
-
- Not applicable.
-
-
- 2.6.10.2 Call Forwarding No Reply
-
-
- The invocation of CFB takes precedence over CFNR.
-
-
- 2.6.10.3 Call Forwarding Unconditional
-
-
- The invocation of CFU takes precedence over CFB.
-
-
- 2.6.11 Line Hunting
-
-
- In general, Line Hunting takes precedence over CFB. Thus, CFB
- only occurs if all members of the hunt group are busy.
-
-
- 2.6.12 Three-Party Service
-
-
- Refer to Recommendation I.254, S 2.6.10, interaction with CFB.
-
-
- 2.6.13 User-to-User Signalling
-
-
- Same as CFU (S 4), except that service 2 of UUS cannot be
- guaranteed prior to completion of the Call Forwarding Busy in case
- of a user-determined-busy.
-
-
- 2.6.14 Multiple Subscriber Number
-
-
- No impact, i.e. neither supplementary service affects the
- operation of the other supplementary service.
-
-
-
-
-
-
-
-
-
-
-
- 2.6.15 Call Hold
-
-
- No impact, i.e. neither supplementary service affects the
- operation of the other supplementary service.
-
-
-
- 2.6.16 Advice of Charge
-
-
- Refer to Recommendation I.256, SS 2.1.6.10, 2.2.6.10,
- 2.3.6.10, interaction with CFB.
-
-
- 2.7 Dynamic description
-
-
- The dynamic description given in Figure 5/I.252 contains the
- descriptions of the three Call Forwarding services (CFU, CFB, and
- CFNR).
-
-
- Figure 5/I.252 (feuillet 1 sur 5), (N), p. 11
-
-
-
-
-
- Figure 5/I.252 (feuillet 2 sur 5), (N), p. 12
-
-
-
-
-
- Figure 5/I.252 (feuillet 3 sur 5), (N), p. 13
-
-
-
-
-
- Figure 5/I.252 (feuillet 4 sur 5), (N), p. 14
-
-
-
-
-
- Figure 5/I.252 (feuillet 5 sur 5), (N), p. 15
-
-
-
-
-
- 3 I.252.3 - Call Forwarding No Reply
-
-
-
-
-
-
-
-
-
-
-
-
- 3.1 Definition
-
-
- Call Forwarding No Reply (CFNR) permits a "served user" (see
- S 3.2.2) to have the network send to another number all incoming
- calls for the served user's ISDN number which meet no reply, or
- just those associated with a specific basic service which meet no
- reply. The served user's originating service is unaffected.
-
- Note - In normal situations, the CFNR service is provided on
- a per access basis. (In these situations, there is a one-to-one
- relationship between ISDN number and access.) However, the network
- may recognize multiple numbers on a single interface; in addition,
- it may not understand a complete ISDN number (e.g. DDI). In these
- cases, the CFNR service is offered on the basis of the part of the
- ISDN number which the network can recognize.
-
-
- 3.2 Definition
-
-
-
- 3.2.1 General description
-
-
- For a given ISDN number, this service (including options) may
- be subscribed to for each basic service to which the user(s) of the
- number subscribes, or collectively for all the basic services to
- which the user(s) subscribes. Since subscription is on an ISDN
- number basis, the same Call Forwarding subscriptions will apply to
- all terminals using this number.
-
- Two conditions of CFNR are possible as follows:
-
- 1) the call is offered and no indication of a com-
- patible terminal is received; or
-
- 2) the call is offered and an indication of a com-
- patible terminal is received.
-
- Only case 2) is considered here. Case 1) is for further study.
-
- Note - In this service description, it is assumed that a sin-
- gle ISDN number is not shared across multiple interfaces. A single
- ISDN number may, however, be shared by multiple terminals on the
- same interface. Procedures permitting an ISDN number to be shared
- across multiple interfaces are for further study. For multiple
- access installations, it may be possible for the user to specify,
- on activation, if the service is applicable to a specific access or
- all accesses associated with that installation.
-
- The served user can request a different forwarded-to number
- for each basic service subscription parameter value to which he has
- subscribed.
-
- An indication that the CFNR service is activated on a number
- may, as an option, be given to the user who has forwarding
-
-
-
-
-
-
-
-
-
- activated, each time an outgoing call is made. This may take the
- form of a special indication in the proceed response.
-
-
- 3.2.2 Specific terminology
-
-
- A served user | is a user of particular ISDN number who is
- requesting that calls to his number be forwarded. This user may
- also be referred to as the forwarding user or the called user.
-
- A forwarded-to user | is a user to whom the call shall be
- forwarded.
-
-
- 3.2.3 Qualifications on the applicability to telecommunica-
- tion services
-
-
- No restrictions identified.
-
-
- 3.3 Procedures
-
-
-
- 3.3.1 Provision/withdrawal
-
-
- CFNR shall be provided after pre-arrangement with the service
- provider.
-
-
- The service can be offered with four subscription options.
- Options apply separately to each basic service subscribed to an
- each ISDN number. For each subscription option, only one value can
- be selected. Subscription options are summarized below:
-
-
- Subscription options Value Served user receives notification that
- call has been forwarded - No - Yes, with
- call offering information (see S 3.3.2.2) Calling user
- receives notification that his call has been forwarded - No
- - Yes, with or without forwarded-to user number
-
-
- No reply condition timer - 5-60 seconds, in steps of 5
- seconds Served user received notification that CFNR is
- currently activated - No - Yes
-
-
- 3.3.2 Normal procedures
-
-
-
- 3.3.2.1 Activation/deactivation/registration
-
-
-
-
-
-
-
-
-
-
- Same as CFU (see S 4).
-
-
- 3.3.2.2 Invocation and operation
-
-
- The following illustration clarifies the CFNR procedures.
- Assume that A calls B1, who forwards the call to B2, . | | , Bm, .
- | | , Bx. The final receiver of the call is C.
-
-
- Figure, (N), p.
-
-
-
- 3.3.2.2.1 Served user Bm's perspective
-
-
- When CFNR is active, incoming calls will be offered to the
- served user. Normal call offering information is provided to the
- served user. If the served user does not reply within a subscribed
- time interval, the call will be forwarded. The served user, as a
- subscription option, may receive notification that a call has been
- forwarded. This notification is given as soon as the forwarding
- attempt is started. No further notification is given.
-
-
- 3.3.2.2.2 Forwarded-to user C's perspective
-
-
- The forwarded-to user C will receive an indication that the
- call has been forwarded.
-
- As an option he may also receive:
-
- 1) originally called number B1;
-
- 2) cause for original forwarding;
-
- 3) last forwarding number Bx;
-
- 4) cause for last forwarding.
-
- (Depending on the use or other supplementary services, the
- forwarded-to user C may also receive information such as the cal-
- ling party A number and user-to-user signalling. See the descrip-
- tions of interactions with other supplementary services.)
-
-
-
- 3.3.2.2.3 Calling user A's perspective
-
-
- As a subscription option, the served user Bm can request that
- the calling user receive a notification that the call has been for-
- warded and, as an additional subscription option, that notification
- can include the forwarded-to number B(m + 1). Transfer of the
-
-
-
-
-
-
-
-
-
- fowarded-to user number will not take place if number restrictions
- at the forwarded-to user exist.
-
-
- 3.3.3 Exceptional procedures
-
-
-
- 3.3.3.1 Activation/deactivation/registration
-
-
- Same as CFU (see S 4).
-
-
- 3.3.3.2 Invocation and operation
-
-
- Call forwarding applies only to subscribed basic services.
- Calls to an ISDN number requesting a basic service which is not
- subscribed to will never be forwarded.
-
- Within an ISDN, or tandem ISDNs, the total number of all for-
- wardings for each call should be limited. The maximum number of
- such connections should be limited to a value between 3 and 5 for
- each call. This is to prevent infinite looping.
-
- If the limit is reached and an attempt is made to forward the
- call an additional time, the forwarded call shall be treated as
- follows:
-
- If the forwarded call cannot be completed to the forwarded-to
- destination, then the network will clear the forwarded leg of the
- call and the calling user will, in the case of a telephony call,
- continue to receive inband ringing tone. The "no reply timer" will
- not be restarted by the network. (Note that during the activation
- of CFNR, the calling user shall continue to alert the forwarding
- user until alerting commences at the forwarded-to user.)
-
-
- 3.3.4 Alternative procedures
-
-
-
- 3.3.4.1 Activation/deactivation/registration
-
-
- None identified.
-
-
- 3.3.4.2 Invocation and operation
-
-
- None identified.
-
-
- 3.4 Network capabilities for charging
-
-
-
-
-
-
-
-
-
-
- This Recommendation does not cover charging principles. Future
- Recommendations in the D-series are expected to contain that infor-
- mation.
-
- It shall be possible to charge the subscriber accurately for
- the service.
-
-
- 3.5 Interworking requirements
-
-
- If a forwarded-to number is not within the ISDN, then an
- interworking situation is said to exist.
-
- If a forwarded call meets an interworking situation, then an
- interworking indication should be sent to the calling party. Also,
- if the network cannot determine that the forwarded call cannot be
- completed (i.e. the progress of the call is provided in-band), the
- network shall cease alerting at the diverting termination and con-
- nect the calling user to the diverted call in order to receive
- these inband supervisory indications.
-
- Note - The number of times a call has been forwarded once it
- has exited the Common Channel Signalling (CCS) network cannot be
- limited by this CCS network.
-
-
-
- 3.6 Interaction with other supplementary services
-
-
- The ways in which Call Forwarding No Reply interacts with
- other supplementary services are in general identical to the ways
- in which Call Forwarding Unconditional interacts with other supple-
- mentary services. Thus, if the interactions are described to be
- "same as CFU", the CFU text should be taken verbatim, except that
- the expression "Call Forwarding Unconditional" should be replaced
- by "Call Forwarding Busy".
-
-
- 3.6.1 Call Waiting
-
-
- Refer to Recommendation I.253, S 1.6.10, interaction with
- CFNR.
-
-
- 3.6.2 Call Transfer
-
-
- Same as CFU (see S 4).
-
-
- 3.6.3 Connected Line Identification Presentation
-
-
- Same as CFU (see S 4).
-
-
-
-
-
-
-
-
-
- 3.6.4 Connected Line Identification Restriction
-
-
- Same as CFU (see S 4).
-
-
- 3.6.5 Calling Line Identification Presentation
-
-
- Same as CFU (see S 4).
-
-
- 3.6.6 Calling Line Identification Restriction
-
-
- Same as CFU (see S 4).
-
-
- 3.6.7 Closed User Group
-
-
- Same as CFU (see S 4).
-
-
- 3.6.8 Conference Calling
-
-
- Same as CFU (see S 4).
-
-
- 3.6.9 Direct-Dialling-In
-
-
- No impact, i.e. neither supplementary service affects the
- operation of the other supplementary service.
-
-
- 3.6.10 Call Diversion (i.e. Call Forwarding) services
-
-
-
- 3.6.10.1 Call Forwarding Busy
-
-
- The invocation of CFB takes precedence over CFNR.
-
-
- 3.6.10.2 Call Forwarding No Reply
-
-
- Not applicable.
-
-
- 3.6.10.3 Call Forwarding Unconditional
-
-
- The invocation of CFB takes precedence over CFNR.
-
-
-
-
-
-
-
-
-
- 3.6.11 Line Hunting
-
-
- No impact, i.e. neither supplementary service affects the
- operation of the other supplementary service.
-
-
-
- 3.6.12 Three-Party Service
-
-
- Refer to Recommendation I.254, S 2.6.10, interaction with
- CFNR.
-
-
- 3.6.13 User-to-User Signalling
-
-
- Service 1: A CFNR subscriber who has CFNR activated should
- not respond by accepting or rejecting a User-to-User Service 1
- request until the call is answered. If a call for which
- User-to-User Service 1 was requested undergoes CFNR, User-to-User
- Service 1 will not be extended to the forwarded-to user.
-
- Service 2: An outgoing call which meets a called party with
- CFNR activated cannot use User-to-User Service 2 Service 2 will not
- be extended to the forwarded-to user.
-
- Service 3: A CFNR subscriber who has CFNR activated should
- not respond by accepting or rejecting a User-to-User Service 3
- request until the call is answered. If a call which User-to-User
- Service 3 was requested undergoes CFNR, User-to-User Service 3 may
- be extended to the forwarded-to user if the forwarding party allows
- it.
-
-
- 3.6.14 Multiple Subscriber Number
-
-
- No impact, i.e. neither supplementary service affects the
- operation of the other supplementary service.
-
-
- 3.6.15 Call Hold
-
-
- No impact, i.e. neither supplementary service affects the
- operation of the other supplementary service.
-
-
- 3.6.16 Advice of Charge
-
-
- Refer to Recommendation I.256, SS 2.1.6.10, 2.2.6.10,
- 2.3.6.10, interaction with CFNR.
-
-
-
-
-
-
-
-
-
-
-
- 3.7 Dynamic description
-
-
- Refer to the CFB dynamic description (which covers CFU, CFB,
- and CFNR) in S 2.
-
-
- 4 I.252.4 - Call Forwarding Unconditional
-
-
-
- 4.1 Definition
-
-
- Call Forwarding Unconditional (CFU) permits a "served user"
- (see S 4.2.2) to have the network send to another number all incom-
- ing calls for the served user's ISDN number (or just those associ-
- ated with a specified basic service). The served user's originating
- service is unaffected. If this service is activated, calls are for-
- warded no matter what the condition of the termination. Other Call
- Forwarding services provide for call forwarding based on condition
- e.g. Call Forwarding Busy (CFB) and Call Forwarding No Reply
- (CFNR).
-
- Note - In normal situations, the CFU service is provided on a
- per access basis. (In these situations, there is a one-to-one rela-
- tionship between ISDN number and access.) However, the network may
- recognize multiple numbers on a single interface; in addition, it
- may not understand a complete ISDN number (e.g. DDI). In these
- cases, the CFU service is offered on the basis of the part of the
- ISDN number which the network can recognize.
-
-
-
- 4.2 Description
-
-
-
- 4.2.1 General description
-
-
- For a given ISDN number, this service (including options) may
- be subscribed to for each basic service to which the user(s) of the
- number subscribes, or collectively for all the basic services to
- which the user(s) subscribes. Since subscription is on an ISDN
- number basis, the same Call Forwarding subscriptions will apply to
- all terminals using this number.
-
- Note - In this service description, it is assumed that a sin-
- gle ISDN number is not shared across multiple interfaces. A single
- ISDN number may, however, be shared by multiple terminals on the
- same interface. Procedures permitting an ISDN number to be shared
- across multiple interfaces are for further study. For multiple
- access installations, it may be possible for the user to specify,
- on activation, if the service is applicable to a specific access or
- all accesses associated with that installation.
-
-
-
-
-
-
-
-
-
-
- The served user can request a different forwarded-to number
- for each basic service subscription parameter value to which he has
- subscribed.
-
- An indication that the CFU service is activated on a number
- may, as an option, be given to the user who has Forwarding
- activated, each time an outgoing call is made. This may take the
- form of a special indication in the proceed response.
-
-
- 4.2.2 Specific terminology
-
-
- A served user is a user of a particular ISDN number who is
- requesting that calls to his number be forwarded. This user may
- also be referred to as the forwarding user or the called user.
-
- A forwarded-to user is a user to whom the call shall be for-
- warded.
-
-
- 4.2.3 Qualifications on the applicability to telecommunica-
- tion services
-
-
- No restrictions identified.
-
-
- 4.3 Procedures
-
-
-
- 4.3.1 Provision/withdrawal
-
-
- CFU shall be provided after pre-arrangement with the service
- provider.
-
- The service can be offered with three subscription options.
- Options apply separately to each basic service subscribed to on
- each ISDN number. For each subscription option, only one value can
- be selected. Subscription options are summarized below:
-
-
-
- Subscription options Value Served user receives notification that
- call has been forwarded - No - Yes, with
- call offering information (see S 4.3.2.2) Calling user
- receives notification that his call has been forwarded - No
- - Yes, with or without forwarded-to user number
- Served user receives notification that CFU is currently
- activated - No - Yes .bp
-
-
- 4.3.2 Normal procedures
-
-
-
-
-
-
-
-
-
-
-
- 4..3.2.1 ActivationB/FdeactivationB/Fregistration
-
-
- If the served user has subscribed to CFU, the served user will
- use the activation procedure.
-
- To activate CFU, the served user must supply:
-
- 1) the forwarded-to number;
-
- 2) information as to whether all calls or all calls
- of a specified basic service should be forwarded;
-
- 3) possibly the ISDN number for which CFU should
- apply.
-
- As a network option, verification of the forwarded-to number
- should be accomplished, if possible, before accepting the call for-
- warding request.
-
- When the served user so activates CFU, the service provider
- will return notification of acceptance or rejection of the request
- (see Exceptional procedures, S 4.3.3, for a list of possible causes
- for rejection).
-
- This notification will include the number of the forwarded-to
- user to whom the call forwarding is active. If a single number can
- be used by more than one terminal, activation of CFU will be possi-
- ble from any terminal which uses this number. As a service option,
- activation/deactivation may be restricted to selected terminals
- (users) (e.g. by use of a password).
-
- CFU can be deactivated in either of two ways. The user can
- specifically deactivate the CFU activation. The user can activate
- CFU for the specified basic service to another number, thus causing
- the previous invocation of CFU to be overridden.
-
-
- 4.3.2.2 Invocation and opertion
-
-
- The following illustration clarifies the CFU procedures.
- Assume that A calls B1, who forwards the call to B2, . | | , Bm, .
- | | , Bx. The final receiver of the call is C.
-
-
- Figure, (N), p.
-
-
-
- 4.3.2.2.1 Served user Bm's perspective
-
-
- When CFU is active, all incoming calls will be forwarded
- without being offered to the served user Bm. When an incoming call
- is forwarded without being offered to the served user, the served
- user, as a subscription option, may receive notification of the
-
-
-
-
-
-
-
-
-
- call forwarding (but will not be able to answer the incoming call).
- This notification is given as soon as the forwarding attempt is
- started.
-
- This notification includes the following information (on the
- call that has been forwarded):
-
- 1) indication that a call has been forwarded;
-
- 2) telecommunication service information (e.g.
- bearer capability, higher layer compatibility);
-
- 3) user-to-user information;
-
- 4) Bm's number;
-
- 5) calling party's number A (if CLIP applicable).
-
- If multiple forwardings have occurred and the served user is
- authorized to receive additional information, he may also receive:
-
- 6) originally called number B1;
-
- 7) cause for original forwarding;
-
- 8) last forwarding number B(m - 1);
-
- 9) cause for last forwarding.
-
-
-
- 4.3.2.2.2 Forwarded-to user C's perspective
-
-
- The forwarded-to User C will receive an indication that call
- has been forwarded.
-
- As an option he may also receive:
-
- 1) originally called number B1;
-
- 2) cause for original forwarding;
-
- 3) last forwarding number Bx;
-
- 4) cause for last forwarding.
-
- (Depending on the use of other supplementary services, the
- forwarded-to user C may also receive information such as the cal-
- ling party A number and user-to-user signalling. See the descrip-
- tions of interactions with other supplementary services.)
-
-
- 4.3.2.2.3 Calling user A's perspective
-
-
- As a subscription option, the served user Bm can request that
-
-
-
-
-
-
-
-
-
- the calling user receive a notification that the call has been for-
- warded and, as an additional subscription option, that notification
- can include the forwarded-to number B(m+1). Transfer of the
- forwarded-to user number will not take place if number restrictions
- at the forwarded-to user exist.
-
-
- 4.3.3 Exceptional procedures
-
-
-
- 4.3.3.1 Activation/deactivation/registration
-
-
- 4.3.3.1.1 Call Forwarding Unconditional for all basic services and
- Call Forwarding of particular basic services cannot be activated
- simultaneously.
-
- If the system cannot accept an activation request, the served
- user should receive a notification that Call Forwarding activation
- was unsuccessful. Possible causes are:
-
- i) service not subscribed;
-
- ii) forwarded-to invalid ISDN number;
-
- iii) use of an operator access prefix;
-
- iv) forwarded-to ISDN number's telecommunication
- services violate subscribed constraints (e.g. group restrictions);
-
- v) forwarded-to ISDN number is of a free number
- within the same office (i.e. a number to which no call is charge-
- able);
-
- vi) insufficient information;
-
- vii) requested telecommunication service is not
- provided to the forwarded-to ISDN number;
-
- viii) forwarded-to number is a special service code
- (e.g. police);
-
- ix) forwarded-to number is served user's number.
-
- However, the network is not required to validate information
- related to the forwarded-to user.
-
-
- 4.3.3.1.2 Deactivation
-
-
- If the user does not specify completely which CFU request is
- to be deactivated (e.g. the basic service and/or the originator's
- number), the network will reject the deactivation request with
- appropriate cause.
-
-
-
-
-
-
-
-
-
-
- If the network cannot accept a user's request for deactiva-
- tion, the cause will be returned to the user, e.g. incorrect origi-
- nation ISDN number used.
-
- If the network deactivates CFU without the served user having
- requested deactivation (e.g. when an exceptional condition occurs),
- the served user will receive notification along with the cause.
-
-
-
- 4.3.3.2 Invocation and operation
-
-
- Call forwarding applies only to subscribed basic services.
- Calls to an ISDN number requesting a basic service which is not
- subscribed to, will never be forwarded.
-
- Within an ISDN, or tandem ISDNs, the total number of all for-
- wardings for each call should be limited. The maximum number of
- such connections should be limited to a value between 3 and 5 for
- each call. This is to prevent infinite looping.
-
- If the limit is reached and an attempt is made to forward the
- call an additional time, then the forwarded call shall be treated
- as follows:
-
- If the forwarded call cannot be completed to the forwarded-to
- destination, then the network will clear the forwarded leg of the
- call. Specifically, if CFU has been invoked, then the call would
- be cleared back towards the calling user. If the call has not pre-
- viously undergone CFNR, the call will be cleared all the way back
- to the calling user and the calling user will be informed that no
- user is responding. If the call has previously undergone CFNR the
- call will only be cleared back as far as the CFNR exchange and the
- calling user will, in case of a telephony call, continue to receive
- inband ringing tone.
-
-
- 4.3.4 Alternative procedures
-
-
-
- 4.3.4.1 Activation/deactivation/registration
-
-
- None identified.
-
-
- 4.3.4.2 Invocation and operation
-
-
- None identified.
-
-
- 4.4 Network capabilities for charging
-
-
-
-
-
-
-
-
-
-
-
- This Recommendation does not cover charging principles. Future
- Recommendations in the D-Series are expected to contain that infor-
- mation.
-
- It shall be possible to charge the subscriber accurately for
- the service.
-
-
- 4.5 Interworking requirements
-
-
- If the fowarded-to number is not within the ISDN, then an
- interworking situation is said to exist.
-
- If a forwarded call meets an interworking situation, then an
- interworking indication should be sent to the calling party.
-
- Note - The number of times a call has been forwarded once it
- has exited the Common Channel Signalling (CCS) network, cannot be
- limited by the CCS network.
-
-
- 4.6 Interaction with other supplementary services
-
-
-
- 4.6.1 Call Waiting
-
-
- Calling user: No impact i.e. neither supplementary service
- affects the operation of the other supplementary service.
-
- Called user: If a called user has activated CFU, then execu-
- tion of that forwarding condition takes precedence over Call Wait-
- ing. CFU can be activated while a call is waiting without changing
- the state of the waiting call.
-
- Forwarded-to user: A forwarded call can invoke Call Waiting.
-
-
-
- 4.6.2 Call Transfer
-
-
-
- 4.6.2.1 Transfer of a Forwarded Call
-
-
- Calling user: A call which has been forwarded can be
- transferred by the calling user.
-
- Called user: No impact i.e. neither supplementary service
- affects the operation of the other supplementary service.
-
- Forwarded-to user: A call that has been transferred will be
- forwarded if the transferred-to user has CFU active and the
- appropriate forwarding conditions are met. A call which has been
-
-
-
-
-
-
-
-
-
- forwarded can by transferred by the forwarded-to user.
-
-
- 4.6.2.2 Forwarding of a Call During Transfer
-
-
- A call which is being transferred can be forwarded by the
- party to whom the call is being transferred.
-
-
- 4.6.3 Connected Line Identification Presentation
-
-
- No impact, i.e. neither supplementary service affects the
- operation of the other supplementary service.
-
-
- 4.6.4 Connected Line Identification Restriction
-
-
- No impact, i.e. neither supplementary service affects the
- operation of the other supplementary service.
-
-
- 4.6.5 Calling Line Identification Presentation
-
-
- Called user: If subscribed to, the called user can receive the
- Calling Line Identification of all calls which have been forwarded.
-
- Forwarded-to user: Forwarded-to users having subscribed to
- CLIP may receive the calling user's number. If subscribed to by the
- called user, the forwarded-to user may receive the called user's
- number when a call has been forwarded.
-
- Forwarded-to users who have subscribed to CLIP may receive the
- calling user's number if the calling user has not
- subscribed/invoked CLIR. In addition, forwarded-to users subscrib-
- ing to CLIP may also receive the original called user's number and
- the last forwarding user's number if neither has subscribed/invoked
- CLIR (e.g. if A calls B1 who forwards A to B2 who forwards A to B3
- who forwards A to C, then C will receive A, B1 and B3's number,
- unless A, B1 and B3 have restricted delivery).
-
-
- 4.6.6 Calling Line Identification Restriction
-
-
- Calling user: When the CLIR is applicable and activated, the
- Calling Line Identification will not be presented to the
- forwarded-to user unless both the forwarding and forwarded-to users
- are in the override category. In addition, if the forwarding user
- is in an override category, the calling party's number will be pro-
- vided in the call offering information. The latter is a national
- option.
-
-
-
-
-
-
-
-
-
-
-
- 4.6.7 Closed User Group
-
-
- CUG restrictions must be met on each leg of the call. In addi-
- tion, CUG restrictions must be met end-to-end. In the case of mul-
- tiple forwarding, CUG restrictions have to be met in addition at
- each intermediate forwarding point.
-
-
- Called user/forwarded-to user: When a call is forwarded, a new
- check of the CUG restrictions is made at the "forwarded-to" desti-
- nation. The CUG information sent to the "forwarded to" destination
- is the same CUG information that was sent from the originating net-
- work.
-
- Forwarding (i.e. called) user: Call forwarding can only be
- activated if CUG restrictions between the forwarding user and the
- forwarded-to user are met.
-
-
- 4.6.8 Conference Calling
-
-
- Calling user: If a conference controller attempts to establish
- a conference call and calls a user with call forwarding active, the
- forwarded-to user will be alerted and can be added to the confer-
- ence.
-
- Called user: No impact i.e. neither supplementary service
- affects the operation of the other supplementary service.
-
- Forwarded-to user: A forwarded-to user can establish a confer-
- ence using an existing forwarded call as one of the conference con-
- nections.
-
- A call, which has been forwarded, can be added to an existing
- conference by the forwarded-to user.
-
-
- 4.6.9 Direct-Dialling-In
-
-
- No impact, i.e. neither supplementary service affects the
- operation of the other supplementary service.
-
-
- 4.6.10 Call Diversion (i.e. Call Forwarding) services
-
-
-
- 4.6.10.1 Call Forwarding Busy
-
-
- The invocation of CFU takes precedence over CFB.
-
-
- 4.6.10.2 Call Forwarding No Reply
-
-
-
-
-
-
-
-
-
- The invocation of CFU takes precedence over CFNR.
-
-
- 4.6.10.3 Call Forwarding Unconditional
-
-
- Not applicable.
-
-
- 4.6.11 Line Hunting
-
-
- Calling user: No impact i.e. neither supplementary service
- affects the operation of the other supplementary service.
-
- Called user: Call Forwarding may be assignable to all or part
- of the hunting group. When forwarding is only required on part of
- the hunting group the forwarding customer must specify, at activa-
- tion, which access the service is to be invoked from. Procedures
- for the operation of this service in association with part of a
- hunt group need to be completed. In general, CFU takes precedence
- over Line Hunting.
-
- Forwarded-to user: Forwarded calls will be treated as normal
- calls when completing to a multi-line group user.
-
-
- 4.6.12 Three-Party Service
-
-
- Refer to Recommendation I.254, S 2.6.10, interaction with CFU.
-
-
-
- 4.6.13 User-to-User Signalling (UUS)
-
-
- Call originated by a user with CFU activated: Since CFU does
- not affect the forwarding user's ability to make outgoing calls, a
- user with CFU activated can send and receive user-to-user informa-
- tion (UUI) in association with an ongoing call or at the set-up of
- a new call.
-
- Call incoming to a user with CFU activated:
-
- During forwarding: Any UUI which accompanies the set-up of the
- call will be forwarded along with the forwarded call if both the
- calling and forwarding (i.e. called) parties have subscribed to
- service 1.
-
- After forwarding: If the calling party has requested UUS
- service(s) 1, 2 and/or 3 in his initial call set-up, and if the
- fowarding (i.e. called) party has subscribed to the same
- service(s), then that service (those services) will automatically
- be extended so that they are available for use between the calling
- party and the forwarded-to party. If the forwarding party does not
- subscribe to the same service (set of services), the calling party
-
-
-
-
-
-
-
-
-
- will be informed that he can no longer employ the service(s) on
- this call.
-
-
- 4.6.14 Multiple Subscriber Number
-
-
- No impact, i.e. neither supplementary service affects the
- operation of the other supplementary service.
-
-
- 4.6.15 Call Hold
-
-
- No impact, i.e. neither supplementary service affects the
- operation of the other supplementary service.
-
-
- 4.6.16 Advice of Charge
-
-
- Refer to Recommendation I.256, SS 2.1.6.10, 2.2.6.10,
- 2.3.6.10.
-
-
- 4.7 Dynamic description
-
-
- Refer to CFB dynamic description (which covers CFB, CFNR and
- CFU) in S 2.
-
-
- 5 I.252.5 - Call Deflection
-
-
- This service, having been identified, now requires further
- study; its description is not yet included.
-
-
- 6 I.252.6 - Line Hunting
-
-
-
- 6.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 - Development of Line Hunting to cover the case of hunt-
- ing on available ISDN numbers, or addresses, rather than on inter-
- faces is a possible extension of the service.
-
-
- 6.2 Description
-
-
-
-
-
-
-
-
-
-
- 6.2.1 General description
-
-
- The interfaces selected for Line Hunting may be contained
- within one node, or may encompass more than one node.
-
- It is the responsibility of the user to provide terminals to
- his interfaces for effective operation of the service. The problem
- of terminal compatibility in the Line Hunting supplementary service
- is also the responsibility of the user of the service.
-
-
-
- 6.2.2 Specific terminology
-
-
- The following specific terminology is used to describe the
- possible selection method:
-
-
- Sequential hunting A sequential search is conducted over the
- members of the group in a fixed pre-specified order Uniform distri-
- bution An equal distribution of calls is provided to idle members
- of the group
-
- The actual algorithm for each hunting method is a network pro-
- vider option.
-
- Note - The status of an individual channel may be included in
- the selection criteria above.
-
- The selection of an interface is based on the availability of
- information channels rather than on the NDUB status. As part of
- each applicable bearer service or teleservice, there is already an
- option specifying the maximum number of information channels which
- can be used on the interface for each ISDN number, all ISDN numbers
- or subsets of ISDN numbers.
-
-
- 6.2.3 Qualifications on the applicability to telecommunica-
- tion services
-
-
- This supplementary service is considered meaningful when
- applied to the speech and 3.1 kHz audio bearer services and to the
- Telephony teleservice. Furthermore, it may also be meaningful when
- applied to other services.
-
-
- 6.3 Procedures
-
-
-
- 6.3.1 Provision/withdrawal
-
-
- Line Hunting is offered, with possible subscription options,
-
-
-
-
-
-
-
-
-
- as a service to the called party and applied to an ISDN number. For
- each subscription the following are specified:
-
-
- Subscription options Values Selected Method - Sequential
- - Uniform Members - List of 2 or
- more interfaces
-
-
- 6.3.2 Normal procedures
-
-
-
- 6.3.2.1 Activation/deactivation/registration
-
-
- Line Hunting is activated on provision and deactivated on
- withdrawal.
-
-
- 6.3.2.2 Invocation and operation
-
-
- An incoming call to an ISDN number on which Line Hunting is in
- operation will be offered to a specific available interface in a
- pre-defined manner. The selection of the specified interface may
- provide for a uniform distribution of calls or sequential distribu-
- tion of calls.
-
- The method of selecting the interface may be either Sequential
- Hunting or Uniform Distribution. The selection algorithm may
- include reference to the channel status.
-
- Once an interface has been selected, normal call set-up pro-
- cedures apply and Line Hunting procedures are considered complete.
-
- Outgoing calls from a Line Hunting Group are unaffected by
- this service.
-
-
-
- 6.3.3 Exceptional procedures
-
-
-
- 6.3.3.1 Activation/deactivation/registration
-
-
- None identified.
-
-
- 6.3.3.2 Invocation and operation
-
-
- If no interface is available, the Line Hunting service is
- unsuccessful and a busy indication is returned to the calling sub-
- scriber.
-
-
-
-
-
-
-
-
-
- If no compatible terminal on a selected interface responds, no
- further line hunting action is provided and the call is released in
- the normal manner.
-
- If the offered call is rejected at an interface, the call is
- released with normal procedures. No further hunting is provided.
-
-
- 6.3.4 Alternative procedures
-
-
-
- 6.3.4.1 Activation/deactivation/registration
-
-
- None identified.
-
-
- 6.3.4.2 Invocation and operation
-
-
- None identified.
-
-
- 6.4 Network capabilities for charging
-
-
- This Recommendation does not cover charging principles. Future
- Recommendations in the D-Series are expected to contain that infor-
- mation.
-
- It shall be possible to charge the subscriber accurately for
- the service.
-
-
- 6.5 Interworking requirements
-
-
- The possibility of a line hunting group including both ISDN
- and non-ISDN interfaces for a particular Line Hunting service
- should be considered. This is for futher study.
-
-
- 6.6 Interaction with other supplementary services
-
-
-
- 6.6.1 Call Waiting
-
-
- The Call Waiting service should not be provided to a line in a
- hunt group.
-
-
- 6.6.2 Call Transfer
-
-
-
-
-
-
-
-
-
-
-
- No impact, i.e. neither supplementary service affects the
- operation of the other supplementary service.
-
-
- 6.6.3 Connected Line Identification Presentation
-
-
- No impact, i.e. neither supplementary service affects the
- operation of the other supplementary service.
-
-
- 6.6.4 Connected Line Identification Restriction
-
-
- No impact, i.e. neither supplementary service affects the
- operation of the other supplementary service.
-
-
- 6.6.5 Calling Line Identification Presentation
-
-
- No impact, i.e. neither supplementary service affects the
- operation of the other supplementary service.
-
-
-
- 6.6.6 Calling Line Identification Restriction
-
-
- No impact, i.e. neither supplementary service affects the
- operation of the other supplementary service.
-
-
- 6.6.7 Closed User Group
-
-
- When a free line of a Line Hunting Group has been found, any
- CUG restrictions must be met before the connection will be esta-
- blished.
-
-
- 6.6.8 Conference Calling
-
-
- No impact, i.e. neither supplementary service affects the
- operation of the other supplementary service.
-
-
- 6.6.9 Direct-Dialling-In
-
-
- No impact, i.e. neither supplementary service affects the
- operation of the other supplementary service.
-
-
- 6.6.10 Call Diversion (i.e. Call Forwarding) services
-
-
-
-
-
-
-
-
-
-
- 6.6.10.1 Call Forwarding Busy (CFB)
-
-
- If the outcome of the Line Hunting supplementary service is
- unsuccessful (see S 6.3.3.2 above), CFB may be invoked.
-
-
- 6.6.10.2 Call Forwarding No Reply
-
-
- No impact, i.e. neither supplementary service affects the
- operation of the other supplementary service.
-
-
- 6.6.10.3 Call Forwarding Unconditional
-
-
- When the CUF and Line Hunting supplementary services are both
- subscribed to on the same ISDN number, the CFU supplementary ser-
- vice takes priority. Further information is contained in the CUF
- definition in S 4.
-
-
- 6.6.11 Line Hunting
-
-
- Not relevant.
-
-
- 6.6.12 Three-Party Service
-
-
- No impact, i.e. neither supplementary service affects the
- operation of the other supplementary service.
-
-
- 6.6.13 User-to-User Signalling
-
-
- No impact, i.e. neither supplementary service affects the
- operation of the other supplementary service.
-
-
- 6.6.14 Multiple Subscriber Number
-
-
- For further study.
-
-
- 6.6.15 Call Hold
-
-
- No impact, i.e. neither supplementary service affects the
- operation of the other supplementary service.
-
-
- 6.6.16 Advice of Charge
-
-
-
-
-
-
-
-
-
- No impact, i.e. neither supplementary service affects the
- operation of the other supplementary service.
-
-
-
- 6.7 Dynamic description
-
-
- The dynamic description of this service is contained in
- Figure 6/I.252.
-
-
- Figure 6/I.252, (N), p.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-