1 MultiParty Service (MPTY)
22.0843GPPMultiParty (MPTY) supplementary serviceStage 1TS
1.1 Definition
This Supplementary Service provides a mobile subscriber with the ability to have a multi-connection call, i.e. a simultaneous communication with more than one party.
1.2 Description
1.2.1 Description
A precondition for the multi-party service is that the served mobile subscriber is in control of one active call and one call on hold, both calls having been answered. In this situation the served mobile subscriber can request the network to begin the multiParty service.
Once a multiParty call is active, remote parties may be added, disconnected or separated (i.e. removed from the multiParty call but remain connected to the served mobile subscriber).
The maximum number of remote parties is 5.
1.2.1.1 Indication about multiParty status
Notification shall be sent towards the served mobile subscriber and all the remote parties in a multiParty call at the invocation of this Supplementary Service. In addition, a notification shall always be sent towards all remote parties (i.e. not towards the served mobile subscriber) every time a new party is added to the multiParty call. Notifications shall also be sent to remote parties when they are put on hold and when they are retrieved in accordance with normal Call Hold procedures.
In the case where a previously private communication is added again to the multiParty call, a notification shall be sent towards all remote parties.
NOTE: During an interim period of time, some networks might not support the sending of the notifications to the remote parties.
1.2.2 Applicability to telecommunication services
The applicability of this Supplementary Service is defined in TS 22.004.
1.2.3 Terminology
Served Mobile Subscriber
During the invocation and active phase, the service is under the control of the served mobile subscriber, i.e. the one who has subscribed to the service.
Remote Party
Any participant in the multiParty call who is not the served mobile subscriber.
1.3 Normal procedures with successful outcome
1.3.1 Provision
This Supplementary Service is provisioned for all Basic Services (BS) subscribed to and to which it is applicable, i.e. not to any subset of these BS.
The provision of the Call Hold Supplementary Service is also required.
1.3.2 Withdrawal
Withdrawal of the service is made by the service provider upon request by the subscriber or for service provider reasons.
1.3.5 Activation
The Supplementary Service shall be activated by the service provider as a result of provision.
1.3.6 Deactivation
The Supplementary Service shall be deactivated by the service provider as a result of withdrawal.
1.3.7 Invocation
Multi-Party service will be invoked by the served mobile subscriber by use of a control procedure, as defined in TS 22.030.
1.3.8 Normal operation with successful outcome
Only the served mobile subscriber shall be able to add remote parties to the multiParty call.
1.3.8.1 Beginning the multiParty call
When the served mobile subscriber invokes multiParty service from the precondition defined in Section 1.2.1, the network joins the active call and the call on hold together into a multiParty call in which the served mobile subscriber and the remote parties can all communicate with one another.
1.3.8.2 Managing an active multiParty call
During an active multiParty call, the served mobile subscriber shall be able to:
(i) Add another remote party, to which a private communication has been established using the same procedures as in Section 1.3.8.1, if the number of remote parties does not then exceed the maximum number allowed, which results in an active multiParty call.
A "MPTY invoke" notification shall be sent towards all remote parties.
A Retrieve notification (according to TS 22.083) shall be sent towards all previously held remote parties.
(ii) Put the connection to multiParty call on hold, i.e. place her connection to the multiParty call on hold (and typically later retrieve it). The served mobile subscriber may make an enquiry call (e.g. to a potential new remote party) or process a Call Waiting request from this state. While the multiParty call is on hold the remaining remote parties in the multiParty call can have communication with each other.
As a result of this scenario, the enquiry call or the accepted waiting call can be added to the multiParty call or released. If the call is released by the served mobile subscriber or by the remote party, the served mobile subscriber is in control of a held multiParty call.
A Hold notification (according to TS 22.083) shall be sent towards all remote parties.
(iii) Separate a remote party:
Explicitly choose one remote party to have a private communication with. This results in that remote party being removed from the multiParty call which is placed on hold, and the conversation between the served mobile subscriber and the designated remote party being a normal active call (see NOTE 1). The remaining remote parties may have communication with each other in this state.
As a result of this scenario the private communication can be added again to the multiParty call or released. If the private call is released by the served mobile subscriber or by the remote party, the served mobile subscriber is in control of a held multiParty call.
A Hold notification (according to TS 22.083) shall be sent towards all remote parties, except the designated remote party to which a private communication was established.
(iv) Terminate the entire multiParty call. When the served mobile subscriber releases, this is interpreted as a request for termination of the entire multiParty call even if there are calls on hold.
No further notification shall be sent.
(v) Disconnect a remote party:
Explicitly release the remote parties on a one at a time basis (see NOTE 1). In the case when no remote parties remain, the multiParty call is terminated.
NOTE 1: If the served mobile subscriber has a private communication with one of the remote parties and this remote party disconnects or is disconnected a notification is sent towards the served mobile subscriber that she has a multiParty call on hold.
The notification about the held multiparty call towards the served mobile subscriber is given by the MS, not by the network.
1.3.8.3 Managing a held multiParty call
During a held multiParty call the served mobile subscriber shall be able to:
1) Retrieve the held multiParty call, which results in an active multiParty call.
2) Initiate a new call.
3) Process a Call Waiting request.
4) Disconnect the held multiParty call. All calls belonging to the multiParty call shall be released.
5) Disconnect a single remote party.
During a held multiParty call the served mobile subscriber shall NOT be able to:
Retrieve a single remote party.
1.3.8.4 Managing a single call and a MPTY
1.3.8.4.1 Single active call
If the served mobile subscriber is connected to a single active call (regardless whether it is a private communication or a new initiated call) and has a MPTY on hold, she is able to:
1) Disconnect the single active call.
2) Disconnect the held MPTY.
3) Disconnect both. All calls, even if they are on hold, shall be released.
4) Join the single active call and the held MPTY together.
This would result in an active MPTY, except if the number of remote parties exceeds the number allowed.
A "MPTY invoke" notification shall be sent towards all remote parties.
A Retrieve notification (according to TS 22.083) shall be sent towards the previously held remote party.
5) Alternate between both calls.
1.3.8.4.2 Active MPTY and held call
If the served mobile subscriber is connected to a active MPTY and has a single call on hold, she is able to:
1) Disconnect the active MPTY.
2) Disconnect the single held call.
3) Disconnect both. All calls, even if they are on hold, shall be released.
4) Join the single held call and the active MPTY together. This would result in an active MPTY, except if the number of remote parties exceeds the number allowed.
A "MPTY invoke" notification shall be sent towards all remote parties.
A Retrieve notification (according to TS 22.083) shall be sent towards all previously held remote parties.
5) Alternate between both calls.
If the served mobile subscriber is connected to a active Multi Party call and has a single call on hold, a request for establishing a private communication will be rejected by the network. (Because this would lead to an active call and two calls on hold, which is not supported according to the Call Hold Supplementary Service).
An indication will be given to the served mobile subscriber with the reason for failure.
1.3.8.5 Remote parties in a Multi-Party Call
Any of the remote parties shall be able to:
a) Put her connection to the multiParty call on hold (and typically later retrieve it). The requirements of the Call Hold service then apply;
b) Release from the multiParty call.
If a remote party releases and no remote party then remains, the requirements of the normal call release procedures then apply.
1.4 Exceptional procedures or unsuccessful outcome
If a served mobile subscriber attempts to invoke multiParty service and the network cannot accept that request, the request will be rejected and an indication will be given to the served mobile subscriber with a reason for denial. Some possible reasons for rejection are:
– service not subscribed;
– resources cannot be allocated;
– conflicting situation with other Supplementary Services;
– calls are not in appropriate state (e.g. one or more calls are not answered or are in the process of being cleared);
– service not supported by the LPLMN.
If the service provider cannot satisfy the request to add a further remote party (e.g. if the multiParty call has been cleared or if the maximum number of remote parties allowed has already been reached) the served mobile subscriber shall receive an indication that the request is denied, with the reason for failure.
If the radio path of the served mobile subscriber is lost permanently for any reason, the multiParty call shall be released.
1.5 Alternate procedures
None identified.
1.6 Interactions with other Supplementary Services
1.6.81.3 Connected line identification presentation
Remote parties in an existing multiParty call who have subscribed to connected line number identification presentation will not receive a new remote party’s number whenever a served mobile subscriber adds a new remote party to the multiParty call.
1.6.82.1 Call forwarding unconditional
No interaction, the following text shall give a clarification.
Calling subscriber: If a calling subscriber attempts to establish a multiParty call to a subscriber with call forwarding unconditional active and operative, the forwarded-to subscriber will be alerted and can be added to the conference.
Forwarded-to subscriber: A forwarded-to subscriber can establish a multiParty call using an existing forwarded call as one of the multiParty connections.
1.6.82.2 Call forwarding on mobile subscriber Busy
No interaction, the following text shall give a clarification.
Calling subscriber: If a calling subscriber attempts to establish a multiParty call to a subscriber with call forwarding on mobile subscriber busy active and operative, and the forwarding condition is met, the forwarded-to subscriber will be alerted and can be added to the conference.
Forwarded-to subscriber: A forwarded-to subscriber can establish a multiParty call using an existing forwarded call as one of the multiParty connections.
1.6.82.3 Call forwarding on no reply
Same as the interaction between call forwarding on mobile subscriber busy and multiParty call.
1.6.82.4 Call Forwarding on mobile subscriber not reachable
Same as the interaction between call forwarding on mobile subscriber busy and multiParty call.
1.6.83.1 Call waiting
No interaction. The following text is included for clarification:
A user who is active on a multiParty call, either as the served mobile subscriber or as remote party, may receive an indication of a waiting call, provided that the maximum number of calls at the mobile equipment will not be exceeded.
After the multiParty call has been put on hold by this user, the waiting call may be accepted by the user.
1.6.83.2 Call hold
Any party involved in an active multiParty call (i.e. the served mobile subscriber or a remote party) may place the connection to the multiParty call on hold and later retrieve it.
1.6.84.1 Multi-party service
It shall be possible for any remote party in a multiParty call to alternate between two different multiParty calls.
Served Mobile Subscriber:
The served mobile subscriber cannot control more than one multiParty call at a time.
It shall not be possible to invoke multiParty service if either or both of the initial calls are active parts of one or two other multiParty calls.
Multi-Party Call controlled by one of the remote parties:
The network will not be required to prevent that a leg to one of the other remote parties can be part of another multiParty call controlled by that remote party.
1.6.85.1 Closed user group
See TS 22.085.
1.6.88.1 Barring of all outgoing calls
If barring of all outgoing calls is activated after a multiParty call is invoked, any outgoing calls in progress within that multiParty call will not be barred. Any new outgoing call is barred.
1.6.88.2 Barring of outgoing international calls
Same as interworking between barring of all outgoing calls and multiParty service.
1.6.88.4 Barring of outgoing international calls except those directed to the home PLMN country
Same as interaction between barring of all outgoing calls and multiParty service.
1.6.88.6 Barring of incoming calls
If barring of incoming calls is activated after a multiParty call is invoked, any incoming calls in progress within that multiParty call will not be barred. Any new incoming call is barred.
1.6.88.7 Barring of incoming calls when roaming outside the home PLMN country
If barring of incoming calls when roaming outside the home PLMN country is made active and operative after a multiParty call is invoked, any incoming calls in progress within that multiParty call will not be barred. Any new incoming call is barred.
1.7 Interworking considerations
Interworking with non-PLMN/ISDN:
If a remote party is neither a PLMN nor an ISDN subscriber, it is possible that she is not notified.
Mapping of notifications:
Direction ISDN to PLMN:
3PTY and CONF shall be mapped onto MPTY.
Direction PLMN to ISDN:
MPTY shall be mapped onto CONF.
Annex A (informative):
Change history
Change history |
|||||||||||
TSG SA# |
SA Doc. |
SA1 Doc |
Spec |
CR |
Rev |
Rel |
Cat |
Subject/Comment |
Old |
New |
WI |
Jun 1999 |
GSM 02.84 |
Transferred to 3GPP SA1 |
7.0.0 |
||||||||
SA#04 |
22.084 |
R99 |
Transferred to 3GPP SA1 |
3.0.0 |
|||||||
SP-05 |
SP-99479 |
S1-99631 |
22.084 |
001 |
R99 |
D |
Editorial changes for alignment |
3.0.0 |
3.0.1 |
Editorial changes |
|
SP-11 |
SP-010065 |
S1-010258 |
22.084 |
Rel-4 |
Transferred to 3GPP Release 4 |
3.0.1 |
4.0.0 |
||||
SP-15 |
SP-020045 |
S1-020457 |
22.084 |
002 |
– |
Rel-4 |
F |
Editorial CR to correct terms and references |
4.0.0 |
4.1.0 |
CORRECT |
SP-16 |
SP-020267 |
S1-021043 |
22.084 |
Rel-5 |
Updated from Rel-4 to Rel5 |
4.1.0 |
5.0.0 |
||||
SP-26 |
SP-040744 |
S1-040997 |
22.084 |
Rel-6 |
Updated from Rel-5 to Rel-6 |
5.0.0 |
6.0.0 |
||||
SP-36 |
22.084 |
Rel-7 |
Updated from Rel-6 to Rel-7 |
6.0.0 |
7.0.0 |
||||||
SP-42 |
– |
– |
Rel-8 |
Updated from Rel-7 to Rel-8 |
7.0.0 |
8.0.0 |
|||||
SP-46 |
– |
– |
– |
– |
– |
– |
– |
Updated to Rel-9 by MCC |
8.0.0 |
9.0.0 |
|
2011-03 |
– |
– |
– |
– |
– |
– |
– |
Update to Rel-10 version (MCC) |
9.0.0 |
10.0.0 |
|
2012-09 |
– |
– |
– |
– |
– |
– |
– |
Updated to Rel-11 by MCC |
10.0.0 |
11.0.0 |
|
2014-10 |
– |
– |
– |
– |
– |
– |
– |
Update to Rel-12 version (MCC) |
11.0.0 |
12.0.0 |
|
2015-12 |
– |
– |
– |
– |
– |
– |
– |
Updated to Rel-13 by MCC |
12.0.0 |
13.0.0 |
|
2017-03 |
– |
– |
– |
– |
– |
– |
– |
Updated to Rel-14 by MCC |
13.0.0 |
14.0.0 |
|
2018-06 |
– |
– |
– |
– |
– |
– |
– |
Updated to Rel-15 by MCC |
14.0.0 |
15.0.0 |
|
SA#88e |
– |
– |
– |
– |
– |
– |
– |
Updated to Rel-16 by MCC |
15.0.0 |
16.0.0 |
|
2022-03 |
– |
– |
– |
– |
– |
– |
– |
Updated to Rel-17 by MCC |
16.0.0 |
17.0.0 |