delim @@
| 5i'
CALL COMPLETION SUPPLEMENTARY SERVICES
1 Call waiting
1.1 General
This Recommendation provides information on the functions in ISDN entities and the information flows between the entities which are required to provide the call waiting supplementary service.
The call waiting supplementary service will permit a subscriber to be notified of an incoming call (as per basic call procedures) with an indication that no interface information channel is available.
The user then has the choice of accepting, rejecting or ignoring the waiting call (as per basic call procedures).
Recommendation Q.83
Fascicle VI.1 -- Rec. Q.83 1
1.2 Description
1.2.1 General description
The ISDN call waiting service allows notification to subscriber B of the incoming call to be out-of-band and this is the assumed case for this definition. In addition, as a service provider option audible in-band indications may be provided.
Where this option is provided, the application of in-band indications, in relation to particular call types and channels, is for further study. Where applied, tones should be in accordance with Recommendation E.180.
The maximum number of calls that can be handled (e.g. active, held, alerting, waiting) for each ISDN number on a given interface is specified at subscription time.
1.2.2 Qualifications on the applicability to telecommunication services
This supplementary service is considered meaningful when applied to the telephony teleservice, speech and 3.1 kHz audio bearer services. Furthermore, it may also be meaningful when applied to other services.
|
1.3 |
Derivation of the functional model for call waiting service The model used for illustrating the call waiting supplementary service procedures is given below: FIGURE, p. CCA is the functional entity that serves the user and is responsible for initiating functional requests and |
interacting with the network. CC is the functional entity within the network that cooperates with its peers to provide the services requested by CCA.
r1and r2are relationships between functional entities wherein information flows occur in order to process call attempts on service requests.
|
1.4 |
Information flow diagrams This paragraph contains the information flow diagram for the successful sequences of call waiting. The following flow diagrams are identified: -- Figure 1-1/Q.83: call waiting notification: case 1; -- Figure 1-2/Q.83: call waiting notification: case 2; -- Figure 1-3/Q.83: call waiting notification: case 3; |
||
|
2 |
Fascicle VI.1 -- Rec. Q.83 |
-- Figure 1-4/Q.83: call waiting acceptance by clearing the A call: case 1;
|
-- -- -- -- -- |
Figure 1-5/Q.83: Figure 1-6/Q.83: Figure 1-7/Q.83: Figure 1-8/Q.83: Figure 1-9/Q.83: |
call waiting acceptance by clearing the A call: case 2; call waiting acceptance by holding the A call: case 1; call waiting acceptance by holding the A call: case 2; call waiting rejection; call waiting cancellation. Fascicle VI.1 |
-- Rec. Q.83 3 |
1.4.1 Call waiting terminology
Throughout the stage 2 description the following terminology will be used:
i) Subscriber B: This is the subscriber who is provided by the network with call waiting service on a particular interface.
|
ii) iii) iv) |
User at B: This is the one user who reacts to the call waiting at B. User C: This is the user who has originated a call to B which causes the call waiting service to be One user at A: This represents a user who is engaged in a call with a user at B (this call can be in any |
|
|
state). v) |
Information channel control: A terminal that has information channel control is active on a call, is alerting |
for an incoming call, has an outgoing call in a state following or including the outgoing call proceeding state, or has a call on hold with reservation.
1.4.2 Call waiting procedures with successful outcome
The call waiting procedures with successful outcome are hereafter described by means of generic information flow diagrams.
1.4.2.1 Call waiting notification
The call waiting notification procedures are given in Figures 1-1/Q.83 to 1-3/Q.83.
Two categories are identified:
i) Figures 1-1/Q.83 and 1-2/Q.83 describe the case where the served user is notified of an incoming call and the network requires an interface channel to his user access and it has detected that all information channels are in use (no information channel available).
ii) Figure 1-3/Q.83 describes the case where the served user is notified of an incoming call and the network requires an interface channel to his user access and it has detected that an existing free information channel, which is the only compatible terminal, is in the busy condition (information channel available).
The following procedures are valid for call waiting with no information channel available.
When an incoming call from a user C arrives at the functional entity controlling the access at B and encounters the channel's busy condition and the network determined user busy conditions do not result, then the call shall be offered to B by means of the Setup procedure with the ``no information channel'' indicated.
The following actions will be taken by the terminals connected to the user B access:
i) Incompatible terminals will not react.
ii) Terminals not presently controlling the information channel that are compatible with the incoming call will respond by initiating the release procedure indicating a no information circuit/channel available condition.
iii) Terminals presently controlling the information channel that do not support the call waiting service and are compatible with the incoming call will respond either by initiating the release procedure indicating a user busy condition or by acting as incompatible terminals (e.g. no reaction).
iv) Terminals presently controlling the information channel that support the call waiting service and that are compatible with the incoming call will respond by initiating the call progress (reporting) procedure and will give a local alert to the human user by giving an audible and/or visual (in-band) indication.
When a positive response is received from the terminals at B within the normal basic call period, that (those) user(s) is (are) being informed about the incoming call, then the calling user at C will be given an indication that the 4 Fascicle VI.1 -- Rec. Q.83
called user(s) is (are) being informed. This will be performed by the network at the B side by sending of the ringing tone; some networks may instead generate a special call waiting tone, provided the bearer capability is either speech or audio 3.1 kHz. In addition, optionally, a call waiting out of band indication may be sent to the C user.
Case 1 : Both B Channels busy, one terminal controlling a B Channel supports call waiting.
Fascicle VI.1 -- Rec. Q.83 5
|
from |
Figure 1-1/Q.83 shows the generic information flow diagram for call waiting notification when the incoming call user C is delivered at the user B access by broadcast data link without available information channels. The following user B access terminals are assumed: -- TE1: Being a compatible terminal not supporting call waiting occupying channel B |
|
|
1and having a call |
reference CR1. This terminal is assumed to be located in FE6.
-- TE2: Being a compatible terminal not presently controlling the information channel. This terminal is assumed to be located in FE6`.
-- TE3: Being a compatible terminal supporting call waiting, occupying channel B2and having a call reference CR2. This terminal is assumed to be located in FE6".
The new incoming call from C is assumed to have a call reference CR3.
Case 2 : Both B Channels busy, both terminals controlling the B Channels support call waiting.
Figure 1-2B/FQ.83 shows the generic information flow diagram for call waiting notification when the incoming call from user C is delivered at the user B access by broadcast data link without available information channels.
The following user B access terminals are assumed.
-- TE1: Being a compatible terminal supporting call waiting occupying channel B1and having a call reference CR1. This terminal is assumed to be located in FE6.
-- TE2: Being a compatible terminal not presently controlling the information channel. This terminal is assumed to be located in FE6`.
-- TE3: Being a compatible terminal supporting call waiting, occupying channel B2and having a call reference CR2. This terminal is assumed to be located in FE6".
The new incoming call from C is assumed to have a call reference CR3.
Case 3 : One B Channel busy, the terminal controlling the busy B Channel supporting call waiting.
Figure 1-3/Q.83 shows the generic information flow diagram for call waiting notification when the incoming call from user C is delivered at the user B access by broadcast data link with an available information channel, but the only compatible terminal is presently controlling an information channel.
If the thus compatible terminal has call waiting facilities available, it alerts its user (audible or visible indication) and notifies the network (REPORT). The user then can decide whether to accept the waiting call or not.
1.4.2.2 Call waiting acceptance
If a user at B requests, within a specified period, to connect to the waiting call, two procedures may be required by user B with regard to the active call with a user at A.
i) Procedure one will terminate the specified active call with a user at A, while the call between a user at C and the user at B is completed in the normal manner (see Figures 1-4/Q.83 and 1-5/Q.83).
ii) Procedure two will place the specified active call with a user at A into a held state, while the call between a user at C and the user at B will be completed in the normal manner. The previously active call between a user at A and the user at B is put into the held state. From this state other supplementary services, for example, three party service may be used (see Figures 1-6/Q.83 and 1-7/Q.83).
This acceptance provokes the initiation of a Hold sequence by the terminal to the network. The network will hold the previous call between a user at A and the user at B, while the waiting call from a user at C will be connected by a Setup responseB/Fconfirm sequence.
Since more than one terminal controlling the information channels can respond positively to a call waiting offering, the network will subsequently apply a clear procedure to the remaining terminals having responded positively after having received the Setup response/confirmation order.
6 Fascicle VI.1 -- Rec. Q.83
Figure 1-1/Q.83, p. 2 Fascicle VI.1 -- Rec. Q.83 7
Figure 1-2/Q.83, p. 3 8 Fascicle VI.1 -- Rec. Q.83
Figure 1-3/Q.83, p. 4 Fascicle VI.1 -- Rec. Q.83 9
Figure 1-4/Q.83, p. 5 10 Fascicle VI.1 -- Rec. Q.83
Figure 1-5/Q.83, p. 6 Fascicle VI.1 -- Rec. Q.83 11
Figure 1-6/Q.83, p. 7 12 Fascicle VI.1 -- Rec. Q.83
Figure 1-7/Q.83, p. 8 Fascicle VI.1 -- Rec. Q.83 13
1.4.2.3 Call waiting rejection
The user at B can also, within the specified period, reject the new incoming call from user C. In this case, call clearing procedures (see Figure 1-8/Q.83) will apply at the basic access interface.
If the terminals controlling the information channels have initiated the Report (alerting) procedures, the network will wait after the reception of the first release sequence from a terminal for the possible reaction of the other terminal. If all the users reject the waiting call, the network shall initiate the clearing of the call indicating the user determined busy condition of the called users to the calling user C.
1.4.2.4 Call waiting notification ignored
If the specified period expires without any acceptance from B of the incoming call, then the network shall inform B of this situation and also inform C that this call cannot be connected.
Normal release applies to the call attempt from C by sending an appropriate clearing indication to the calling user (see Figure 1-9/Q.83).
A rejection of the waiting call by one terminal will not stop the call waiting timer, as another terminal may accept the waiting call within the specified period.
1.5 SDL diagrams for functional entities
This section contains the SDL diagrams for the network function entity FE5. The entire SDL is a variation of the basic call r2-r1CALL SENT state.
The relationships ``r1'' and ``r2'' have been deleted in functional entity FE5 between functional entities FE4 (r2) and FE6 (r1). (See § 1.3.)
1.6 Functional entity actions
The functional entity actions are identical to the actions required for the circuit mode switched bearer services speech, 3.1 kHz audio unrestricted and alternate speech/unrestricted information transfer.
14 Fascicle VI.1 -- Rec. Q.83
Blanc
Fascicle VI.1 -- Rec. Q.83 15
Figure 1-8/Q.83, p. 9 16 Fascicle VI.1 -- Rec. Q.83
Figure 1-9/Q.83, p. 10 Fascicle VI.1 -- Rec. Q.83 17
Figure 1-10/Q.83 (feuillet 1 sur 7), p. 11 18 Fascicle VI.1 -- Rec. Q.83
Figure 1-10/Q.83 (feuillet 2 sur 7), p. 12 Fascicle VI.1 -- Rec. Q.83 19
Figure 1-10/Q.83 (feuillet 3 sur 7), p. 13 20 Fascicle VI.1 -- Rec. Q.83
Figure 1-10/Q.83 (feuillet 4 sur 7), p. 14 Fascicle VI.1 -- Rec. Q.83 21
Figure 1-10/Q.83 (feuillet 5 sur 7), p. 15 22 Fascicle VI.1 -- Rec. Q.83
Figure 1-10/Q.83 (feuillet 6 sur 7), p. 16 Fascicle VI.1 -- Rec. Q.83 23
Figure 1-10/Q.83 (feuillet 7 sur 7), p. 17 24 Fascicle VI.1 -- Rec. Q.83
1.7 Allocation of functional entities to physical locations
The following allocation of functional entities to physical locations of the call waiting supplementary service are applicable:
i) Case 1
FE1 FE3 FE4 FE5 FE6
FE2 <ACCESS> FE7 <NETWORK> FE8 <NETWORK> LE <ACCESS> TE
TE LE TR
FE1, FE2 and FE6 are the functional entities which represent the users of the call waiting supplementary service (e.g. may be physically located in TE or NT2 equipment). FE1 represents user A, FE2 user C and FE6 user B. FE6 is the service requesting terminal and FE1 and FE2 the remote terminals.
FE3, FE4, FE5, FE7 and FE8 are the functional entities which represent the network functions.
FE5 represents the network access providing exchange, FE4 and FE8 the transit exchanges, FE3 and FE7 the remote local exchanges.
ii) Case 2
FE1 FE3 FE4 FE5 FE6
FE2 <ACCESS> FE7 <NETWORK> FE8 <ACCESS> NT2 <ACCESS> TE
TE LE LE (PRA) (BA)
FE1, FE2, FE5 AND FE6 are the functional entities which represent the users of the call waiting supplementary service. FE1 represents user A, FE2 user C.
FE6 is the service requesting terminal while FE5 represents the service providing NT2.
FE3, FE4, FE7 and FE8 are the functional entities which represent the local network functions.
iii) Case 3
FE1 FE3 FE4 FE5
FE2 <ACCESS> FE7 <ACCESS> FE8 <NETWORK> LE <ACCESS> FE6
TE NT2 LE
FE1, FE2, FE3, FE6 and FE7 are the functional entities which represent the users of the call waiting supplementary service. FE1 and FE3 represent user A, FE2 and FE7 represent user C while FE6 represents user B.
FE6 is the service requesting terminal, FE1 and FE2 the remote terminals and FE3 and FE7 the remote NT2s.
FE4, FE5 and FE8 are the functional entities which represent the local network functions.
iv) Case 4
FE1 FE3 FE4 FE5
FE2 <ACCESS> FE7 <NETWORK> FE8 <ACCESS> NT2 <ACCESS> FE6
NT2 LE LE
FE1, FE2, FE5 and FE6 are the functional entities which represent the users of the call waiting supplementary service. FE1 represents user A, FE2 user C and FE5 and FE6 user B, FE6 being the service requesting terminal.
FE5 being the service providing NT2 and FE1 and FE2 the remote terminals.
Fascicle VI.1 -- Rec. Q.83 25
FE3, FE4, FE7 and FE8 are the functional entities which represent the local network functions.
v) Case 5
FE1 FE3 FE4 FE5
FE2 <ACCESS> FE7 <NETWORK> FE8 <ACCESS> TE
TE/NT2 LE
FE1, FE2 and FE5 are the functional entities which represent the users of the call waiting supplementary service. FE1 represents user A, FE2 user C and FE5 and FE6 user B, FE5 is as well as the service requesting as the service providing terminal while FE1 and FE2 are the remote terminals/NT2s.
FE3, FE4, FE7 and FE8 are the functional entities which represent the local network functions.
2.1 Introduction
References: CCITT Recommendation I.253, § 2, Call hold (Stage 1) Service description.
This paragraph includes treatment of the network options as described in the Stage 1 service description. Specifically, (1) optional notification to the held party indicating that the call has been placed on hold, and (2) optional notification to the held party that a call has been retrieved.
26 Fascicle VI.1 -- Rec. Q.83
2.1.1 Definition
The call hold service allows a user to interrupt communications on an existing call/connection and then subsequently, if desired, re-establish communications. A B Channel may or may not be reserved after the communication is interrupted to allow the origination or possible termination of other calls. Reservation must be provided by the service provider as a user option. The Call Hold service includes the Retrieve operation which re-establishes communication on a B Channel between the served user and the held party.
|
2.2 2.2.1 |
Definition of functional model Functional model description Figure 2-1/Q.83, p. r, along with its subscripts, represents different information flow relationships between functional entities. FE3 |
and FE4 are shown as dashed circles to represent their optional nature in the context of the Call Hold Service.
2.2.1.1 Description of functional entity 1
Functional entity 1 supports the following functionality:
1) access the service providing capabilities of functional entity 2 by way of functional service requests (e.g., hold request, retrieve request);
2) receive functional indications relating to the call from functional entity 2 and relay them to the ``user'' of the call (e.g., hold confirmation, retrieve confirmation).
2.2.1.2 Description of functional entity 2
Functional entity 2 supports the following functionality:
1) receive the functional service requests from functional entity 1 and relay them into the network (e.g., receive the hold request from functional entity 1 and relay an optional notification of the held call toward user B);
2) perform the holding function (functional entity action 201);
3) send functional indications relating to the call to functional entity 1 (e.g., hold confirmation, retrieve confirmation);
4) reserve an information channel, if reservation is subscribed to (functional entity action 203);
The applicability of the hold service a ``call'' versus a ``connection'' requires further study.
The applicability of this service definition to other access resources (e.g., H-channels, logical channels) for
other services requires further study.
Fascicle VI.1 -- Rec. Q.83 27
5) perform reservation management (functional entity action 204);
6) perform the retrieve function (functional entity action 202).
28 Fascicle VI.1 -- Rec. Q.83
2.2.1.3 Description of functional entity 3
Functional entity 3 supports the following functionality:
1) receive the optional notification of call hold and the optional notification of retrieval and relay them toward functional entity 4;
2) identify the call at the FE3/FE4 interface that the optional notifications apply to (functional entity action 205).
2.2.1.4 Description of functional entity 4
Functional entity 4 supports the following functionality:
|
1) 2.2.2 |
receive the optional notification of call hold and the optional notification of retrieval and inform (relay them Relationship to basic service |
|
|
Figure 2-2/Q.83, p. |
The call control agent (CCA) is the functional entity that serves the user and is responsible for initiating functional requests and interacting with the network. Call control (CC) is performed by functional entities within the network to provide the services requested by the CCA.
Fascicle VI.1 -- Rec. Q.83 29
Blanc
30 Fascicle VI.1 -- Rec. Q.83
2.3 Information flow description
|
2.3.1 |
Information flow diagram for successful operation |
Figure 2--3/Q.83, p. |
2.3.2 Definition of individual information flows
|
2.3.2.1 Hold request 2.3.2.1.1 Meaning of hold request Hold request is the information sent from FE1 to FE2 to request that a call be placed on hold by the network. 2.3.2.1.2 Information content for hold request |
Fascicle VI.1 -- Rec. Q.83 31
The following information is contained in the hold request:
-- an identifier of the call to which the hold request applies. 32 Fascicle VI.1 -- Rec. Q.83
2.3.2.2 Hold confirmation
2.3.2.2.1 Meaning of hold confirmation
Hold confirmation is the information sent from FE2 to FE1 that confirms that a call has been put on hold for the user by the network.
2.3.2.2.2 Information content for hold confirmation
The following information is contained in the hold confirmation:
-- an identifier of the call to which the hold confirmation applies.
2.3.2.3 (Optional) notification of hold
2.3.2.3.1 Meaning of (optional) notification of hold
(Optional) notification of hold is the information sent from FE2 towards B indicating that the call between FE1 and FE2 has been placed on hold.
|
2.3.2.3.2 Information content for (optional) notification of hold The following information is contained in the (optional) notification of hold: -- an identifier of the call to which the (optional) notification of hold applies. 2.3.2.4 Retrieve request 2.3.2.4.1 Meaning of retrieve request |
Retrieve request is the information sent from FE1 to FE2 to request the reconnection of a held call.
2.3.2.4.2 Information content for retrieve request
|
The following information is contained in the retrieve request: -- an identifier of the call to which the retrieve request applies; -- an optional indication that: 1) any channel is acceptable for retrieval, or 2) a specified channel is preferred for retrieval, or 3) a specified channel is exclusively required for retrieval. |
Fascicle VI.1 -- Rec. Q.83 33 |
2.3.2.5 Retrieve confirmation
2.3.2.5.1 Meaning of retrieve confirmation
Retrieve confirmation is the information sent from FE2 to FE1 that confirms that communications was able to be re-established and that the held call is now reconnected. If an optional indication concerning the B channel over which communications was to have been re-established was included in the retrieve request, then the retrieve confirmation serves as an acknowledgement that retrieval was carried out as requested.
2.3.2.5.2 Information content for retrieve confirmation
The following information is contained in the retrieve confirmation:
-- an identifier of the call to which the retrieve confirmation applies;
-- an identifier of the channel over which the held call is reconnected.
2.3.2.6 (Optional) notification of retrieval
2.3.2.6.1 Meaning of (optional) notification of retrieval
(Optional) notification of retrieval is the information sent from FE2 towards B indicating that the B channel between FE1 and FE2 has been reconnected.
34 Fascicle VI.1 -- Rec. Q.83
|
2.3.2.6.2 Information content for (optional) notification of retrieval The following information is included in the (optional) notification of retrieval: -- an identifier of the call to which the (optional) notification of retrieval applies. 2.4 Functional entity actions |
|
-- -- -- -- |
201 202 203 204 |
-- -- -- -- |
Perform the holding function Perform the retrieve function Perform the reservation function Perform the reservation management to insure that: |
When a user (as identified by a terminal, other possibilities for further study) places a call on hold and reservation applies, a B channel should always be available on that user's interface for the user to retrieve that call from hold; or setup, retrieve, or connect to another call. One B channel should be kept available for the user as long as the user: (i) has one or more calls on hold with reservation and, (ii) is not currently connected to any other call. That is, the network should not reserve more than one B channel for a user, regardless of how a user is defined (as identified by a terminal, other possibilities for further study).
-- 205 -- identify the call at the FE3/FE4 interface that the optional notifications apply to.
2.5 SDL diagrams for functional entities
The SDL diagrams for functional entities 1, 2, 3 and 4 are shown in Figures 2-4/Q.83, 2-5/Q.83, 2-6/Q.83 and 2-7/Q.83.
Fascicle VI.1 -- Rec. Q.83 35
Blanc
36 Fascicle VI.1 -- Rec. Q.83
Figure 2-4/Q.83 (feuillet 1 sur 2), p. 21 Fascicle VI.1 -- Rec. Q.83 37
Figure 2-4/Q.83 (feuillet 2 sur 2), p. 22 38 Fascicle VI.1 -- Rec. Q.83
Figure 2-5/Q.83 (feuillet 1 sur 2), p. 23 Fascicle VI.1 -- Rec. Q.83 39
Figure 2-5/Q.83 (feuillet 2 sur 2), p. 24 40 Fascicle VI.1 -- Rec. Q.83
|
Figure 2-6/Q.83, p. 25 Figure 2-7/Q.83, p. 26 |
Fascicle VI.1 -- Rec. Q.83 41
2.6 Network physical allocation scenarios
H.T. [T1.83]
center box; lw(36p) | lw(12p) | lw(24p) | lw(24p) | lw(24p) | lw(12p) . FE1 FE2 FE3 FE4 _ lw(36p) | lw(12p) | lw(24p) | lw(24p) | lw(24p) | lw(12p) . Scenario 1 TE LE LE TE lw(36p) | lw(12p) | lw(24p) | lw(24p) | lw(24p) | lw(12p) . Scenario 2 TE NT2 NT2 TE lw(36p) | lw(12p) | lw(24p) | lw(24p) | lw(24p) | lw(12p) . Scenario 3 TE LE NT2 TE lw(36p) | lw(12p) | lw(24p) | lw(24p) | lw(24p) | lw(12p) . Scenario 4 TE NT2 LE TE
Table [T1.83], p. 3 Completion of call to busy subscriber
Under study.
42 Fascicle VI.1 -- Rec. Q.83
Fascicle VI.1 -- Rec. Q.83 43