home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Standards
/
CD2.mdf
/
ccitt
/
1992
/
q
/
q83.asc
< prev
next >
Wrap
Text File
|
1991-12-31
|
35KB
|
1,465 lines
Recommendation Q.83 - Call completion supplementary services
Page
1. Call waiting................................................... 6
2. Call hold...................................................... 29
3. Completion of call to busy subscriber (CCBS) (under study)..... 41
(3247)
- 2 -
AP IX-98-E
Recommendation Q.83
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).
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.
(3247)
- 3 -
AP IX-98-E
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:
USER A USER B
CCA: CC: CC: CC: CCA:
Call control Call control Call control Call control Call control
agent functions functions functions agent
functions functions
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.
r1 and r2 are relationships between functional entities wherein
information flows occur in order to process call attempts on service requests.
1.4 Information flow diagrams
This section 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;
- Figure 1-4/Q.83: call waiting accceptance by clearing the
A call: case 1;
- Figure 1-5/Q.83: call waiting acceptance by clearing the
A call: case 2;
- Figure 1-6/Q.83: call waiting acceptance by holding the
A call: case 1;
(3247)
- 4 -
AP IX-98-E
- Figure 1-7/Q.83: call waiting accceptance by holding the
A call: case 2;
- Figure 1-8/Q.83: call waiting rejection;
- Figure 1-9/Q.83: call waiting cancellation.
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) User at B: This is the one user who reacts to the call waiting
at B.
iii) User C: This is the user who has originated a call to B which
causes the call waiting service to be invoked.
iv) 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).
(3247)
- 5 -
AP IX-98-E
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
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.
Figure 1-1/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 without available information channels.
The following user B access terminals are assumed:
- TE1: Being a compatible terminal not supporting call waiting
occupying channel B1 and having a call reference
CR1. This terminal is assumed to be located in
FE6.
(3247)
- 6 -
AP IX-98-E
- 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 B2 and 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-2/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 without available information channels.
The following user B access terminals are assumed.
- TE1: Being a compatible terminal supporting call waiting
occupying channel B1 and 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 B2 and 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).
(3247)
- 7 -
AP IX-98-E
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
response/confirm 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.
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 - r1 CALL SENT state.
The relationships "r1" and "r2" have been deleted in functional entity
FE5 between functional entities FE4 (r2) and FE6 (r1), see section 3.1.3.
(3247)
- 8 -
AP IX-98-E
Note 1 - If the call waiting flag is set then the "no information channel"
indication should be included. When not set, normal call offering procedures apply.
Depending on the terminal configuration the set up message will be delivered by
point-to-point or by broadcast data link.
Note 2 - When user network interface channels are free and the call waiting
service is subscribed, some implications may occur with regard to channel
negotiation procedure complications, in particular with exclusive channel negotiation.
Note 3 - This is a substate of the "r2 - r1 CALL SENT" state of the basic
service description.
Note 4 - This timer is the same as for the basic call service.
Note 5 - Other possible supplementary services may apply; e.g. CCBS, CFB.
(3247)
- 9 -
AP IX-98-E
Note 1 - Optionally compatible busy terminals not having call waiting may not
respond.
Note 2 - Timer 1 expiration is dependent on terminal configuration being either
point-to-point or broadcast link.
Note 3 - This is a substate of the "r2 - r1 CALL SENT" state of the basic
service description.
Note 4 - The status may either indicate "USER BUSY" (for compatible busy
terminals not having call waiting); or "no-circuit-or-channel available" (for free
compatible terminal).
Note 5 - If the call waiting flag is not set this is the normal call service
supervision timer which controls the time-out for Report (Alert) without receipt
of the setup confirmation, and specifies the period the network will wait for a
response, from party B, to the offered call from user C.
(3247)
- 10 -
AP IX-98-E
Note - This is a substate of the "r2 - r1 CALL SENT" state of the basic service
description.
(3247)
- 11 -
AP IX-98-E
Note 1 - Timer 2 is not stopped and supervises the receipt of the consequent set
up confirmation.
Note 2 - This is a substate of the "r2 - r1 CALL SENT" state, of the basic service
description.
(3247)
- 12 -
AP IX-98-E
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.
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 FE6
FE2 <ACCESS> FE7 <ACCESS> FE8 <NETWORK> LE <ACCESS>
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.
(3247)
- 13 -
AP IX-98-E
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.
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. Call hold
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.
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.
───────────
* Note - The applicability of the hold service to a "call" versus a
"connection" requires further study.
** Note - The applicability of this service definition to other access
resources (e.g., H-channels, logical channels) for other services requires further
study.
2.2 Definition of functional model
(3247)
- 14 -
AP IX-98-E
2.2.1 Functional model description
FIGURE 2-1/Q.83
Functional model
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);
5) perform reservation management (Functional Entity action 204);
6) perform the retrieve function (Functional Entity action 202).
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
(3247)
- 15 -
AP IX-98-E
notifications apply to (Functional Entity action 205).
2.2.1.4 Description of Functional Entity 4
Functional Entity 4 supports the following functionality:
1) receive the optional notification of call hold and the optional
notification of retrieval and inform (relay them to) user B.
2.2.2 Relationship to Basic Service
FIGURE 2-2/Q.83
Relationship to basic service
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.
2.3 Information flow description
2.3.1 Information flow diagram for successful operation
(3247)
- 16 -
AP IX-98-E
FIGURE 2-3/Q.83
Information flow diagram for call hold service
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
The following information is contained in the Hold Request:
- an identifier of the call to which the Hold Request applies.
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.
(3247)
- 17 -
AP IX-98-E
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.
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.
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 - Perform the holding function
- 202 - Perform the retrieve function
- 203 - Perform the reservation function
- 204 - 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
(3247)
- 18 -
AP IX-98-E
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 has (i) 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 four
figures (2-4/Q.83, 2-5/Q.83, 2-6/Q.83 and 2-7/Q.83).
(3247)
- 19 -
AP IX-98-E
(pages 36-40 of this document recoup)
(3247)
- 20 -
AP IX-98-E
2.6 Network physical allocation scenarios
│ FE1 FE2 FE3 FE4
───────────┼──────────────────────────────
Scenario 1 │ TE LE LE TE
│
Scenario 2 │ TE NT2 NT2 TE
│
Scenario 3 │ TE LE NT2 TE
│
Scenario 4 │ TE NT2 LE TE
3. Completion of call to busy subscriber
Under study.
───────────────────
(3247)