delim @@
| 5i'
CALL COMPLETION 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, as defined in Recommendation I.140, for supplementary services is for futher study.
|
This Recommendation describes the following Call Completion supplementary services: I.253.1 Call Waiting (CW) I.253.2 Call Hold (HOLD) I.253.3 Completion of calls to busy subscribers (CCBS) (Note) Note -- This service already identified needs to be further studied; its description is not yet included. |
||
|
1 1.1 |
I.253.1 -- Call Waiting Definition The Call Waiting service permits 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 an out-of-band notification to subscriber B of the incoming call; this is the assumed case for this definition. In addition, as a service provider option, audible in-band indications may be provided to the channels occupied with the speech bearer service and the Telephony teleservice. Where applied, tones should be in accordance with Recommendation E.180.
Fascicle III.7 -- Rec. I.253 1
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 Specific terminology
Throughout this definition the following terminology will be used:
Subscriber B: the subscriber who is provided by the network with the Call Waiting service on a particular interface.
User B: the user who reacts to the call waiting at B.
User C: the user who has originated a call to B which causes the Call Waiting service to be invoked.
User A: represents a user who is engaged in a call with user B (this call can be in any state).
User Response timer T1: this timer specifies the period the network will wait for a positive response, from a terminal at B, to the offered call. It is part of the basic call and has a value of a few seconds.
No Answer timer T2: this optional timer specifies the period the network will wait for a response (answer), from user B, to the offered call from user C. The value of this timer is between 0.5 and 2 minutes.
1.2.3 Qualifications on the applicability to telecommunication services
This supplementary service is considered meaningful when applied to the Telephony teleservice and the speech and 3.1 kHz audio bearer services. Furthermore, it may also be meaningful when applied to other services.
2 Fascicle III.7 -- Rec. I.253
|
1.3 1.3.1 |
Procedures ProvisionB/Fwithdrawal Call Waiting can be provided on a subscription basis or, as a network provider option, can be generally available |
|
|
to all |
users without subscription. Call Waiting can be withdrawn for administrative reasons. As part of each applicable bearer service or teleservice, there is an option specifying the maximum number of |
information channels which can be used (occupied) on the interface for each ISDN number, all ISDN numbers or subsets of ISDN numbers. Call Waiting for bearer services or teleservices occurs only when an attempt is made to exceed these limits.
As a network provider option, Call Waiting can be offered with several subscription options. The options apply separately to each ISDN number and service combination. For each subscription option, only one value can be selected. Subscription options are summarized below:
Subscription options Value Calls that can wait -- All -- Others are for further study Calling user receives notification call is waiting -- No -- Yes
In addition, the following subscription options can be specified for each ISDN number, all ISDN numbers, or subsets of ISDN numbers on each interface.
Subscription options Value Maximum number of calls which can be waiting -- One -- l , where 1 l n -- m
Note -- The parameters m | (maximum number of information channels) and n | (maximum number of total calls present) are defined in the relevant basic service description (refer to Recommendations I.231 and I.241).
1.3.2 Normal procedures
1.3.2.1 ActivationB/Fdeactivation
Subscriber B may activate and deactivate Call Waiting with an appropriate request. Whether, and if so, to what degree, activationB/Fdeactivation is supported by the network may be network dependent. If supported, then the network shall inform subscriber B (all terminals on the access) of the success, or other outcome, of this action.
1.3.2.2 Invocation
1.3.2.2.1 When an incoming call from user C arrives at the access of subscriber B and encounters the channels busy condition, and a network determined user busy (NDUB) condition does not result, then the Call Waiting service will be invoked and the call shall be offered to subscriber B with an indication that the channels busy condition exists.
Fascicle III.7 -- Rec. I.253 3
1.3.2.3 Operation
1.3.2.3.1 If a response is received from a terminal at the B access, within the normal basic call period, that the user(s) is (are) being informed about the incoming call, then user C will be given an indication that the called user(s) is (are) being informed of the incoming call. In some networks this indication may also indicate that call waiting is in operation. 1.3.2.3.2 If user B requests connection to the waiting call and placement of the specified active call with user A into a held state, before the expiry of the optional No Answer timer T2, then the call between user C and user B is completed in the normal manner with any indications to user C being removed. The previously active call between user A and user B is put into the held state. User A may be given an indication that his call has been put into the held state.
Note -- From this state other supplementary services, for example the Three Party Service, may be used.
1.3.2.3.3 If user B requests connection to the waiting call and termination of the specified active call with user A before the expiry of the optional No Answer timer T2, then the call between user C and user B is completed in the normal manner with any indications to user C being removed. The previously active call between user A and user B is terminated in the normal manner.
1.3.2.3.4 If user B terminates the active call with user A before the expiry of the optional No Answer timer T2, then this call shall be released in the normal manner. User B is then able to accept the waiting call from user C using normal information channel selection procedures.
1.3.2.3.5 If user B holds the active call with user A before the expiry of the optional No Answer timer T2, then this call shall be held in the normal manner. User B is then able to accept the waiting call from user C using normal information channel selection procedures.
1.3.2.3.6 If user A requests termination of the active call with user B before the expiry of the optional No Answer timer T2, then the conditions of § 1.3.2.3.4 apply.
1.3.3 Exceptional procedures
1.3.3.1 ActivationB/FdeactivationB/Fregistration
None identified.
1.3.3.2 Invocation
None identified.
1.3.3.3 Operation
1.3.3.3.1 Incoming call from user C ignored by subscriber B
If the optional No Answer timer T2 expires without any acceptance from subscriber B of the incoming call, then the network shall inform subscriber B that the call is no longer waiting and also inform user C that his call cannot be connected. Normal release applies to the call attempt from user C (the call is cleared indicating no response) with an appropriate indication given to user C.
1.3.3.3.2 Incoming call from user C rejected by user B
4 Fascicle III.7 -- Rec. I.253
A rejection of the waiting call by one of the terminals on the interface of subscriber B will not stop the optional No Answer timer T2 as another terminal may subsequently accept the waiting call within the remainder of the specified period. Such a rejection may, however, cancel any indication provided to that terminal. Where rejections of a waiting call have been received from all those terminals that responded with an alerting indication before the expiry of the optional No Answer timer T2, then the network shall inform user C that his call cannot be connected. Normal release applies to the call attempt from user C with the call being cleared indicating user rejection. Subscriber B is notified that the call is no longer waiting.
1.3.3.3.3 Release by user C within the specified period
If calling user C informs the network, before the expiry of the optional No Answer timer T2, that he wishes to release his call attempt to subscriber B, then the network shall inform subscriber B of this situation and initiate release of the call attempt from user C.
Fascicle III.7 -- Rec. I.253 5
1.3.3.3.4 No positive response from terminals at subscriber B's interface
If no positive response that user(s) are being informed of the waiting call is received from a terminal at subscriber B's interface during the normal call period (User Response timer T1), then the call attempt from user C shall be released by the network with user C being given the reason for the release.
1.3.3.3.5 No resources available
If user B accepts a call and network resources do not exist to complete the call (i.e. no information channels are available), the network will indicate an error to user B with cause ``no B-channels available''. The network will not clear the call but will wait for another user B indication for acceptance, until user C clears the call or the optional No Answer timer T2 expires.
1.3.4 Alternative procedures
1.3.4.1 ActivationB/FdeactivationB/Fregistration
None identified.
1.3.4.2 Invocation and operation
None identified.
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 1.5.1 |
Interworking requirements ISDN served user: non-ISDN calling user If an ISDN subscriber B receives a call from a non-ISDN calling user, the network will send the Call Waiting |
indication to subscriber B in the normal way.
An inband indication will be applied to channels occupied with the 3.1 kHz audio bearer service (where the call originated from the PSTN as identified by a progress indicator), only if it is destined to a number designated for inband notification by the call waiting subscriber.
1.5.2 Non-ISDN served user: ISDN calling user
Not applicable since a non-ISDN served user will not be able to subscribe to ISDN Call Waiting.
6 Fascicle III.7 -- Rec. I.253
|
1.6 1.6.1 |
Interaction with other supplementary services Call Waiting Not relevant. |
|
|
1.6.2 |
Call Transfer User B, who has subscribed to both Call Waiting and Call Transfer services, cannot transfer a waiting call from |
user C until he first establishes a connection to user C.
Assume that user B is on an active call with user A and has received an indication of a waiting call from user C. Users A and B have Call Waiting subscribed for their accesses and user B has subscribed to the Call Transfer service. User B intends to transfer user A to user D.
Fascicle III.7 -- Rec. I.253 7
-- User B may receive an indication of a waiting call from user C either before or during the transfer of user A to another party. The call waiting indication may be presented regardless of the type of transfer invoked by user B (i.e. for Normal, Single Step, or Explicit transfers). When user A has been transferred, a B-channel would normally become idle, enabling the waiting call to be answered by user B.
-- If user A has a call waiting indication before or during the transfer process, then upon successful completion of the transfer of user A to user D, user A shall retain the waiting call indication. User A could use normal call waiting procedures (if desired) to accept the waiting call.
-- If user D receives a call waiting indication during the transfer process, e.g. while being in a call with user B, then upon successful completion of the transfer of user A to user D, user D shall retain the waiting call indication. User D could use normal call waiting procedures (if desired) to accept the waiting call.
In general, a call waiting indication may be delivered to users A or B (and to user D during the transfer process) when the called user has subscribed to the Call Waiting service.
1.6.3 Connected Line Identification Presentation
No impact, i.e. neither supplementary service affects the operation of the other supplementary service.
When user B uses one of the call waiting procedures to accept a waiting call (within any time limits established by the service provider), user C will be informed of the connection. The confirmation that a connection has been established may provide the connected user B's number.
|
1.6.4 |
Connected Line Identification Restriction No impact, i.e. neither supplementary service affects the operation of the other supplementary service. |
|
|
1.6.5 |
Calling Line Identification Presentation No impact, i.e. neither supplementary service affects the operation of the other supplementary service. If the user(s) at B is(are) given a call waiting indication, and has(have) subscribed to the CLIP service, then the |
calling user number shall be presented to the users at B at the time the call waiting indication is given.
1.6.6 Calling Line Identification Restriction
No impact, i.e. neither supplementary service affects the operation of the other supplementary service.
Assume a user at C, who has subscribed to the CLIR service, reaches a user(s) at B, who has subscribed to the Call Waiting service. On invocation, the user at B would receive a call waiting indication but would not receive user C's number when the call waiting indication is given.
|
1.6.7 |
Closed User Group No impact, i.e. neither supplementary service affects the operation of the other supplementary service. |
||
|
1.6.8 |
Conference Calling A user at B who is active on any type of conference call may receive an indication of a waiting call. Once a conference has been established: |
||
|
8 |
Fascicle III.7 -- Rec. I.253 |
i) Any party that has activated Call Waiting will be able to receive an indication of an incoming call, and could place his connection to the conference on hold to accept the waiting call.
ii) The Conference Controller could, if desired, add the party from the waiting call, by answering the waiting call and using the ``add party from existing call'' procedures.
Fascicle III.7 -- Rec. I.253 9
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 Diversion (Call Forwarding) services
1.6.10.1 Call Forwarding Busy
If user B is not NDUB, Call Waiting will take place. If user B is NDUB, CFB will take place. Therefore these services are mutually exclusive and there is no interaction.
1.6.10.2 Call Forwarding No Reply
If subscriber B has Call Forwarding No Reply (CFNR) activated, then a waiting call shall still be offered as described in this definition. If no answer is received to this call within the duration of the CFNR timer, then the CFNR service is invoked and the call is forwarded as per that service definition.
1.6.10.3 Call Forwarding Unconditional
If subscriber B has activated Call Forwarding Unconditional, then the execution of that forwarding condition takes precedence over Call Waiting. Call Forwarding Unconditional can be activated while a call is waiting without changing the state of the waiting call.
1.6.11 Line Hunting
The Call Waiting service should not be provided to a line in a hunt group.
1.6.12 Three-Party Service
A user at B who is involved in a Three-Party Service operation (with minimal Three-Party Service or active in a three-way conversation) may receive an indication of a waiting call. The procedures and restrictions for handling the waiting call are defined in the Three-Party Service description.
1.6.13 User-to-User Signalling
User-to-user information (UUI) (service 1) included in the call set-up message will be delivered to subscriber B with the Call Waiting indication.
UUI (service 2) sent from the calling user to the called user during the alerting phase is allowed to be sent when a point-to-point configuration exists at the called side.
If the called user subscribes to User-to-User Signalling, he may include UUI (service 1) in a rejection of a waiting call when a point-to-point configuration exists at the called side.
There is no interaction with user-to-user service 3.
1.6.14 Multiple Subscriber Number
10 Fascicle III.7 -- Rec. I.253
No impact, i.e. neither supplementary service affects the operation of the other supplementary service.
1.6.15 Call Hold
When an ISDN user receives a call waiting indication the ISDN user may use the Call Hold service to hold his active call and answer the waiting call. Use of the hold service does not place a call into a waiting state.
1.6.16 Advice of Charge
No impact, i.e. neither supplementary service affects the operation of the other supplementary service.
1.7 Dynamic description
The dynamic description of this service is given in Figure 1/I.253.
Fascicle III.7 -- Rec. I.253 11
Figure 1/I.253 (feuillet 1 sur 5), (N), p. 12 Fascicle III.7 -- Rec. I.253
Figure 1/I.253 (feuillet 2 sur 5), (N), p. 2 Fascicle III.7 -- Rec. I.253 13
Figure 1/I.253 (feuillet 3 sur 5), (N), p. 3 14 Fascicle III.7 -- Rec. I.253
Figure 1/I.253 (feuillet 4 sur 5), (N), p. 4 Fascicle III.7 -- Rec. I.253 15
Figure 1/I.253 (feuillet 5 sur 5), (N), p. 5 2 I.253.2 -- Call Hold
2.1 Definition
The Call Hold service allows a user to interrupt communications on an existing callB/Fconnection (Note 1) and then subsequently, if desired, re-establish communications. A B-channel (Note 2) 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 1 -- The applicability of the hold service to a ``call'' versus a ``connection'' requires further study.
Note 2 -- The applicability of this service definition to other access resources (e.g. H-channels, logical channels) for other services requires further study.
16 Fascicle III.7 -- Rec. I.253
2.2 Description
2.2.1 General description
When the Call Hold service is invoked, communication on a B-channel is interrupted and the B-channel is released from use by the existing call. If reservation is subscribed to, and depending on subscription parameters, a B-channel is reserved for use by:
|
-- -- -- -- -- |
the given terminal used to invoke the Call Hold service; a subscription time user-defined set of terminals; a user, defined by a directory number (Note); a subscription time user-defined set of directory numbers (Note), or; a user, identified by a Personal Identification Number (Note). |
Note -- Methods to define implementation are for further study.
When a user (as identified by a terminal, others for further study) places a call on hold and reservation applies, a B-channel should always be available on that user's interface so that the user may retrieve that call from hold, or set up, 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.
Hence, 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, others for further study).
When the served user wishes to re-establish communications, the Retrieve operation is requested. The success of the Retrieve operation depends on whether a B-channel was reserved and whether a B-channel is currently available to the served user.
|
2.2.2 |
Specific terminology None identified. |
|
|
2.2.3 |
Qualifications on the applicability to telecommunication services This supplementary service is considered meaningful when applied to the Telephony teleservice and the speech |
and 3.1 kHz audio bearer services. Furthermore, it may also be meaningful when applied to other services.
|
2.3 2.3.1 |
Procedures ProvisionB/Fwithdrawal The type of reservation is specified at subscription time. |
||
|
2.3.2 |
Normal procedures |
Fascicle III.7 -- Rec. I.253 17 |
2.3.2.1 ActivationB/FdeactivationB/Fregistration
None identified.
2.3.2.2 Invocation and operation
2.3.2.2.1 Hold request
The served user indicates to the service provider that the communication on the interface is to be interrupted. A call may be placed on hold:
-- on the calling user's interface, by the calling user at any time after completion of dialling;
-- on the called user's interface, by the called user at any time after the call has been answered and before call clearing has begun.
The communication on the interface is then interrupted. The service provider acknowledges this action, and the associated channel is made available for other uses, depending on the reservation option. As an option, the network may send a notification to the held party indicating that the call has been placed on hold.
18 Fascicle III.7 -- Rec. I.253
If held call(s) are cleared for any reason, the service provider will continue to reserve a channel for the specified user(s)/terminal(s) until there are no more held calls with reservation associated with the specified user(s)/terminal(s). If at any time a call is in the held state, either party may clear the call.
2.3.2.2.2 Retrieve request
When the user who invoked the Call Hold service indicates that the call is to be retrieved, the service provider will re-establish communications, provided that a B-channel is available, and acknowledge to the served user and optionally to the held party that the call is now active.
The user may optionally indicate a B-channel selection parameter in the Retrieve request. The parameter may indicate:
1) any channel is acceptable;
2) specified channel is preferred; or
3) specified channel is required exclusively.
If the service provider can satisfy the request, the call will be returned to the active phase; if it cannot, the request will be rejected with the appropriate cause returned to the user.
2.3.2.2.3 Reservation processing
The following conditions concerning reservations against a channel apply:
1) when the call is retrieved, any reservation against a channel associated with that call should be cleared, regardless of which channel is used to retrieve the call;
|
2) 3) |
when a call is cleared, any reservation against a channel associated with the call should be cleared; when all reservations are cleared, all channels become available for use by either the network or the |
|||
|
user. |
||||
|
4) |
When any reservation is outstanding for a given user [as identified by a terminal, a set of terminals, a DN |
(directory number), a set of DNs or a PIN (personal identification number)] and that user is not using a channel for an active call, then the network must consider a channel as ''not free'' for that user for subsequent incoming calls.
If all channels are ``not free'' (busy or reserved) and a user has also subscribed to the Call Waiting service, the network would be able to offer an incoming call with an indication that ``no interface information channels are available''. The served user may accept that incoming call using a reserved channel.
2.3.3 Exceptional procedures
|
2.3.3.1 ActivationB/FdeactivationB/Fregistration None identified. 2.3.3.2 Invocation and operation 2.3.3.2.1 Hold request |
Fascicle III.7 -- Rec. I.253 19
If the user tries to hold a call while not subscribed to the service or if, for some other reason, the service provider cannot hold the call, an indication will be provided to the user with the reason of failure.
2.3.3.2.2 Retrieve request
If the service provider cannot retrieve a previously held call, the user will be informed of the reason for failure. (For example, there may not be any channel available, or the call may be in the process of being cleared.)
|
2.3.4 |
Alternative procedures 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 information.
It shall be possible to charge the subscriber accurately for the service.
20 Fascicle III.7 -- Rec. I.253
2.5 Interworking requirements
The operation of this feature is not affected by the nature (i.e. ISDN or non-ISDN) of the far end of the connection.
2.6 Interactions with other supplementary services
2.6.1 Call Waiting
A user may use the hold feature to hold an active call and answer an incoming call that is being given call waiting treatment.
2.6.2 Call Transfer
A served user may indicate to a service provider that a held call is to be transferred to another party. The transfer indication must explicitly identify the held call. A successful transfer will clear the held call from the served user's point of view. For more information, see the explicit call transfer procedure in the Call Transfer service description.
Any parties on hold to a party being transferred will continue to be on hold to that party after the transfer operation. For example, if party B, currently active or on hold to party A, is transferred to another party C by served user A, then the parties held by parties B and C before the transfer will continue to be held by those parties after the transfer.
The hold process is symmetric, i.e. both parties may place each other on hold. It is possible, therefore, for two parties that have subscribed to the Call Hold and Call Transfer services, to each place their active call on hold and to simultaneously transfer the other party. That is, if parties A and B have an active connection, party A may place the call on hold and transfer party B to another party C while at the same time party B puts his call to party A on hold and transfers party A to another party D.
|
2.6.3 |
Connected Line Identification Presentation No impact, i.e. neither supplementary service affects the operation of the other supplementary service. |
||
|
2.6.4 |
Connected Line Identification Restriction No impact, i.e. neither supplementary service affects the operation of the other supplementary service. |
||
|
2.6.5 |
Calling Line Identification Presentation No impact, i.e. neither supplementary service affects the operation of the other supplementary service. |
2.6.6. Calling Line Identification Restriction
No impact, i.e. neither supplementary service affects the operation of the other supplementary service.
2.6.7 Closed User Group
Fascicle III.7 -- Rec. I.253 21
No impact, i.e. neither supplementary service affects the operation of the other supplementary service.
2.6.8 Conference Calling
Any party involved in an active conference (i.e. the conference controller or a conferee) may place the conference call on hold and later retrieve the connection to the conference. Any party placing the conference on hold may retrieve any other party it had previously placed on hold. See also the Conference Calling service description Recommendation I.254, § 1.6.15.
22 Fascicle III.7 -- Rec. I.253
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
No impact, i.e. neither supplementary service affects the operation of the other supplementary service.
2.6.10.2 Call Forwarding No Reply
No impact, i.e. neither supplementary service affects the operation of the other supplementary service.
2.6.10.3 Call Forwarding Unconditional
No impact, i.e. neither supplementary service affects the operation of the other supplementary service.
2.6.11 Line Hunting
No impact, i.e. neither supplementary service affects the operation of the other supplementary service.
2.6.12 Three-Party Service
Refer to Recommendation I.254, § 2.6.15, interaction with Call Hold.
2.6.13 User-to-User Signalling
Any party that has placed one or more calls on hold may continue to exchange (send or receive) user-to-user information (UUI) (service 3) messages with the party(s) on hold as well as to exchange UUI (service 3) messages with an active call party. A held party that is disconnecting may receive or send UUI (service 1) messages during the clearing phase of the call.
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
Assume that parties A and B have both subscribed to the Call Hold service. The Hold service is unidirectional and therefore, the following is possible:
1) only party A has party B on hold;
2) only party B has party A on hold;
Fascicle III.7 -- Rec. I.253 23
3) each party has the other party on hold.
2.6.16 Advice of Charge
|
No impact, i.e. neither supplementary service affects the operation of the other supplementary service. |
||
|
2.7 |
Dynamic description The dynamic description of this service is given in Figure 2/I.253. |
|
|
3 |
I.253.3 -- Completion of Calls to Busy Subscribers This service, already identified, needs to be further studied; its description is not yet included. |
|
|
24 |
Fascicle III.7 -- Rec. I.253 |
Figure 2/I.253 (feuillet 1 sur 2), (N), p. Fascicle III.7 -- Rec. I.253 25
Figure 2/I.253 (feuillet 2 sur 2), (N), p. 26 Fascicle III.7 -- Rec. I.253
MULTIPARTY 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 Multiparty Supplementary Services: I.254.1 Conference Calling (CONF) I.254.2 Three-Party Service (3PTY) |
||
|
1 1.1 |
I.254.1 -- Conference Calling Service Description Definition Conference Calling is an ISDN supplementary service which allows a user to communicate simultaneously with |
multiple parties, which may also communicate among themselves. This description deals primarily with the establishment and manipulation of the connections used to form a conference call and is therefore expected to be applicable to many types of conference calls (e.g. voice, data, video, multi-media). Although provision is made for specifying the conference type, it is recognized that the control of conferencing functions (especially for those other than speech) is beyond the scope of this Recommendation.
This Recommendation describes the operation of the ``Add-on'' Conference Calling service only. Other forms of Conference Calling (e.g. ``Meet-me'') are not described.
1.2 Description
1.2.1 General description
When Conference Calling is invoked, conference resources (e.g. a ''bridge'') are allocated to the served user, and any calls indicated by the service request are added to the conference. Once a conference is active, parties may be added, dropped, isolated (i.e. prevented from communicating with the conference), reattached, or split (i.e. removed from the conference but remain connected to the conference controller). The controller can place his connection to the conference on hold, retrieve the conference, end the conference, or disconnect himself from the conference.
1.2.2 Specific terminology
Fascicle III.7 -- Rec. I.254 27
1.2.2.1 Served user, conference controller, conferees, parties
During the invocation phase, the service is under the control of the `` served user '', i.e. the one for whom the service was subscribed or, in those cases where subscription is not required, the one who invokes the service. Once the conference is in the active state, the service is under the control of the `` conference controller '' who, in most cases, is the served user but could be a party other than the served user if transfer of control has occurred (an anticipated future extension to this service). Any party other than the conference controller is called a `` conferee ''. All participants in the conference call are considered ``parties''.
1.2.2.2 Call ID, Party ID, Connection ID
|
28 |
Call ID: the served user's (controller's) reference to a call of which he is a party. Examples: 1) the conference call itself, 2) a call which is to be added to the conference, 3) a call which is formed by splitting a party from the conference. Fascicle III.7 -- Rec. I.254 |
Party ID: the served user's (or controller's) reference to a particular party within the context of a call.
Connection ID: the served user's (or controller's) reference to a particular connection (to a particular party) within the context of a call.
Observe that multiple parties may be associated with a given call, e.g. a conference call. Moreover, there can be multiple connections associated with a single party, e.g. a simultaneous voice and video call.
Note -- This service description assumes that there exists only one connection to a given party. Procedures to allow for multiple connection (e.g. multi-media conference calls) to a given party are anticipated future extensions.
1.2.2.3 Conference states
Conference Idle : the state prior to the reception of a ``conference invocation request '', or after a particular conference has ended.
Conference Active : the state in which conference resources have been allocated to the specified conference and at least one party has a connection to the conference. That connection could be either active or held.
Conference Floating : the state in which the conference is active but without a controller. This state is possible when two or more conferees exist on an active conference and the controller successfully disconnects himself (see Figure 1/I.254, sheet 7).
1.2.3 Qualification on the applicability to telecommunication services
This supplementary service is considered meaningful when applied to the Telephony teleservice and the speech and 3.1 kHz audio bearer services. Furthermore, it may also be meaningful when applied to other services.
1.3 Procedures
1.3.1 Provision/withdrawal
The Conference Calling supplementary service may be subscribed to by prior arrangements with the service provider. The subscription parameters include the maximum (and, if different, the default) number of conferees allowed in a conference call.
Note -- The default will usually be three, but may be six (or some other number).
If the served user has subscribed to more than one size conference service and wishes to establish a conference of a size other than the default size, the served user must request the properly-sized conference before any parties are added to the conference.
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.
Fascicle III.7 -- Rec. I.254 29
1.3.2.2 Invocation and operation
1.3.2.2.1 Beginning the conference call | (see Figure 1/I.254, Sheets 1 and 2)
Invocation parameters:
The Conference Calling service must be invoked by the served user. The invocation request must include the ``root'' Call ID, i.e. the Call ID by which the served user (or controller) will refer to the conference call itself. This Call ID may be either a new Call ID or the Call ID of an existing call which is to be used to form the conference.
30 Fascicle III.7 -- Rec. I.254
The invocation request may include the following additional information:
-- Conference size : the intended maximum number of parties for the conference (if different from the default).
-- Existing call/party information (Call IDs/Party IDs/disposition of related B-channel connections): in order to initially include one or more parties from an existing call in the conference, the invocation request must include the Call ID, and optionally the Party ID and information as to how the B-channel associated with that call is to be handled.
-- New party information (called party address, other ``set-up'' information): in order to initially include a party for which there is no existing call, the invocation request must include the desired party's address, and optionally other information information contained in a normal call request.
Note -- Some information which is mandatory in a normal call request (e.g. ``bearer capability'') can be inferred (e.g. from the conference type) and and hence may not be mandatory here.
-- Connection request : either active or held. This request defines the served user's initial connection to the conference. Possible values follow:
Active state specified :
i) Specific B-channel : a specified preferred/exclusive B-channel shall be used to immediately establish a connection to the conference.
ii) Any available B-channel may be used.
Held state specified :
i) Reserved B-channel : a B-channel is to be reserved for (later) connection to the conference.
ii) No reserved B-channel : in this case no B-channel is allocated or reserved; the served user may have to free up a B-channel later when participation in the conference is desired.
-- Conference type : in general, the bearer capability compatibility check during context arbitration can be used to infer the type of conference required. It is assumed to be ``speech''. Other conference types may require special bridging facilities and/or higher layer control.
-- Conference bridge location : it should be possible to request the conference bridge to be at a specified location, e.g. close to some grouping of conferees. Procedures for remote location of conference bridge facilities are anticipated future extensions.
Defaults for invocation parameters
If any of the information described above is not included in the invocation request, the following defaults will occur:
-- Conference size: the size defaults to the subscribed default conference size specified at subscription time (if the served user specified a default conference size at subscription time) or the subscribed maximum conference size (if a default conference size was not specified), or the default conference size specified by the service provider (if the served user did not subscribe to the service).
-- Existing call/party information:
i) Call IDs: if no Call ID other than the root Call ID is specified, no existing calls will be initially included in the conference.
ii) Party IDs: if not specified, each party (other than the served user) of the indicated Call ID(s) will be initially included in the conference.
iii) Disposition of related B-channel connections: if disposition information is not included, the related B-channel connections will be deallocated, unless the service provider chooses to use them for connection of the
Fascicle III.7 -- Rec. I.254 31
served user to the conference call (e.g. in a multi-media conference).
-- New party information:
i) Called party address: if not specified, no new parties will be initially included in the conference.
ii) Other ``set-up'' information: for further study.
32 Fascicle III.7 -- Rec. I.254
-- Connection request: if no connection information is included, it is assumed that the served user wishes to be initially connected to the conference in the active state and any available B-channel may be used.
i) If the served user indicates that he wishes to be connected to the conference in the active state but does not indicate ``specific B-channel'' or ``any available B-channel'', it is assumed that any available B-channel may be used.
ii) If the served user indicates that he wishes his resulting connection to the conference to be in the held state, but does not indicate ``reserved B-channel'' nor ``no reserved'', it is assumed that a B-channel is to be reserved for (later) connection to the conference.
-- Conference type: if not specified, the service provider will attempt to derive the appropriate conference type from the bearer capabilities of the call(s) involved. If no calls are known by the service provider to be involved in the call, the default conference type shall be ``speech''.
-- Conference bridge location : if not specified, the service provider will attempt to place the conference bridge (s) in the most appropriate location, considering the call(s) known by the service provider to be involved at the time the request is made.
Procedures
When a conference request is made, a conference call is set up.
When the service provider receives the request to allocate resources for the conference call, it checks to see that the requested conference can be established. This procedure is termed `` context arbitration ''. Context arbitration includes a bearer capability compatibility check, a supplementary services compatibility check, a check to see that the state of each connection to be added is acceptable, and a check for the availability of conference/network resources. Upon successful completion of the context arbitration, the resources needed are allocated.
If the conference request is successful, all existing appropriate call(s) referenced in the conference request are added to the conference.
Note -- Adding parties from an existing call may not be successful in all cases due to remote bridging and rerouting limitations.
Upon successful joining of the specified parties to the conference, any unused B-channels are deallocated and any single party calls are released.
The service provider checks the conference request for additional information (optional parameters). For those optional parameters not included in the conference request, the default values will be used. In addition, if the connection request parameter is not included and no additional parties are indicated (i.e. m = 0, n = 0) the service provider will prompt the served user for further actions.
1) Prompting procedures detected: if the number of referenced existing calls (other than the root Call ID) in the conference request is zero and the controller connection request is not included, then the conference is put on hold from the served user's point of view and the served user is prompted for further actions (i.e. the add-party procedure is automatically started).
2) No prompting procedures detected: if the number of referenced existing calls (other than the root Call ID) in the conference request is larger than zero, or if the controller connection request is specified, the referenced calls are automatically connected to the conference, which is now in an active state. The served user's connection to the conference will also be active unless the controller has indicated that his connection to the conference should be held.
The decision to put the conference on hold or not (from the served user's point of view) is based on the information received in the Conference request, independent of the number of referenced existing calls.
1.3.2.2.2 Managing individual parties | (see Figure 1/I.254, Sheets 2 and 3)
When managing a party, the controller needs to specify the pair Call ID/Party ID. If no party(s) is specified, the service provider will typically assume that the request applies to all parties associated with the indicated Call ID.
Fascicle III.7 -- Rec. I.254 33
(Exception: if Party ID is not specified in the drop party command, the last party added to conference is dropped.) 34 Fascicle III.7 -- Rec. I.254
In the active state of the conference, the conference controller has the following options for managing parties in association with a conference:
Add new party
The conference controller can request that a new party be added to an existing conference call using procedures analogous to those used to start the conference call.
Upon a request for the addition of a new party, the conference controller automatically puts the conference on hold. The service provider checks the Add Party request for additional information, i.e. whether or not the conference controller is to keep the conference on hold after the addition of a new party. If no information is received, the service provider will use the service default value.
When on hold, the conference controller can either indicate the address of a new party or indicate a Call ID of an already existing call. (See Figure 1/I.254, Sheet 2.)
a) New call: the service provider will establish a connection with the new party indicated by the address provided by the controller. Upon call establishment, the controller will be connected to this new active call. (If call establishment fails or if the active call is disconnected, the controller may or may not return to the active conference based on the connection request parameter within the Add Party request).
Note -- By establishing this connection via the conference bridge, the service provider may avoid problems associated with remote bridging and rerouting.
b) Existing call: if a Call ID exists, the controller indicates a call Call ID to be added directly to the conference. The party (parties) on the indicated call are immediately joined to the conference.
If a Party ID is given in conjunction with the Call ID, then the specified party is split from the specified call and added to the conference. If no Party ID is given then all parties on the specified call are added to the conference.
Note -- Adding parties from an existing call may not be successful in all cases due to remote bridging and rerouting limitations.
Drop party
The conference controller can request that a specified party be disconnected from the conference and the conference controller's association with that party be eliminated completely. If no Party ID is specified, it is assumed that the last party (if identifiable) added to the conference should be dropped. After the party is dropped, if there are no other conferees (a conferee being a party other than the conference controller), then the conference remains in the Conference Active state (with only the conference controller attached). If, after the party is dropped, there is only one other conferee, then the service provider could, at its option, form an ``ordinary'' two-party call and release the conference resources, or remain in the Conference Active state (with only the conference controller and the one conferee attached). (See Figure 1/I.254, Sheet 3.)
Split party
The conference controller can request that a specified party be removed from the conference but remain connected to the conference controller. Execution of this request requires that the network establish a new Call ID for the call between the conference controller and the specified party, since that party is no longer associated with the conference call. Two parameters must appear in the Split Party request:
1) Call ID (conference call), and
2) Party ID (specified party).
The Split Party request will put the controller's connection to the conference in the held state and the controller's connection to the specified party in the active state (see Figure 1/I.254, Sheet 3).
Fascicle III.7 -- Rec. I.254 35
Isolate party
The conference controller can request that a specified party be prevented from communicating with the conference but not removed from it. This does not affect the state (e.g. active or held) of the specified party's access channels (e.g. B-channels) which are nominally under the control of the specified party. (See Figure 1/I.254, Sheet 3.) 36 Fascicle III.7 -- Rec. I.254
Reattach party
The conference controller can request that the specified party be reattached to the conference. Successful execution of this command permits a previously isolated party to again converse with all other parties that are connected to the conference. (See Figure 1/I.254, Sheet 3.)
1.3.2.2.3 Managing the conference | (see Figure 1/I.251, Sheets 4 and 5)
In addition to the foregoing, the conference controller can manage the complete conference in any of the following ways:
Hold conference: the conference controller can request that his own connection to the conference be held, using procedures as described in the Call Hold service. Successful execution of this command retains the existing state of conferees in relation to the conference, i.e. those who could communicate with each other can still do so and those who were in an isolated state remain in that state. (See Figure 1/I.254, Sheet 4.)
Retrieve conference: the conference controller can request that a conference controller's connection to the conference be retrieved (see hold conference description above). Successful execution of this command retains the existing state of conferees, i.e. those who could communicate with each other can still do so between themselves as well as the conference controller, and those who were in an isolated state remain in that state. (See Figure 1/I.254, Sheet 4.)
Interrogate: it is an anticipated future extension that the conference controller will be able to request the current status of the conference call (i.e. number of parties, identification of parties, etc.) from the service provider. Information content and procedures for the interrogate request are, as yet, undefined. (See Figure 1/I.254, Sheet 4.)
Disconnect: a Disconnect request from the controller will disconnect the controller from the conference, and may, in some cases, result in ending the conference. From the controller's perspective, this disconnect procedure is identical to that outlined in the Basic Call service description.
|
If: a) |
the number of conferees is greater than or equal to 2; and |
|||
|
b) c) |
the Conference Floating option is subscribed to; and Floating conditions (e.g. charging) are satisfied; |
then the conference goes to the Floating state. Otherwise the conference ends (see End conference). This procedure differs from the disconnect controller procedure in that the normal disconnect procedure can result in either the Conference Active or Conference Idle state. When Conference Floating cannot be performed, instead of notifying the controller, disconnect processing continues with the release of conference resources. (See Figure 1/I.254, Sheet 5.)
Disconnect controller: the controller can request that he be disconnected from the conference. If the number of parties is greater than or equal to 3 and if the controller has subscribed to the Conference Floating option, and provided charging or other restrictions are not violated, the connection of the controller will be cleared and the conference will proceed to the Floating state (i.e. the remaining conferees may continue to communicate). Otherwise, the controller will be notified that the Disconnect Controller request is denied and the conference will remain active with the controller still connected.
The remaining parties will stay on the conference without a controller until less than two conferees exist on the conference. In a conference without a controller, conferees can only hold, retrieve or drop their own connections.
If one or two parties (including the controller) exist on the conference at the time disconnect is requested, the controller will be notified that the Disconnect request is denied and the conference will remain active with the controller still connected. (See Figure 1/I.254, Sheet 5.)
End conference: the conference controller can request that the conference be terminated, i.e.
1) that every party associated with a particular conference be disconnected,
Fascicle III.7 -- Rec. I.254 37
|
2) 3) Note |
that all conference resources be de-allocated, and that all knowledge of the conference call, including the Call ID, be removed. (See Figure 1/I.254, -- While Disconnect Controller and End Conference provide useful unambiguous functions, it is |
recommended that all terminals include the Disconnect function, and that this be the request that is sent in response to the normal user action (e.g. hanging up the telephone). This will avoid the problem which arises if the controller ``hangs up'' and leaves the terminal before receiving notification that a Disconnect Controller request cannot be accomplished. The Disconnect request would allow processing to continue at this point and the conference would be ended.
38 Fascicle III.7 -- Rec. I.254
1.3.2.2.4 Possible actions by conferees | (See Figure 1/I.254, Sheet 6)
In the active state of the conference, the conference can:
Hold/retrieve: put his connection to the conference on hold and later retrieve it. (See Figure 1/I.254, Sheet 6.)
Disconnect from the conference: the procedures here are nominally the same as those that occur after a conferee has been dropped from a conference by the conference controller. (See Figure 1/I.254, Sheet 6).
Indication of the above actions by any conferee should be provided to the conference controller. Whether conferees also receive indications as to the actions of other conferees is for further study.
1.3.3 Exceptional procedures
1.3.3.1 Activation/deactivation/registration
None identified.
1.3.3.2 Invocation and operation
1.3.3.2.1 Beginning the conference call
If a user tries to invoke Conference Calling and the service provider cannot comply with that request, the service provider will deny the request and explain the reason for denial. Possible reasons for non-compliance are:
|
-- -- -- -- -- |
service not subscribed; resources cannot be allocated; served user (or intended conferee) restrictions not met; context arbitration check failed; more than one party in an alerting state. |
If multiple conferees are specified in the conference request and if the context arbitration failed for only a subset of the intended conferees, the service provider has the option of permitting the subset of conferees which passed the context arbitration to form the initial conference call. If this is not permitted, the failure of any of the requested parties to pass the context arbitration check causes the conference request to be denied.
1.3.3.2.2 Managing individual parties
Add new party: | if the service provider cannot satisfy an Add New Party request (e.g. if the conference call has been cleared or if the maximum number of conferees allowed has already been reached) the conference controller will receive indication that the request is denied, with the reason for failure.
Note -- It is an anticipated future extension to allow for conference re-sizing when there is an attempt to exceed the maximum conference size allowed.
Fascicle III.7 -- Rec. I.254 39
Failure to pass any of the checks associated with the context arbitration results in the return of a failure message to the conference controller with appropriate cause(s).
Split isolate party: if no Party ID is included in a Split Party or Isolate Party request, notification of failure is returned to the conference controller. If the controller sends an Isolate Party request concerning a party which is already isolated, or a Re-attach Party request concerning a party which is already attached, the network will ignore the request.
1.3.3.2.3 Managing the conference
No exceptional procedures identified.
1.3.4 Alternative procedures
None identified.
40 Fascicle III.7 -- Rec. I.254
Figure 1/I.254 (feuillet 1 sur 7), (N), p. 8 Fascicle III.7 -- Rec. I.254 41
Figure 1/I.254 (feuillet 2 sur 7), (N), p. 9 42 Fascicle III.7 -- Rec. I.254
Figure 1/I.254 (feuillet 3 sur 7), (N), p. 10 Fascicle III.7 -- Rec. I.254 43
Figure 1/I.254 (feuillet 4 sur 7), (N), p. 11 44 Fascicle III.7 -- Rec. I.254
Figure 1/I.254 (feuillet 5 sur 7), (N), p. 12 Fascicle III.7 -- Rec. I.254 45
Figure 1/I.254 (feuillet 6 sur 7), (N), p. 13 46 Fascicle III.7 -- Rec. I.254
Figure 1/I.254 (feuillet 7 sur 7), (N), p. 14 Fascicle III.7 -- Rec. I.254 47
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 None identified. |
||
|
1.6 1.6.1 |
Interactions with other supplementary services Call Waiting Once a conference has been established of which the parties have subscribed to the Call Waiting service: i) any party that has activated Call Waiting will be able to receive an indication of an incoming call, and |
could |
place the conference on hold to accept the waiting call;
ii) the conference controller may, if desired, add the party from the waiting call by answering the waiting call and using the ``add party from existing call'' procedures.
Note -- If either the conference controller or a conferee has accepted a waiting call and has subscribed to either (minimal) Three-Party service or Call Hold service, then this party could alternate between the waiting call and the conference.
1.6.2 Call Transfer
Conference controller
A conference controller may transfer the conference to a party not in the conference, but ``control'' cannot be transferred [Figure 2/I.254, case a)]. The transfer of control of a conference to another party in the conference is an anticipated future extension [Figure 2/I.254, case b)] not yet included in this service description. A conference controller may disconnect himself from the conference [Figure 2/I.254, case c)] which may result in the conference entering a Floating state (see § 1.3.2.2.3).
Conferee
A conferee should be able to transfer his connection to the conference [Figure 2/I.254, case d)] to another party. Only the ``normal'' and ''explicit'' forms of transfer should be used, and the Complete Transfer request should only be made after the call to the other party has reached the active state. (This is to prevent call progress signals from disrupting the conference.) The identity of the new party, if available and unrestricted, should be given to the conference controller.
Any party
48 Fascicle III.7 -- Rec. I.254
Any party in a conference may transfer calls, or receive transferred calls, that are independent from the conference. A conference controller can add a call transferred to him using the ``add party from existing call'' procedure [Figure 2/I.254, case e)] (see § 1.3.2.2.2).
A conference controller can ``transfer'' a call to a conference [Figure 2/I.254, case f)]. (This is functionally similar to the case shown in Figure 2/I.254, case a).) A conferee may explicitly transfer an incoming call that has reached the active state to a conference [Figure 2/I.254, case f)], but this results in the conferee being disconnected from the conference, as shown in Figure 2/I.254, case d); it is not a form of ``add party''.
Any party in a conference may place the conference on hold, and explicity transfer another party that is being held. For example, user A is active in a conference call and also has a party B on hold (B is thus not part of the conference). User A may place the conference on hold and ``explicitly'' transfer party B to another party.
Calls may be transferred to any party of a conference while that party has the conference on hold. A conferee receiving a transferred call would not be able to add the transferred party to the conference. A conference controller receiving a transferred party would be able to use the ``add party from existing call'' procedure to add this new party to the conference.
Fascicle III.7 -- Rec. I.254 49
|
1.6.3 |
Connected Line Identification Presentation |
Figure 2/I.254, (N), p. |
A conference controller who has also subscribed to COLP should be presented the connected party's number when the party is either part of the initial activation of the conference or is added as a new conferee to an existing conference. Conferees in an existing conference who have subscribed to COLP will not receive a new party's number whenever a conference controller adds a new party to the conference.
|
1.6.4 |
Connected Line Identification Restriction No impact, i.e. neither supplementary service affects the operation of the other supplementary service. |
||
|
1.6.5 |
Calling Line Identification Presentation Any party that has subscribed to CLIP will receive the address of the conference controller when: -- the party is to be included as a ``new party'' during the invocation of a conference call, or -- the party is being added to an existing conference call. |
||
|
50 |
Fascicle III.7 -- Rec. I.254 |
|
1.6.6 |
Calling Line Identification Restriction No impact, i.e. neither supplementary service affects the operation of the other supplementary service. |
|
|
1.6.7 |
Closed User Group The conference controller and all conferees must belong to the same CUG. When establishing the conference |
initially, or when adding a new conferee, CUG restrictions must be checked and met for all parties on the conference call before the (new) party is allowed to enter the conference.
1.6.8 Conference Calling
A conferee may be connected to more than one conference if he has also subscribed to the Hold service. The conferee could switch between the conferences by placing one conference on hold and retrieving the other conference. (See also § 6.12 for the interaction with Three Party Service).
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 Diversion (Call Forwarding) services
A call which has been diverted can be added to a conference by the conference controller or be part of a new conference when initially invoked by the served user.
1.6.10.1 Call Forwarding Busy
See § 1.6.10 above.
1.6.10.2 Call Forwarding No Reply
See § 1.6.10 above.
1.6.10.3 Call Forwarding Unconditional
See § 1.6.10 above.
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 (see Figure 3/I.254)
It should be possible for a conference controller who has also subscribed to (minimal) Three-Party Service to participate in two conferences, and alternate between them [Figure 3/I.254, case a)]. It should not be possible to use (full) Three-Party Service to join the two conferences [Figure 3/I.254, case b)]. Procedures for joining conferences via normal ``add party'' functions are described in the text.
Fascicle III.7 -- Rec. I.254 51
It should be possible for a conferee who has also subscribed to (minimal) Three-Party Service to participate both in the conference and in another call (which may or may not be a conference) and alternate between them [Figure 3/I.254, case c)]. It is highly undesirable, and may, in some networks, be prohibited, for the conferee to use (full) Three-Party Service to bridge the conference and the other call [Figure 3/I.254, case d)]. This is due to the reduced control the conference controller would have regarding the party(ies) on the other call. Example: a conference controller request to drop the conferee that invoked Three-Party Service would drop the conference connection to all of the parties on that three-way call [Figure 3/I.254, case e)] but would not, in fact, disconnect any of them; they would remain active with party C.
52 Fascicle III.7 -- Rec. I.254
|
1.6.13 |
User-to-User Signalling |
Figure 3/I.254, (N), p. |
The conference controller will be able to send user-to-user information (UUI) (service 3) to any conferee on a conference call individually, and in some networks optionally broadcast messages to all conferees. (This assumes that each conferee can be uniquely identified.) UUI can be received by the conference controller from any of the conferees. While adding a new party to the conference, the conference controller can send and receive UUI (services 1, 2 and 3) from the new party until the new party is added to the conference.
A conferee may send and receive UUI (service 3 and service 1 during call clearing phase) from the conference controller. UUI cannot be sent between the conferees in association with the conference call (although any two parties, if subscribed, could send non-call associated UUI to each other.) A conferee's ability to send broadcast messages (under the control of the conference controller) to all parties, is for further study. A conferee may send UUI (service 1) to the conference controller only during the call clearing phase.
1.6.14 Multiple Subscriber Number
No impact, i.e. neither supplementary service affects the operation of the other supplementary service.
Fascicle III.7 -- Rec. I.254 53
1.6.15 Call Hold
When establishing a conference, the served user may identify any party(s) it has on hold to become a conferee(s) in the conference call being established. Similarly, a conference controller may add any party he has on hold to an active conference.
A party (A) in a conference may place the conference on hold and retrieve some other party that party A has on hold. Party A may then place this call on hold to retrieve the conference call.
Assuming subscription to both the Conference Calling and Call Hold services, a party may:
i) be a conference controller of two or more conferences. The conference controller switches conferences by putting the active conference on hold and then retrieving another conference;
ii) be a conference controller of one conference and a conferee of another conference(s). The party may switch between conferences by putting the active conference on hold and then retrieving another conference.
1.6.16 Advice of Charge
|
No impact, i.e. neither supplementary service affects the operation of the other supplementary service. |
||
|
1.7 |
Dynamic description The dynamic description of this service is shown in Figure 1/I.254, Sheets 1 to 7. |
|
|
2 2.1 |
I.254.2 -- Three Party Service Definition The Three-Party Service enables a user who is active on a call to hold that call, make an additional call to a third |
party, switch from one call to the other as required (privacy being provided between the two calls), and/or release one call and return to the other. Optionally, the served user could subscribe to an ability to join the two calls together into a three-way conversation. (Relationships between this service and the Call Transfer supplementary service are indicated throughout the text and Figure 4/I.254).
2.2 Description
2.2.1 General description
Three-Party Service provides a user with flexibility in handling up to two (initially-) independent calls. Different forms of the service exist which allow the user to control these calls. The various forms of Three-Party Service are given in Table 1/I.254.
In principle, all participants in a Three-Party Service call should be informed about the state of their calls whenever necessary.
H.T. [T1.254]
TABLE 1/X.254
center box; cw(48p) | lw(96p) | cw(48p) . Form of service { -- Hold existing call -- Make call to 3rd party -- Alternate between parties
54 Fascicle III.7 -- Rec. I.254
} { Form common path between all three parties
} _ lw(48p) | cw(96p) | cw(48p) . Minimal service Yes No _ lw(48p) | cw(96p) | cw(48p) . Full three-party service Yes Yes _
Table 1/I.254 [T1.254], p.
Fascicle III.7 -- Rec. I.254 55
|
2.2.2 |
Specific terminology Call ID: the served user's reference to a call of which he is a party. Examples: 1) the call to user B (or user C) prior to its being used to form a three-way conversation; 2) the three-way conversation, once it is formed. Served user: 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''.
|
User B: The other party in the original call (A¬ ñB). User C: The ``third party'' -- the other party in the second (e.g. enquiry) call (A | (raC). (For the original call, the served user may have been either the calling or called party (i.e. it may have been either an incoming or outgoing |
||
|
call)). 2.2.3 |
Qualifications on the applicability to telecommunication services |
|
|
This supplementary service is considered meaningful when applied to the Telephony teleservice and the speech and 3.1 kHz audio bearer |
services. Furthermore, it may also be meaningful when applied to other services.
2.3 Procedures
2.3.1 Provision/withdrawal
The Three-Party supplementary service is subscribed to by prior arrangements with the service provider. Subscription can be made for the Minimal Service or the Full Three-Party Service.
Withdrawal of the service is made by the service provider upon request by the subscriber or for service provider reasons.
2.3.2 Normal procedures
2.3.2.1 Activation/deactivation/registration
None identified.
2.3.2.2 Invocation and operation
2.3.2.2.1 Beginning Three-Party Service | (see Figure 4/I.254, Sheet 1)
The served user, user A, who has an existing active call with user B, asks the service provider to begin the Three-Party Service. The service provider puts the existing call on hold. User A then proceeds to establish the second call (to user C).
Note -- The same actions take place when the served user asks the service provider to start the ``normal'' Call Transfer service (see Call Transfer service description). Conceivably, a similar ``Held && Active'' service state (see Figure 2/I.252) could be attained as a result of accepting an incoming call in such a way that the service provider knew to associate that incoming call with the existing call and, hence, put the existing call on hold (see Call Waiting service description for one such possibility).
56 Fascicle III.7 -- Rec. I.254
2.3.2.2.2 Managing two associated calls -- one held one active | (see Figure 4/I.254, Sheets 1 and 2)
Served user :
Once the call to the third party reaches the alerting state, the served user can:
i) alternate from one call to the other as required (possibly several times), privacy being provided between the two calls;
Note -- The exact interactions between the served user and the service provider depend somewhat on the information and control capabilities available to the user from his terminal. Compare the two methods of alternating between calls given in Figure 4/I.254 under ``Alternate'' vs. ``Return to B(C)''.
Fascicle III.7 -- Rec. I.254 57
ii) Disconnect the active party (e.g. user C), whereupon the service provider would notify (see Note) the served user that the other party (e.g. user B) is still held and wait for one of the following events:
-- a request from the served user that the held party be retrieved;
-- a request from held party to disconnect.
If neither event occurs within a brief time interval, the service provider will disconnect the held party.
Note -- This would be a ``high priority notify'', i.e. one capable of gaining the served user's attention if he were away from the terminal. Ringing is an example of this.
iii) Disconnect the held party (e.g. user B)
Note -- Disconnecting a held party without previously retrieving it is considered undesirable for a ``human-to-human'' call but may be useful in other cases;
or, if subscribed for:
iv) request the service provider to begin a three-way conversation (see managing an active three-way conversation below).
Note -- In some networks, the served user can invoke this step only after the call to the third party reaches the active state.
Active party
If the active party disconnects, the service provider would notify the served user that the other party (e.g. user B) is still held and wait for one of the following events:
-- a request from the served user that the held party be retrieved;
-- a request from the held party to disconnect.
If neither event occurs within a brief time interval, the service provider will disconnect the held party.
Held party
If the held party disconnects, the service provider will clear that connection, resulting in a simple active call between the served user and the currently-active user.
2.3.2.2.3 Managing an active three-way conversation | (See Figure 4/I.254, Sheet 3)
Note -- The extent to which the service provider re-uses the existing resources (e.g. a bridge) to form the resulting, simple call is a service provider option.
Served user
During an active three-way conversation, the served user can request that the service provider:
i) end the three-way conversation;
Note -- Signalling procedures for disconnecting a multi-connection call are not yet defined.
ii) disconnect himself from the three-way conversation. Since the served user is also the controller (and normally the one that is charged for the call), this shall result in the entire three-way call being cleared.
Note -- An anticipated future extension to this service and the Call Transfer service is the ability to negotiate charging and control responsibilities, thus permitting the call to continue after the served user has disconnected (See Figure 4/I.254: call transfer from Active Three-Way Conversation state).
iii) explicitly disconnect one of the other parties which would result in a simple active call between the served user and the remaining other party;
58 Fascicle III.7 -- Rec. I.254
iv) place his connection into the conversation on hold (and, typically, later retrieve it).
Note -- While the served user is held, the other parties (B and C) may continue to communicate.
v) split off one of the parties in order to have a private communication with that party. This results in that party being split off from the conversation, the connection between the served user and the other party on the three-way call being placed on hold, and the connection between the served user and the designated party being active.
Fascicle III.7 -- Rec. I.254 59
|
Other party (B or C) Either of the other parties (users B or C) can ask the service provider to: i) release it from the three-way conversation which results in a simple active call between the served user and the remaining |
party; |
||
|
2.3.3 |
ii) place its connection to the three-way conversation on hold (and, typically, later retrieve it); Note -- While the served user is held, the other parties (i.e. served user and remaining party) may continue to communicate. Exceptional procedures |
2.3.3.1 Activation/deactivation/registration
None identified.
|
2.3.3.2 Invocation and operation None identified. 2.3.4 Alternative procedures 2.3.4.1 Activation/deactivation/registration |
None identified.
2.3.4.2 Invocation and operation
None identified, except for the point made above regarding variations due to different terminal capabilities.
2.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 |
It shall be possible to charge the subscriber accurately for the service. |
||
|
2.5 |
Interworking None identified. |
Interworking Requirements None identified. |
|
|
2.6 60 |
Interaction Fascicle |
Interaction with other supplementary services III.7 -- Rec. I.254 |
2.6.1 Call Waiting
Assume that users A, B and C have subscribed to the Call Waiting service, then:
-- if a call waiting indication was presented to user A and/or user B either before or during the Three-party-Service invocation, then the call waiting indication would still be present after the Three-Party Service is active. While the Three-Party Service is active, the party with the waiting call may put his active call on hold to accept the waiting call;
|
-- 1) 2) 3) 4) -- |
a call waiting indication may be presented to any party involved in a Three-Party Service call, and that party: may be active in a two-party call (A-B or A-C), may be on hold (B during A-C, C during A-B), may be active in a three-way conversation, or may have his connection to the three-way conversation on hold; it may be desirable to include a capability of accepting an incoming call as part of Three-Party Service. Currently a user could |
alternate between the first call and the second (waiting or answered) call by combining hold and retrieve requests. A user could also join the second (waiting or active) call to the first call by invoking a three- (or more) party conference call.
Fascicle III.7 -- Rec. I.254 61
2.6.2 Call Transfer
Call Transfer can be invoked in either the Held A¬ ñB(C) && Active A | (raC(B) state (see Figure 2/I.252 for Call Transfer service) or the Active Three-Way Conversation state (see Figure 5/I.254, call transfer from Active Three-Way Conversation state).
|
2.6.3 |
Connected Line Identification Presentation No impact supplementary service affects the operation of the other supplementary service. |
|
|
2.6.4 |
Connected Line Identification Presentation No impact, i.e. neither supplementary service affects the operation of the other supplementary service. |
|
|
2.6.5 |
Calling Line Identification Presentation No impact, i.e. neither supplementary service affects the operation of the other supplementary service. |
|
|
2.6.6 |
Calling Line Identification Restriction No impact, i.e. neither supplementary service affects the operation of the other supplementary service. |
|
|
2.6.7 |
Closed User Group Assume that a user A, who has subscribed to the Three-Party Service, has an established call with user B and wishes to create a |
three-party call by including a user C (either a minimum Three-Party Service or a three-way conversation).
When user A invokes the Three-Party Service and places a call to user C, the service provider shall check that all CUG conditions are met between users A and C but is not required to check CUG conditions between users B and C at this point since user A may wish to only have a minimal Three-Party Service call.
If any of the parties to be involved in the three-party call are also a CUG member, then CUG conditions must be met by all of the parties before a three-way conversation can be formed.
2.6.8 Conference Calling
A served user who has invoked Three-Party Service to create a three-way conversation may convert the three-way conversation to a conference call by invoking the Conference Calling Service and identifying the Party IDs of the currently existing other two parties as part of the conference invocation. This requires that the served user of the Three-Party Service has also subscribed to the Conference Calling service. For other interactions, see § 1.6.12.
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 (Call Forwarding) services
If the served user attempts to establish the second call to a user C who has Call Forwarding activated, and the appropriate forwarding conditions are met, the forwarding-to user will be alerted and treated in all other respects as if the call had been placed to him.
2.6.11 Line Hunting
62 Fascicle III.7 -- Rec. I.254
No impact, i.e. neither supplementary service affects the operation of the other supplementary service.
Fascicle III.7 -- Rec. I.254 63
2.6.12 Three-Party Service
The served user (A) may treat a Three-Party Service call that has reached the Three-Way Conversation service state as an ``existing call'' upon which the minimal Three-Party Service may be invoked. That is, if the served user A is in a three-way conversation with parties B and C and invokes (minimal) Three-Party Service on it, the service provider will place the served user's connection to the conversation on hold (with channel reservation) and allow the served user to establish a call to another party (D). Once the call to user D reaches the alerting state, any of the procedures in § 2.3.2.2.2 may be used to manage the call to party D and the ``three-way conversation'' call.
2.6.13 User-to-User Signalling
While adding the third party (user C) to the three-party service, the served user (user A) can send and receive UUI (services 1, 2 and 3) from the new party until the new party is added to a three-way conversation.
The served user will be able to send and receive UUI (service 3) to both remote parties (users B and C) on a three-way conversation individually and in some networks optionally broadcast UUI (service 3) messages to both parties (see Note). UUI (service 3) cannot be sent between remote parties (users B and C) in association with the three-way conversation.
Note -- This assumes that each party can be uniquely identified.
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
A served user who has all of his parties on hold would not be able to invoke the Three-Party Service, since he is not active on any given call.
A served user A engaged in an active call to a user B shall be able to invoke the Three-Party Service (if subscribed to) to a user C already on hold to served user A. This will allow served user A to create a three-way conversation with user B and previously held user C.
Any party involved in a Three-Party Service call (either minimum service or a three-way conversation) will be able to put the Three-Party Service call on hold. Once a party puts a Three-Party Service call on hold, that party may retrieve any other call it has previously held.
For any party involved in a three-party call which has also subscribed to the hold service without channel reservation, that party may place the Three-Party Service on hold and
1) initiate a new call;
2) receive a call (e.g. to process a Call Waiting request); or
3) complete a call to a new free party that previously was busy and for which the Completion of Calls to Busy Subscribers (CCBS) had been invoked (see Note).
Note -- The Completion of Calls to Busy Subscribers supplementary service needs further study.
The Call Hold service allows a user to switch (by hold and retrieve) between ''parties'' where a party may be a single user, a three-way conversation, or a conference call. Thus, a party in a three-way conversation may switch between the three-way conversation and another ``party'' hold, the ``party'' being a single user, another three-party call or a conference call.
2.6.16 Advice of Charge
No impact, i.e. neither supplementary service affects the operation of the other supplementary services.
2.7 Dynamic description
64 Fascicle III.7 -- Rec. I.254
The dynamic description of this service is shown in Figure 4/I.254.
Fascicle III.7 -- Rec. I.254 65
Figure 4/I.254 (feuillet 1 sur 3), (N), p. 18 66 Fascicle III.7 -- Rec. I.254
Figure 4/I.254 (feuillet 2 sur 3), (N), p. 19 Fascicle III.7 -- Rec. I.254 67
Figure 4/I.254 (feuillet 3 sur 3), (N), p. 20 68 Fascicle III.7 -- Rec. I.254
Figure 5/I.254, (N), p. 21 Fascicle III.7 -- Rec. I.254 69
Figure 6/I.254, (N), p. 22 70 Fascicle III.7 -- Rec. I.254
Figure 7/I.254, (N), p. 23 Fascicle III.7 -- Rec. I.254 71
72 Fascicle III.7 -- Rec. I.254