7.1.2 On-network group call
23.2813GPPFunctional architecture and information flows to support Mission Critical Video (MCVideo)Release 18Stage 2TS
7.1.2.1 General
This subclause contains procedures for group call across a single and multiple MCVideo servers, and associated functions such as emergency call, broadcast call and others.
Two variations of group call model are described in subclause 7.1.2.3, the pre-arranged group call and the chat group call. Each of the subsequent group call types in subclause 7.1.2.4 onwards are applicable to either call model.
7.1.2.2 Information flows for group call in on-network
7.1.2.2.1 Group call request (MCVideo client – MCVideo server)
Table 7.1.2.2.1-1 describes the information flow group call request from the MCVideo client to the MCVideo server.
Table 7.1.2.2.1-1: Group call request (MCVideo client – MCVideo server)
Information Element |
Status |
Description |
MCVideo ID |
M |
The MCVideo ID of the calling party |
Functional alias |
O |
The functional alias of the calling party |
MCVideo group ID |
M |
The MCVideo group ID of the group on which the call is requested |
SDP offer |
M |
Media parameters of MCVideo clients |
Implicit transmit media request |
O |
When originating client requests the permission to transmit media, this element shall be included |
Broadcast indicator |
O |
Indicates that the group call request is for a broadcast group call |
Requested priority |
O |
Application priority level requested for this call |
7.1.2.2.2 Group call request
Table 7.1.2.2.2-1 describes the information flow group call request from the MCVideo server to the MCVideo server and from the MCVideo server to the MCVideo client.
Table 7.1.2.2.2-1: Group call request
Information Element |
Status |
Description |
MCVideo ID |
M |
The MCVideo ID of the calling party |
Functional alias |
O |
The functional alias of the calling party |
MCVideo group ID |
M |
The MCVideo group ID of the group on which the call is initiated |
SDP offer |
M |
Media parameters of MCVideo server |
Broadcast indicator |
O |
Indicates that the group call request is for a broadcast group call |
7.1.2.2.3 Group call response
Table 7.1.2.2.3-1 describes the information flow group call response from the MCVideo server to the MCVideo server and from the MCVideo server to the MCVideo client.
Table 7.1.2.2.3-1: Group call response
Information Element |
Status |
Description |
MCVideo ID |
M |
The MCVideo ID of the calling party |
MCVideo group ID |
M |
The MCVideo group ID of the group on which the call is requested |
SDP answer |
M |
Media parameters selected |
Result |
M |
Result of the group call request (success or failure) |
7.1.2.2.4 Group call response (MCVideo client – MCVideo server)
Table 7.1.2.2.4-1 describes the information flow group call response from the MCVideo client to the MCVideo server.
Table 7.1.2.2.4-1: Group call response (MCVideo client – MCVideo server)
Information Element |
Status |
Description |
MCVideo ID |
M |
The MCVideo ID of the target MCVideo group member |
MCVideo group ID |
M |
The MCVideo group ID of the group on which the call is initiated |
SDP answer |
M |
Media parameters selected |
Result |
M |
Result of the group call request (success or failure) |
7.1.2.2.5 Group call release request
Table 7.1.2.2.5-1 describes the information flow group call release request from the MCVideo server to the MCVideo server and from the MCVideo server to the MCVideo client.
Table 7.1.2.2.5-1: Group call release request
Information Element |
Status |
Description |
MCVideo ID |
M |
The MCVideo ID of the MCVideo group member |
MCVideo group ID |
M |
The MCVideo group ID of the group on which the call is released |
7.1.2.2.6 Group call release request (MCVideo client – MCVideo server)
Table 7.1.2.2.6-1 describes the information flow group call release request from the MCVideo client to the MCVideo server.
Table 7.1.2.2.6-1: Group call release request (MCVideo client – MCVideo server)
Information Element |
Status |
Description |
MCVideo ID |
M |
The MCVideo ID of the MCVideo group member |
MCVideo group ID |
M |
The MCVideo group ID of the group on which the call is released |
7.1.2.2.7 Group call release response
Table 7.1.2.2.7-1 describes the information flow group call release response from the MCVideo server to the MCVideo server and from the MCVideo client to the MCVideo server.
Table 7.1.2.2.7-1: Group call release response
Information Element |
Status |
Description |
MCVideo ID |
M |
The MCVideo ID of the MCVideo group member |
MCVideo group ID |
M |
The MCVideo group ID of the group on which the call is released |
7.1.2.2.8 Group call rejoin request
Table 7.1.2.2.8-1 describes the information flow group call rejoin request from the MCVideo server to the MCVideo server and from the MCVideo client to the MCVideo server.
Table 7.1.2.2.8-1: Group call rejoin request
Information Element |
Status |
Description |
MCVideo ID |
M |
The MCVideo ID of the re-joining MCVideo group member |
Functional alias |
O |
The functional alias of the re-joining MCVideo group member |
MCVideo group ID |
M |
The MCVideo group ID of the group on which the call is on-going |
SDP offer |
M |
Media parameters of MCVideo client |
7.1.2.2.9 Group call rejoin response
Table 7.1.2.2.9-1 describes the information flow group call rejoin response from the MCVideo server to the MCVideo server and from the MCVideo server to the MCVideo client.
Table 7.1.2.2.9-1: Group call rejoin response
Information Element |
Status |
Description |
MCVideo ID |
M |
The MCVideo ID of the MCVideo group member rejoining the group call |
MCVideo group ID |
M |
The MCVideo group ID of the group on which the call is on-going |
SDP answer |
M |
Media parameters selected |
7.1.2.2.10 Group join request
Table 7.1.2.2.10-1 describes the information flow group join request from the MCVideo server to the MCVideo server and from the MCVideo client to the MCVideo server.
Table 7.1.2.2.10-1: Group join request
Information Element |
Status |
Description |
MCVideo ID |
M |
The MCVideo ID of the MCVideo group member joining the group communications for the group |
MCVideo group ID |
M |
The MCVideo group ID of the group to which the group communication is requested |
SDP offer |
M |
Media parameters of MCVideo client |
Implicit transmit media request |
O |
An indication that the user is also requesting the permission to transmit video |
Requested priority |
O |
Application priority level requested for this call |
7.1.2.2.11 Group join response
Table 7.1.2.2.11-1 describes the information flow group join response from the MCVideo server to the MCVideo server and from the MCVideo server to the MCVideo client.
Table 7.1.2.2.11-1: Group join response
Information Element |
Status |
Description |
MCVideo ID |
M |
The MCVideo ID of the MCVideo group member joining the group communications for the group |
MCVideo group ID |
M |
The MCVideo group ID of the group to which the group communication is requested |
SDP answer |
M |
Media parameters selected |
7.1.2.2.12 Group call leave request
Table 7.1.2.2.12-1 describes the information flow group call leave request from the MCVideo server to the MCVideo server and from the MCVideo server to the MCVideo client.
Table 7.1.2.2.12-1: Group call leave request
Information Element |
Status |
Description |
MCVideo ID |
M |
The MCVideo ID of the MCVideo group member which has been de-affiliated |
MCVideo group ID |
M |
The MCVideo group ID of the group on which the call is on-going |
7.1.2.2.12a Group call leave request
Table 7.1.2.2.12a-1 describes the information flow group call leave request from the MCVideo client to the MCVideo server and from the MCVideo server to the MCVideo server.
Table 7.1.2.2.12a-1: Group call leave request
Information Element |
Status |
Description |
MCVideo ID |
M |
The MCVideo ID of the MCVideo group member leaving the group call |
MCVideo group ID |
M |
The MCVideo group ID of the group on which the call is on-going |
7.1.2.2.13 Group call leave response
Table 7.1.2.2.13-1 describes the information flow group call leave response from the MCVideo client to the MCVideo server and from the MCVideo server to the MCVideo server.
Table 7.1.2.2.13-1: Group call leave response
Information Element |
Status |
Description |
MCVideo ID |
M |
The MCVideo ID of the MCVideo group member which has been de-affiliated |
MCVideo group ID |
M |
The MCVideo group ID of the group on which the call is on-going |
7.1.2.2.13a Group call leave response
Table 7.1.2.2.13a-1 describes the information flow group call leave response from the MCVideo server to the MCVideo server and from the MCVideo server to the MCVideo client.
Table 7.1.2.2.13a-1: Group call leave response
Information Element |
Status |
Description |
MCVideo ID |
M |
The MCVideo ID of the MCVideo group member leaving the group call |
MCVideo group ID |
M |
The MCVideo group ID of the group on which the call is on-going |
7.1.2.2.14 Void
7.1.2.2.15 Void
7.1.2.2.16 Void
7.1.2.2.17 Void
7.1.2.2.18 MCVideo emergency group call request
Table 7.1.2.2.18-1 describes the information flow emergency group call request from the MCVideo client to the MCVideo server, from the MCVideo server to the MCVideo server and from the MCVideo server to the MCVideo client.
Table 7.1.2.2.18-1: MCVideo emergency group call request
Information Element |
Status |
Description |
MCVideo ID |
M |
The identity of the calling party |
Functional alias |
O |
The functional alias of the calling party |
MCVideo group ID |
M |
The MCVideo group ID on which the call is to be conducted |
Emergency indicator |
M |
Indicates that the group call request is an MCVideo emergency call |
Alert indicator |
M |
Indicates whether an emergency alert is to be sent |
Requested priority |
O |
Priority level requested for the call |
Implicit transmit media request (see NOTE) |
O |
Indicates that the originating client requests the permission to transmit media. |
NOTE: This element shall be included only when the originating client requests the the permission to transmit media. |
7.1.2.2.19 MCVideo emergency group call response
Table 7.1.2.2.19-1 describes the information flow emergency group call response from the MCVideo client to the MCVideo server, from the MCVideo server to the MCVideo server and from the MCVideo server to the MCVideo client.
Table 7.1.2.2.19-1: MCVideo emergency group call response
Information Element |
Status |
Description |
MCVideo ID |
M |
The identity of the calling party |
MCVideo group ID |
M |
The MCVideo group ID on which the call is to be conducted |
Result |
M |
Result of the MCVideo emergency group call request (success or failure) |
7.1.2.2.20 MCVideo in-progress emergency group state cancel request
Table 7.1.2.2.20-1 describes the information flow MCVideo in-progress emergency group state cancel request from the MCVideo client to the MCVideo server and from the MCVideo server to the MCVideo server.
NOTE: In Rel-14 and Rel-13 versions of this specification the name of this information flow is "MCVideo emergency group call cancel request".
Table 7.1.2.2.20-1: MCVideo in-progress emergency group state cancel request
Information Element |
Status |
Description |
MCVideo ID |
M |
The identity of the cancelling party |
MCVideo group ID |
M |
The MCVideo group ID on which the MCVideo in-progress emergency state is to be cancelled. |
Alert indicator |
O |
Indicates whether the emergency alert of the cancelling party is to be cancelled |
7.1.2.2.21 MCVideo in-progress emergency group state cancel response
Table 7.1.2.2.21-1 describes the information flow MCVideo in-progress emergency group state cancel response from the MCVideo server to the MCVideo server and from the MCVideo server to the MCVideo client.
NOTE: In Rel-14 and Rel-13 versions of this specification the name of this information flow is "MCVideo emergency group call cancel response".
Table 7.1.2.2.21-1: MCVideo in-progress emergency group state cancel response
Information Element |
Status |
Description |
MCVideo ID |
M |
The identity of the cancelling party |
MCVideo group ID |
M |
The MCVideo group ID on which the MCVideo in-progress emergency state is to be cancelled. |
7.1.2.2.22 MCVideo imminent peril group call request
Table 7.1.2.2.22-1 describes the information flow MCVideo imminent peril group call request from the MCVideo client to the MCVideo server, from the MCVideo server to the MCVideo server and from the MCVideo server to the MCVideo client.
Table 7.1.2.2.22-1: MCVideo imminent peril group call request
Information Element |
Status |
Description |
MCVideo ID |
M |
The identity of the calling party |
Functional alias |
O |
The functional alias of the calling party |
MCVideo group ID |
M |
The MCVideo group ID on which the call is to be conducted |
Requested priority |
O |
Priority level requested for the call |
Imminent peril indicator |
M |
Indicates that the group call request is an imminent peril call |
7.1.2.2.23 MCVideo imminent peril group call response
Table 7.1.2.2.23-1 describes the information flow MCVideo imminent peril group call response from the MCVideo client to the MCVideo server, from the MCVideo server to the MCVideo server and from the MCVideo server to the MCVideo client.
Table 7.1.2.2.23-1: MCVideo imminent peril group call response
Information Element |
Status |
Description |
MCVideo ID |
M |
The identity of the calling party |
MCVideo group ID |
M |
The MCVideo group ID on which the call is to be conducted |
Result |
M |
Result of the MCVideo imminent peril group call request (success or failure) |
7.1.2.2.24 MCVideo imminent peril group call cancel request
Table 7.1.2.2.24-1 describes the information flow MCVideo imminent peril group call cancel request from the MCVideo client to the MCVideo server, from the MCVideo server to the MCVideo server and from the MCVideo server to the MCVideo client.
Table 7.1.2.2.24-1: MCVideo imminent peril group call cancel request
Information Element |
Status |
Description |
MCVideo ID |
M |
The identity of the cancelling party |
MCVideo group ID |
M |
The MCVideo group ID on which the imminent peril is to be cancelled |
7.1.2.2.25 MCVideo imminent peril group call cancel response
Table 7.1.2.2.25-1 describes the information flow MCVideo imminent peril group call cancel response from the MCVideo client to the MCVideo server, from the MCVideo server to the MCVideo server and from the MCVideo server to the MCVideo client.
Table 7.1.2.2.25-1: MCVideo imminent peril group call cancel response
Information Element |
Status |
Description |
MCVideo ID |
M |
The identity of the cancelling party |
MCVideo group ID |
M |
The MCVideo group ID on which the imminent peril is to be cancelled |
7.1.2.3 Group call within one MC system
7.1.2.3.1 Group call models
7.1.2.3.1.1 Pre-arranged group call
7.1.2.3.1.1.1 General
A pre-arranged group call is initiated by one of the affiliated group members. The initiation of a pre-arranged group call results in all other affiliated group members being invited. Media plane resources are reserved (on-demand) or a pre-established session is associated during the group call setup procedure and released (if on-demand session) or de-associated (if pre-established session) when the call is released. SIP signalling is used to setup and release pre-arranged group calls.
7.1.2.3.1.1.2 Pre-arranged group call setup
The procedure enables the scenario where an MCVideo client is initiating an MCVideo group call with unicast signalling for communicating with the affiliated members of that group.
Procedures in figure 7.1.2.3.1.1.2-1 are the signalling control plane procedures for the MCVideo client initiating establishment of an MCVideo group call with a pre-arranged group i.e., MCVideo users on client 1, client 2 and client 3 belong to the same group which is defined in the group management server.
Pre-conditions:
1. A pre-arranged group is an MCVideo group that is pre-defined with MCVideo group ID and member list in the group management server. All members of the group belong to the same MC system.
2. It is assumed that MCVideo users on MCVideo client 1, MCVideo client 2 and MCVideo client 3 are already registered for receiving MCVideo service and affiliated.
3. The MCVideo client 1 may have an activated functional alias to be used.
4. The MCVideo server may have subscribed to the MCVideo functional alias controlling server within the MC system for functional alias activation/de-activation updates.
5. The MCVideo user on MCVideo client 1 may have bound a functional alias to the MCVideo group ID (3GPP TS 23.280 [6]).
Figure 7.1.2.3.1.1.2-1: Pre-arranged group call setup
1. User at MCVideo client 1 would like to initiate an MCVideo group call with a selected group (identified by MCVideo group ID). The MCVideo user at MCVideo client 1 may include a functional alias used within the MCVideo group call.
NOTE 1: The selected functional alias is not changed during the group call, i.e. a MCVideo client uses the same functional alias until the group call is released or the MCVideo client has left the group call.
2. MCVideo client 1 sends a group call request towards the MCVideo server via the SIP core, which hosts the group selected by the user and identified by MCVideo group ID. The group call request also contains the MCVideo group ID and an SDP offer containing the MCVideo client media parameters. If the MC service user of MCVideo client 1 has selected a functional alias, then the group call request contains that functional alias. If there is a transmit media request, then the group call request contains an indication for the implicit transmit media request.
3. MCVideo server checks whether the user of MCVideo client 1 is authorized to initiate a group call for the selected group. If a functional alias is present, the MCVideo server checks whether it is allowed to be used and if it has been activated for the user. If authorized and the group call is ongoing for that MCVideo group ID, the MCVideo server adds the requesting MCVideo client 1 to the existing MCVideo group call and notifies the MCVideo client 1 that the MCVideo group call is already in progress. Otherwise, MCVideo server resolves the MCVideo group ID to determine the members of that group and their affiliation status, based on the information from the group management server.
If the functional alias is provided only in the group call request, or via binding, the MCVideo server proceeds with the value that is provided. If the functional alias is provided in both the group call request and via binding, it is up to the MCVideo server implementation to determine a value for the functional alias to be used.
NOTE 2: MCVideo server can have already retrieved the user/group configuration data and locally cached. If the user/group configuration data is not locally cached on the MCVideo server then MCVideo server requests the user/group configuration data from the MCVideo user database/group management server.
4. MCVideo server includes information that it communicates using MCVideo service, offers the same media parameters or a subset of the media parameters contained in the initial received request and sends the corresponding group call request via the SIP core towards the MCVideo clients of each of those affiliated group members. MCVideo users are notified about the incoming group call and, if present, the functional alias of the initiating MC service user is displayed. The MCVideo server indicates whether acknowledgement is required for the call.
5. The receiving MCVideo clients accept the group call request, and a group call response is sent to the group host MCVideo server. This response may contain an acknowledgement. The conditions for sending acknowledgement may be based on configuration.
6. MCVideo server sends the group call response including the selected media parameters to the MCVideo client 1 through the signalling path to inform about successful call establishment.
NOTE 3: Step 6 can occur at any time following step 4b, and prior to step 7 depending on the conditions to proceed with the call.
7. If the initiating MCVideo user requires the acknowledgement from affiliated MCVideo group members, and the required MCVideo group members do not acknowledge the call setup within a configured time (the "acknowledged call setup timeout"), then the MCVideo server may proceed with or abandon the call and then notify the initiating MCVideo user that the acknowledgements did not include all required members according to group policy. This notification may be sent to the initiating MCVideo user by the MCVideo server more than once during the call when MCVideo users join or leave the MCVideo group call.
8. MCVideo client 1, client 2 and client 3 have successfully established media plane and transmission control for communication.
7.1.2.3.1.1.3 Release pre-arranged group call
The procedure enables the scenario where an MCVideo server initiates the termination of an ongoing MCVideo group call for all the participants of that group call, since at least one of the termination conditions are met e.g., last participant leaving, second last participant leaving, initiator leaving, or minimum number of affiliated MCVideo group members are not present.
Procedures in figure 7.1.2.3.1.1.3-1 are the signalling control plane procedures for the MCVideo server initiating termination of an ongoing MCVideo group call.
Figure 7.1.2.3.1.1.3-1: Release pre-arranged group call
1. It is assumed that MCVideo users on MCVideo client 1, client 2 and client 3 are already part of the ongoing group call (e.g., as a result of pre-arranged group call setup).
2. MCVideo server would like to release the MCVideo group call which is ongoing e.g., last participant leaving, initiator leaving, or minimum number of affiliated group members are not present.
3. MCVideo server identifies the participants of the ongoing group call and generates group call release request to release ongoing session.
4. MCVideo server sends a group call release request via SIP core towards each participant of the ongoing group call.
5. MCVideo users are notified about the release of the group call.
6. MCVideo client(s) receiving group call release request, acknowledge towards the MCVideo server by sending a group call release response.
7. MCVideo client 1, client 2 and client 3 have successfully released the media transmission control and media plane resources associated with the group call that is terminated.
7.1.2.3.1.1.4 Late entry pre-arranged group call
Procedures in figure 7.1.2.3.1.1.4-1 are the signalling control plane procedures for the MCVideo server requesting a newly affiliated member or a member coming back from out of coverage to join an ongoing MCVideo group call.
Pre-conditions:
1. MCVideo group is previously defined on the group management server with MCVideo users affiliated to that group. All members of the group belong to the same MC system.
2. It is assumed that MCVideo users on MCVideo client 2 to MCVideo client n are on an ongoing call.
3. Optionally, the MCVideo client 1 may have activated functional alias to be used.
4. The MCVideo server may have subscribed to the MCVideo functional alias controlling server within the MC system for functional alias activation/de-activation updates.
Figure 7.1.2.3.1.1.4-1: Late entry pre-arranged group call
1. MCVideo server determines that MCVideo client 1 which is newly affiliated or coming back from out of coverage has to be invited to join an ongoing group call (late entry).
2. MCVideo server generates group call request including the information such as MCVideo service identifier (possible for the SIP core to route the request to the MCVideo server), MC service group ID of the group invited to join, offer one or more media types and sends towards the MCVideo client 1 via SIP core.
3. MCVideo user at MCVideo client 1 is notified about the incoming group call.
4. Upon MCVideo user at MCVideo client 1 accepting the incoming group call request, MCVideo client 1 sends the group call response including the selected media types to the MCVideo server through the signalling path. If the incoming group call request is rejected by the MCVideo client 1, the MCVideo server should not resend the group call request
5. MCVideo client 1 is successfully added to the ongoing group call and MCVideo users at MCVideo client 1 to MCVideo client n may be notified about the MCVIDEO client 1 joining the group call.
6. A notification with the information of media transmissions in the group call is sent to MCVideo client1.
Editor’s Note: Checking of functional alias of MCVideo client 1 by the MCVideo server is FFS.
7.1.2.3.1.1.5 Rejoining call
Procedures in figure 7.1.2.3.1.1.5-1 are the signalling control plane procedures for the MCVideo client to rejoin an ongoing MCVideo group call (e.g. coming back from out of coverage).
Pre-condition:
1 It is assumed that MCVideo users on MCVideo client 2 to MCVideo client n are on an ongoing call.
2. Optionally, the MCVideo client 1 may have activated functional alias to be used.
3. The MCVideo server may have subscribed to the MCVideo functional alias controlling server within the MC system for functional alias activation/de-activation updates.
Figure 7.1.2.3.1.1.5-1: Rejoin call
1. MCVideo client 1 has necessary information for rejoining an ongoing group call, then the MCVideo client 1 initiates group call rejoin request including the ongoing group call information. The MCVideo user at MCVideo client 1 may include a functional alias used within the MCVideo rejoin request.
2. MCVideo server checks whether the MCVideo client 1 can rejoin the ongoing call (e.g. based upon affiliation status) and checks the functional alias, if present.
3. MCVideo client 1 is informed that the group call rejoin is successful by sending a group call rejoin response.
4. MCVideo client 1 is successfully added to the ongoing group call and MCVideo users at MCVideo client 1 to MCVideo client n may be notified about the MCVideo client 1 joining the group call and the functional alias of MCVideo client 1 may be displayed.
5. A notification with the information of media transmissions in the group call is sent to MCVideo client 1.
7.1.2.3.1.2 Chat group call
7.1.2.3.1.2.1 General
In a chat group (restricted) call model, the MCVideo user individually joins a group call without being explicitly invited by the MCVideo server. The establishment of a chat group (restricted) call does not result in other group members being invited.
Figure 7.1.2.3.1.2.2-1 describes the basic procedure for the MCVideo client initiating an MCVideo group call which uses the chat group (restricted) call model. The chat group (restricted) call model can be used to realize the video conferencing service where only users that have been configured as participants for the video conferencing group are allowed to join the group communications for the given group.
Chat group join mechanism:
– Each MCVideo client sends a group join request when the MCVideo user wants to participate in the group communication for the group. (This message does not impact the MCVideo user’s membership in the group; the MCVideo server will verify that the MCVideo user is an authorized member of the group.)
– The group join request may include a transmit media request. It is assumed that the group join request will be delivered from MCVideo client to MCVideo server using SIP.
– The group join request is used to indicate to the MCVideo server that the MCVideo user associated with the given MCVideo client wishes to participate (begin to receive notifications for media transmissions) from the group.
– The group join request shall cause the MCVideo server to generate an implicit affiliation for the MCVideo user to the group, if the user is not already affiliated to the group.
– The group join request contains the information needed to negotiate media parameters (on demand) or to associate a pre-established session between MCVideo server and MCVideo client for the group call. The group join request can take the form of a SIP invite.
– A selected functional alias is not changed by a MCVideo client during the whole participation within a chat group call, i.e. a MCVideo client uses the same functional alias selected when joining the chat group call until the chat group call is released or the MCVideo client leaves the chat group call.
Subsequent participation in a group call when the group is using the chat model:
– Once an MCVideo client successfully joins a group call which is using the chat model, the MCVideo client connects to the media plane for the media transmission if the media transmission is currently ongoing.
– If the MCVideo group call is not currently ongoing (i.e.: when MCVideo clients on the group call are not sending or receiving media, and the time out between transmission control exchanges has expired) then the newly joined MCVideo client will only have pre-established its media parameters for the call.
– If the newly joined MCVideo user wishes to transmit media to the other joined users of the group using the chat model, then the MCVideo client shall use a normal transmission control procedure for transmitting the media.
– Subsequent group call media transmissions are controlled using transmission control signalling.
– The MCVideo server may tear down the media plane between successive group calls using the chat model, or the MCVideo server may allow the media plane to remain up between successive group calls using the chat model depending on resources.
Leaving and releasing a chat group:
– When a user wants to leave a chat group call, the client shall send a group call leave request to the server and release the media plane.
– The server can release a chat group call by sending a group call release to all joined clients. A server initiated release also releases the media plane for all joined clients.
7.1.2.3.1.2.2 Chat group call setup
MCVideo client 1, client 2, and client 3 are served by the home MCVideo service provider in figure 7.1.2.3.1.2.2-1.
Pre-conditions:
1. MCVideo user 2 and MCVideo user 3 have previously joined (affiliated) to the group call. MCVideo client 1, client 2, and client 3 are registered and all users (MCVideo user 1, user 2, and user 3) have been authenticated and authorized to use the MCVideo service.
2. MCVideo client 1, MCVideo client 2 and MCVideo client 3 may have activated functional alias(es) configured to be used during the group call communication. No call is currently in progress for the group.
3. The MCVideo server may have subscribed to the MCVideo functional alias controlling server within the MC system for functional alias activation/de-activation updates.
4. The MCVideo user on MCVideo client 1 may have bound a functional alias to the MCVideo group ID (3GPP TS 23.280 [6]).
Figure 7.1.2.3.1.2.2-1: MCVideo chat group call
1. MCVideo user 1 indicates to join the group communication for the group. This may include a transmit media request.
1a. MCVideo client 1 sends a group join request with the MCVideo group ID of the desired group. It contains the MCVideo user’s MCVideo ID and the MCVideo client media parameters. The MCVideo user at MCVideo client 1 may include a functional alias used within the MCVideo group join request. If there is a request for media transmission, then the group join request contains an indication of an implicit transmit media request.
1b. The MCVideo server receives the group join request. MCVideo server generates an implicit affiliation (if the MCVideo user is not already affiliated to the group) and verifies that MCVideo user 1 is authorized to affiliate to the group by following the affiliation procedure for MCVideo. If a functional alias is present, the MCVideo server checks whether it is allowed to be used and if it has been activated for the user.
If the functional alias is provided only in the group join request, or via binding, the MCVideo server proceeds with the value that is provided. If the functional alias is provided in both the group join request and via binding, it is up to the MCVideo server implementation to determine a value for the functional alias to be used.
1c. The MCVideo server replies with a group join response indicating the acceptance of the group join request and also returns the MCVideo server selected media parameters for the group call in the group join response.
2. If MCVideo user 1 requests to transmit media by sending transmit media request to MCVideo server, the MCVideo server establishes the media plane (if not already established) for the call.
3. Transmission control will continue to be used by the transmission control participants associated with MCVideo client 1, MCVideo client 2 and MCVideo client 3 for the duration of the call. .If present, the functional alias of MCVideo client 1, MCVideo client 2 and MCVideo client 3 are displayed where appropriate.
7.1.2.3.1.2.3 Release chat group call
The procedure describes the case where the MCVideo server releases an ongoing MCVideo group call for all the participants of that group call, since at least one of the conditions for release are met e.g. due to chat duration expiry, last participant leaving or initiator leaving.
NOTE 1: The procedure for an MCVideo user leaving the group call is a different procedure.
Procedures in figure 7.1.2.3.1.2.3-1 are the procedures for the MCVideo server initiating the release of an ongoing MCVideo group call.
The following precondition applies:
– A group call is ongoing between MCVideo clients 1, 2 and 3
Figure 7.1.2.3.1.2.3-1: Release chat group call
1. MCVideo server would like to release the MCVideo group call which is ongoing e.g., due to chat duration expiry, last participant leaving, or initiator leaving.
2. MCVideo server identifies the participants of the ongoing group call and generates group call release request to release the ongoing session.
3. MCVideo server sends a group call release request towards each participant of the ongoing group call.
NOTE 2: The group call release request can also be sent over SIP signalling on the signalling plane.
4. MCVideo users are notified about the release of the group call.
5. Optionally the MCVideo client(s) receiving group call release request, may send a group call release response to the MCVideo server.
NOTE 3: The MCVideo client can send group call release response when the group call release request is sent using a unicast bearer.
6. MCVideo client 1, client 2 and client 3 release the transmission control and media plane resources associated with the group call that is released. Successful release of the group call does not affect the status of affiliation of any of the clients.
7.1.2.3.1.2.4 void
7.1.2.3.1.2.5 Late entry chat group call, newly joined group member
Procedures in figure 7.1.2.3.1.2.5-1 are those for a group member entering an ongoing MCVideo group call, i.e. performing a late entry.
Pre-conditions:
1. MCVideo user 2 and MCVideo user 3 have previously joined to the group. MCVideo client 1, client 2, and client 3 are registered and all users (MCVideo user 1, user 2, and user 3) have been authenticated and authorized to use the MCVideo service.
2. MCVideo user 1 indicates to join the group communication for the group.
3. MCVideo users using MCVideo client 1 to MCVideo client n may have activated functional alias(es) configured to be used during the group call communication.
4 The MCVideo server may have subscribed to the MCVideo functional alias controlling server within the MC system for functional alias activation/de-activation updates.
5. The MCVideo user on MCVideo client 1 may have bound a functional alias to the MCVideo group ID (3GPP TS 23.280 [6]).
Figure 7.1.2.3.1.2.5-1: Late entry of a newly joined group member
1. MCVideo client 1 sends a group join request with the MCVideo group ID of the desired group. It contains the MCVideo user’s MCVideo ID and the MCVideo client media parameters. The MCVideo user at MCVideo client 1 may include a functional alias used within the MCVideo group join request. If there is a request to transmit, then the group join request contains an indication of an implicit transmit media request.
2. The MCVideo server receives the group join request. MCVideo server generates an implicit affiliation (if the MCVideo user is not already affiliated to the group) and verifies that MCVideo user 1 is authorized to affiliate to the group. If a functional alias is present, the MCVideo server checks whether it is allowed to be used and if it has been activated for the user.
If the functional alias is provided only in the group join request, or via binding, the MCVideo server proceeds with the value that is provided. If the functional alias is provided in both the group join request and via binding, it is up to the MCVideo server implementation to determine a value for the functional alias to be used.
3. The MCVideo server replies with a group join response indicating the acceptance of the group join request.
4. Media plane between MCVideo client 1 and MCVideo server is established using media plane control signalling.
5. MCVideo users at MCVideo client 2 and MCVideo client 3 may be notified about the MCVideo client 1 joining the group call, and the functional alias of MCVideo client 1 may be displayed.
6. The MCVideo server may send (6a) Media transmission notification to MCVideo client 1, indicating the current transmitter. Alternatively the MCVideo server may send (6b) Transmit media granted, (6b) Transmit media rejected or (6d) Queue position info.
7. Transmission control will continue to be used by the transmission control participants associated with MCVideo client 1, MCVideo client 2 and MCVideo client 3. If present, the functional alias of MCVideo client 1, MCVideo client 2 and MCVideo client 3 are displayed where appropriate.
7.1.2.3.1.2.6 Late entry chat group call, MCVideo client coming back from out of coverage
Procedures in figure 7.1.2.3.1.2.6-1 are those for an MCVideo client coming back from out of coverage during an ongoing MCVideo group call.
Pre-conditions:
1. MCVideo users using MCVideo client 1, MCVideo client 2 and MCVideo client 3 are in an ongoing group call when MCVideo client1 goes out of radio coverage.
2. MCVideo client1 returns from out of coverage while the group call is still ongoing.
3. MCVideo users using MCVideo client 1 to MCVideo client n may have activated functional alias(es) configured to be used during the group call communication.
4. The MCVideo server may have subscribed to the MCVideo functional alias controlling server within the MC system for functional alias activation/de-activation updates.
Figure 7.1.2.3.1.2.6-1: Late entry of an MCVideo client returning from out of coverage
1. MCVideo client 1 or MCVideo server detects that MCVideo client 1 has returned from out of coverage.
NOTE 1: How the MCVideo client or MCVideo server detects that the client has returned from out of coverage is out of scope of the present document.
2. Media plane between MCVideo client 1 and MCVideo server is re-established using media plane control signalling.
NOTE 2: Depending on how long MCVideo client 1 was out of coverage, this step can include signalling from MCVideo client 1 to rejoin the chat group.
3. The MCVideo server may send (3a) Media transmission notification to MCVideo client 1, indicating the current transmitter. Alternatively, the MCVideo server may send (3b) Transmit media granted, (3c) Transmit media rejected or (3d) Queue position info.
4. MCVideo users at MCVideo client 2 and MCVideo client 3 may be notified about the MCVideo client 1 returning to the group call, and the functional alias of MCVideo client 1 may be displayed.
5. Transmission control will continue to be used by the transmission control participants associated with MCVideo client 1, MCVideo client 2 and MCVideo client 3. If present, the functional alias of MCVideo client 1, MCVideo client 2 and MCVideo client 3 are displayed where appropriate.
7.1.2.3.2 Exiting group call due to de-affiliation
Procedures in figure 7.1.2.3.2-1 are the signalling control plane procedures for the MCVideo server requesting a newly de-affiliated member to leave an ongoing MCVideo group call.
Pre-conditions:
1. MCVideo group is previously defined on the group management server with MCVideo users affiliated to that group. All members of the group belong to the same MC system.
2. MCVideo users on MCVideo client 1 to MCVideo client n are on an ongoing call.
3. MCVideo client 1 has been de-affiliated from the MCVideo group.
Figure 7.1.2.3.2-1: Exiting MCVideo group call due to de-affiliation
1. MCVideo client 1 which has been de-affiliated is instructed to leave the ongoing group call.
2. MCVideo server sends a group call leave request to MCVideo client 1.
3. MCVideo user at MCVideo client 1 is notified about leaving the group call.
4. MCVideo client 1 sends the group call leave response and leaves the group call.
5. MCVideo client 1 is now removed from the ongoing group call and MCVideo users at MCVideo client 2 to MCVideo client n may be notified that MCVideo client 1 has left the group call.
7.1.2.3.3 MCVideo user leaving a group call
Procedures in figure 7.1.2.3.3-1 are the signalling control plane procedures for the MCVideo user leaving an ongoing MCVideo group call.
Pre-conditions:
1. MCVideo group is previously defined on the group management server with MCVideo users affiliated to that group. All members of the group belong to the same MC system.
2. MCVideo users on MCVideo client 1 to MCVideo client n are on an ongoing call.
3. MCVideo user 1 indicates to leave the group call
Figure 7.1.2.3.3-1: MCVideo user leaving a group call
1. MCVideo client 1 sends a group call leave request to the MCVideo server.
2. MCVideo server sends a group call leave response to MCVideo client 1.
3. Release of transmission control and media plane resources associated with the group call for MCVideo client 1.
NOTE 1: MCVideo server checks if group call termination conditions are met, e.g. last participant leaving, second last participant leaving, initiator leaving, minimum number of affiliated MCVideo group members are not present . If at least one of the group call termination conditions is met, the MCVideo server releases the group call for all participants (see subclauses 7.1.2.3.1.1.3 Release pre-arranged group call and 7.1.2.3.1.2.3 Release chat group call).
4. MCVideo users at MCVideo client 2 to MCVideo client n may be notified that the MCVideo user of client 1 has left the group call.
NOTE 2: The MCVideo server does not perform late entry for MCVideo users that have left the group call.
7.1.2.4 Broadcast group call
7.1.2.4.1 General
A broadcast group call is a special group call where the initiating MCVideo user expects no response from the other MCVideo users, i.e. no response from the recipients is required to start media transmission and the call ends when the media transmission is complete.
7.1.2.4.2 Common broadcast group call procedure
Only the call originator can transmit media during the broadcast group call and the broadcast group call is released when the transmission is complete.
Figure 7.1.2.4.2-1 illustrates the common procedure both for group-broadcast group call and user-broadcast group call.
Pre-condition:
1. MCVideo client 1 and MCVideo client 2 are members of a group-broadcast group/user-broadcast group.
Figure 7.1.2.4.2-1: Broadcast group call
1. MCVideo user at MCVideo client 1 initiates the broadcast group call setup procedure with the indication of broadcast group call. The signalling procedure is identical to the group call setup as described in subclause 7.1.2.3.1.1 with the inclusion of the parameter for broadcast group call indicator.
2. MCVideo client 1 starts to transmit media.
NOTE 1: Only the call originating MCVideo user is allowed to transmit media on broadcast group call.
NOTE 2: A broadcast group call transmitted on a user-broadcast group has priority over group calls involving users within the user hierarchy. A broadcast group call transmitted on a group-broadcast group has priority over group calls on its subordinate groups.
3. If the media transmission from call originating MCVideo user is complete, the broadcast group call is released.
7.1.2.5 Emergency and imminent peril procedures
7.1.2.5.1 MCVideo emergency group call
7.1.2.5.1.1 MCVideo emergency group call commencement
The procedure describes the case where an MCVideo client is initiating an MCVideo emergency group call with the affiliated MCVideo group members of that MCVideo group. An MCVideo client in the MCVideo emergency state gains elevated access privilege for all of the MCVideo user’s mission critical applications. Initiating an MCVideo emergency group call puts the MCVideo group into the in-progress emergency state. While in the in-progress emergency state, all MCVideo group calls in the MCVideo group are processed as MCVideo emergency group calls by the MCVideo server until the emergency state of the MCVideo group is cancelled.
Figure 7.1.2.5.1.1-1 shows the procedures for the MCVideo client initiating establishment of an MCVideo emergency group call with an MCVideo group i.e., MCVideo users on MCVideo client 1, MCVideo client 2 and MCVideo client 3 belong to the same MCVideo group which is defined on group management server.
NOTE 1: For simplicity, a single MCVideo server is shown in place of a user home MCVideo server and a group hosting MCVideo server.
Pre-conditions:
1. The MCVideo group is previously defined on the group management server with MCVideo client 2 and MCVideo client 3 affiliated to that MCVideo group.
2. All members of the MCVideo group belong to the same MC system.
3. The initiating MCVideo client 1 has been provisioned with an MCVideo group that has been designated via provisioning as the MCVideo emergency group.
4 MCVideo client 1, MCVideo client 2 and MCVideo client 3 may have an activated functional alias to be used during the emergency group communication.
5. The MCVideo server may have subscribed to the MCVideo functional alias controlling server within the MC system for functional alias activation/de-activation updates.
NOTE 2: Alternatively, the client could have been provisioned for emergency behaviour on the selected group.
Figure 7.1.2.5.1.1-1: MCVideo emergency group call
1. The user at the MCVideo client 1 initiates an MCVideo emergency group call. MCVideo client 1 sets its MCVideo emergency state. The MCVideo emergency state of MCVideo client 1 is retained until explicitly cancelled by the user of MCVideo client 1.
NOTE 3: While MCVideo client 1 is in the emergency state, all MCVideo group and private calls initiated by MCVideo client 1 are initiated as MCVideo emergency calls.
2. MCVideo client 1 sends an MCVideo emergency group call request towards the MCVideo server. The MCVideo user at MCVideo client 1 may include a functional alias used within the MCVideo emergency group call request. The request contains an indication of the MCVideo emergency. The MCVideo server records the identity of the MCVideo user that initiated the MCVideo emergency group call until the MCVideo emergency state of the group is cancelled. Once an MCVideo emergency call has been initiated, the MCVideo group is considered to be in an in-progress emergency state until the emergency state of the group cancelled. If configured to send an MCVideo emergency alert when initiating an MCVideo emergency group call, the request also contains an indication that an MCVideo emergency alert is to be initiated. The request may contain an indication of an implicit transmit media request.
NOTE 4: While the MCVideo group is in the in-progress emergency state, all MCVideo group calls within the group are processed as emergency group calls by the MCVideo server. MCVideo group members that are not in the emergency state do not indicate emergency in group call requests but can set the requested priority of all group call requests to high priority.
3. The MCVideo server implicitly affiliates MCVideo client 1 to the emergency group if the client is not already affiliated.
4. MCVideo server checks whether the provided functional alias is allowed to be used and has been activated for the MCVideo user, and whether the MCVideo user of MCVideo client 1 is authorized for initiation of MCVideo emergency calls on the indicated MCVideo group, and if authorized, it resolves the MCVideo group ID to determine the members of that MCVideo group and their affiliation status, based on the information from group management server.
5. The MCVideo server configures the priority of the underlying bearers for all participants in the MCVideo group.
NOTE 5: Successive calls during the MCVideo group’s in-progress emergency state will all receive the adjusted bearer priority.
6. MCVideo server sends the MCVideo emergency group call request towards the MCVideo clients of each of those affiliated MCVideo group members. The request contains an indication of the in-progress emergency. The request contains an indication of an MCVideo emergency alert if the request from the originator indicated MCVideo emergency alert.
7. MCVideo users are notified of the incoming MCVideo group call, and, if available, the functional alias of the initiating user is displayed.
8. The receiving MCVideo clients send the MCVideo emergency group call response to the MCVideo server to acknowledge the MCVideo emergency group call request. For a multicast call, these acknowledgements are not sent.
9. The MCVideo server sends the MCVideo emergency group call response to the MCVideo user 1 to inform the successful MCVideo emergency call establishment.
NOTE 6: Step 9 can occur at any time following step 5, and prior to step 10 depending on the conditions to proceed with the call.
MCVideo client 1, MCVideo client 2 and MCVideo client 3 have successfully established media plane for communication. MCVideo transmission control participant 1, transmission control participant 2 and transmission control participant 3 exchange transmission control information e.g., MCVideo client 1 receives the transmit media granted information over the established media plane, while the other MCVideo client’s receive media available notification with forced reception information. MCVideo client 1 indicates to the MCVideo user that the permission is granted to transmit media, while the other MCVideo clients in the MCVideo emergency group call will be receiving that media. MCVideo client 1 can override other clients in the call except those that are also in the MCVideo emergency state.
7.1.2.5.1.2 MCVideo group call upgraded to an MCVideo emergency group call
The procedure describes the case where an authorized MCVideo user is upgrading an MCVideo group call to an MCVideo emergency group call while the MCVideo group call is already in progress.
Procedures in figure 7.1.2.5.1.2-1 are the signalling control plane procedures for the MCVideo client upgrading an MCVideo group call on an MCVideo group to an MCVideo emergency group call.
NOTE 1: For simplicity, a single MCVideo server is shown in place of a user home MCVideo server and a group hosting MCVideo server.
Pre-conditions:
1. The MCVideo group is previously defined on the group management server with MCVideo client 2 and MCVideo client 3 affiliated to that MCVideo group.
2. All members of the MCVideo group belong to the same MC system.
3. An MCVideo group call is already in progress.
4. The initiating MCVideo client 1 has been configured to send an MCVideo emergency alert when upgrading an MCVideo emergency group call.
Figure 7.1.2.5.1.2-1: MCVideo group call upgraded to an MCVideo emergency group call
1. The MCVideo user at MCVideo client 1 initiates a group emergency. MCVideo client 1 sets its MCVideo emergency state. The MCVideo emergency state of MCVideo client 1 is retained until explicitly cancelled by the user of MCVideo client 1.
NOTE 2: While MCVideo client 1 is in the emergency state, all MCVideo group and private calls initiated by MCVideo client 1 are initiated as MCVideo emergency calls.
2. MCVideo client 1 requests the MCVideo server to upgrade the MCVideo group to an in-progress emergency state by sending an MCVideo emergency group call request. If configured to send an MCVideo alert when initiating an MCVideo emergency upgrade, the request also contains an indication that an MCVideo alert is to be initiated. The request may contain an indication of an implicit transmit media request.
NOTE 3: While the MCVideo group is in the in-progress emergency state, all MCVideo group calls within the group are processed as emergency group calls by the MCVideo server. MCVideo group members that are not in the emergency state do not indicate emergency in group call requests but can set the requested priority of all group call requests to high priority.
3. The MCVideo server adjusts the priority of the underlying bearer for all participants in the MCVideo group.
4. MCVideo server sends the MCVideo emergency group call request towards the MCVideo clients of each of those affiliated MCVideo group members. The request contains an indication of an MCVideo emergency alert if the request from the originator indicated MCVideo emergency alert.
5. MCVideo users are notified of the in-progress emergency state of the MCVideo group.
6. The receiving MCVideo clients send the MCVideo emergency group call response to the MCVideo server to acknowledge the MCVideo group emergency request. For a multicast call, these acknowledgements are not sent.
7. The MCVideo server sends the MCVideo emergency group call response to the MCVideo user 1 to confirm the upgrade request. If the MCVideo emergency request contained an implicit transmit media request, the OK message contains the result of the implicit transmit media request.
NOTE 4: Step 7 can occur at any time following step 3, and prior to step 8 depending on the conditions to proceed with the call.
MCVideo client 1, MCVideo client 2 and MCVideo client 3 continue with the MCVideo group call, which has been transformed into an MCVideo emergency group call. MCVideo client 1 can override other clients in the call except those that are also in the MCVideo emergency state.
7.1.2.5.1.3 MCVideo in-progress emergency group state cancel
NOTE 1: In Rel-14 and Rel-13 versions of this specification the title of this subclause is "MCVideo emergency group call cancel".
The procedure describes the case where an MCVideo client cancels an MCVideo group’s in-progress emergency state. The emergency state of the group may alternatively be cancelled by the emergency alert cancellation procedure specified in 3GPP TS 23.280 [16], subclause 10.10.1.2.2.2.
Procedures in figure 7.1.2.5.1.3-1 are the signalling control plane procedures for the MCVideo client cancelling an in-progress emergency of a group.
NOTE 2: For simplicity, a single MCVideo server is shown in place of a user home MCVideo server and a group hosting MCVideo server.
NOTE 3: The end of the MCVideo emergency group call does not cancel the MCVideo group’s in-progress emergency state. It is explicitly cancelled by an authorized user using this procedure, or by the emergency alert cancellation procedure specified in 3GPP TS 23.280 [5], subclause 10.10.1.2.2.2.
Pre-conditions:
1. The MCVideo group is previously defined on the group management server with MCVideo client 2 and MCVideo client 3 affiliated to that MCVideo group.
2. All members of the MCVideo group belong to the same MC system.
3. MCVideo group members have been notified about the in-progress emergency.
4. The MCVideo group is in the in-progress emergency state and has prioritized bearer support.
5. MCVideo client 1 previously initiated the in-progress emergency for the group.
Figure 7.1.2.5.1.3-1: MCVideo in-progress emergency group state cancel
1. The user at the MCVideo client 1 initiates an MCVideo in-progress emergency group state cancel.
NOTE 4: An MCVideo user authorized to cancel in-progress emergencies on the MCVideo group can also be authorised to cancel the MCVideo emergency alert in addition to the initiator. However, only the initiator can cancel the initiator’s local MCVideo emergency state.
2. MCVideo client 1 sends an MCVideo in-progress emergency group state cancel request to the MCVideo server.
NOTE 5: If an MCVideo emergency alert relating to MCVideo client 1 is in effect together with an MCVideo in-progress emergency group state on the MCVideo group, the MCVideo emergency alert of MCVideo client 1 can be cancelled at the same time. In that case, the MCVideo in-progress emergency group state request carries an indication that the emergency alert of MCVideo client 1 is also being cancelled.
NOTE 6: If an MCVideo in-progress emergency group state cancel request is received by the MCVideo server while a group member that is in the emergency state is transmitting, the MCVideo in-progress emergency group state cancel request is rejected by the MCVideo server.
3. MCVideo server resolves the MCVideo group ID to determine the members of that MCVideo group and their affiliation status, based upon the information from group management server.
4. The MCVideo server adjusts the priority of the underlying bearer; priority treatment is no longer required. The MCVideo server cancels/resets the emergency in-progress state of the MCVideo group.
5. The MCVideo server sends an MCVideo in-progress emergency group state cancel request to the MCVideo group members.
6. MCVideo group members are notified of the MCVideo in-progress emergency group state cancel.
7. The receiving MCVideo clients send the MCVideo in-progress emergency group state cancel response to the MCVideo server to acknowledge the MCVideo in-progress emergency group state cancel. For a multicast call scenario, these acknowledgements are not sent.
8. The MCVideo server sends the MCVideo in-progress emergency group state cancel response to the MCVideo user 1 to confirm the MCVideo in-progress emergency group state cancel. If the MCVideo in-progress emergency group state cancel request (in step 2) contained the "Alert indicator" IE, the MCVideo client 1 resets its local emergency status.
NOTE 7: Step 8 can occur at any time following step 4, depending on the conditions to proceed with the call.
7.1.2.5.2 MCVideo imminent peril group call
7.1.2.5.2.1 MCVideo imminent peril group call commencement
The procedure focuses on the case where an authorized MCVideo user is initiating an imminent peril group call for communicating with the affiliated MCVideo members of that MCVideo group. This procedure will gain elevated access privilege for the MCVideo client if it is not already in that state. The access privilege for other applications will not necessarily be affected.
Procedures in figure 7.1.2.5.2.1-1 are the signalling control plane procedures for the MCVideo client initiating establishment of an imminent peril group call with an MCVideo group i.e., MCVideo users on MCVideo client 1, MCVideo client 2 and MCVideo client 3 belong to the same MCVideo group which is defined on MCVideo group management server.
Pre-conditions:
1. The MCVideo group is previously defined on the group management server with MCVideo client 2 and MCVideo client 3 affiliated to that MCVideo group.
2. All members of the MCVideo group belong to the same MC system.
3. The initiating MCVideo client 1 has been provisioned with an MCVideo group that has been designated in the provisioning to be used for imminent peril communications.
4. MCVideo client 1, MCVideo client 2 and MCVideo client 3 may have an activated functional alias to be used during the emergency group communication.
5. The MCVideo server may have subscribed to the MCVideo functional alias controlling server within the MC system for functional alias activation/de-activation updates.
NOTE 1: Alternatively, the client could have been provisioned for imminent peril behaviour on the selected group.
Figure 7.1.2.5.2.1-1: MCVideo imminent peril group call
1. The user at the MCVideo client 1 initiates an imminent peril group call.
2. MCVideo client 1 sends an MCVideo imminent peril group call request towards the MCVideo server. The MCVideo user at MCVideo client 1 may include a functional alias used within the MCVideo imminent peril group call request. The request contains an indication of the in-progress imminent peril. The MCVideo server records the identity of the MCVideo user that initiated the imminent peril group call until the in-progress imminent peril state is cancelled. Once an imminent peril group call has been initiated, the MCVideo group is considered to be in an in-progress imminent peril state until cancelled. The request may contain an indication of an implicit transmit media request.
3. The MCVideo server implicitly affiliates MCVideo client 1 to the imminent peril group if the client is not already affiliated.
4. MCVideo server checks whether the provided functional alias is allowed to be used and has been activated for the MCVideo user, and whether the MCVideo user of MCVideo client 1 is authorized for initiation of imminent peril group calls on the indicated MCVideo group, and if authorized, it resolves the MCVideo group ID to determine the members of that MCVideo group and their affiliation status, based on the information from group management server.
5. The MCVideo server configures the priority of the underlying bearers for all participants in the MCVideo group.
NOTE 2: Successive calls during the in-progress imminent peril state will all receive the adjusted bearer priority.
6. MCVideo server sends the imminent peril group call request towards the MCVideo clients of each of those affiliated MCVideo group members. The request contains an indication of the in-progress imminent peril.
7. MCVideo users are notified of the incoming imminent peril call, and, if available, the functional alias of the initiating user is displayed.
8. The receiving MCVideo clients send the MCVideo imminent peril group call response to the MCVideo server to acknowledge the imminent peril call request. For a multicast call, these acknowledgements are not set.
9. The MCVideo server sends the MCVideo imminent peril group call response to the MCVideo user 1 to inform the successful imminent peril call establishment. If the MCVideo imminent peril request contained an implicit transmit media request, the OK message contains the result of the implicit transmit media request.
NOTE 3: Step 9 can occur at any time following step 5, and prior to step 10 depending on the conditions to proceed with the imminent peril call.
MCVideo client 1, MCVideo client 2 and MCVideo client 3 have successfully established media plane for communication. MCVideo transmission control participant 1, transmission control participant 2 and transmission control participant 3 exchange transmission control information e.g., MCVideo client 1 receives the transmit media granted information over the established media plane, while the other MCVideo clients receive media available notification with forced reception mode information. MCVideo client 1 indicates to the MCVideo user that the permission is granted to transmit media, while the other MCVideo clients in the imminent peril call will be receiving that media.
7.1.2.5.2.2 Imminent peril group call upgrade
The procedure focuses on the case where an authorized MCVideo user is upgrading an MCVideo group call to an imminent peril group call while the MCVideo group call is already in progress.
Procedures in figure 7.1.2.5.2.2-1 are the signalling control plane procedures for the MCVideo client upgrading an MCVideo group call on an MCVideo group to an imminent peril group call.
Pre-conditions:
1. The MCVideo group is previously defined on the group management server with MCVideo client 1, MCVideo client 2 and MCVideo client 3 affiliated to that MCVideo group.
2. All members of the MCVideo group belong to the same MC system.
3. An MCVideo group call is already in progress.
Figure 7.1.2.5.2.2-1: MCVideo group call upgrade to an imminent peril group call
1. The MCVideo user at MCVideo client 1 initiates an imminent peril call.
2. MCVideo client 1 requests the MCVideo server to upgrade the MCVideo group to an in-progress imminent peril state by sending an MCVideo imminent peril group call request. The request may contain an indication of an implicit transmit media request.
3. The MCVideo server adjusts the priority of the underlying bearer for all participants in the MCVideo group.
4. MCVideo server sends the MCVideo imminent peril group call request towards the MCVideo clients of each of those affiliated MCVideo group members.
5. MCVideo users are notified of the in-progress imminent peril state of the MCVideo group.
6. The receiving MCVideo clients send the MCVideo imminent peril group call response to the MCVideo server to acknowledge the MCVideo imminent peril group call request. For a multicast call, these acknowledgements are not set.
7. The MCVideo server sends the MCVideo imminent peril group call response to the MCVideo user 1 to confirm the upgrade request. If the MCVideo imminent peril group call request contained an implicit transmit media request, the OK message contains the result of the implicit transmit media request.
NOTE: Step 7 can occur at any time following step 4, and prior to step 8 depending on the conditions to proceed with the call.
MCVideo client 1, MCVideo client 2 and MCVideo client 3 continue with the MCVideo group call, which has been transformed into an imminent peril group call.
7.1.2.5.2.3 MCVideo imminent peril group call cancel
The procedure focuses on the case where an authorized MCVideo user cancels an MCVideo group’s in-progress imminent peril state.
Procedures in figure 7.1.2.5.2.3-1 are the signalling control plane procedures for the MCVideo client cancelling an MCVideo group’s in-progress imminent peril state.
NOTE 1: The end of the imminent peril call does not cancel the MCVideo group’s in-progress imminent peril state. It is explicitly cancelled by an authorized user.
Pre-conditions:
1. The MCVideo group is previously defined on the group management server with MCVideo client 1, MCVideo client 2 and MCVideo client 3 affiliated to that MCVideo group.
2. All members of the MCVideo group belong to the same MC system.
3. The MCVideo group is an in-progress imminent peril state and has prioritized bearer support.
4. MCVideo group members have been notified about the MCVideo group’s in-progress imminent peril state.
5. MCVideo client 1 previously initiated the in-progress imminent peril.
Figure 7.1.2.5.2.3-1: MCVideo imminent peril group call cancel
1. The user at the MCVideo client 1 initiates an imminent peril cancel.
2. MCVideo client 1 sends an MCVideo imminent peril group call cancel request to the MCVideo server.
3. The MCVideo server adjusts the priority of the underlying bearer; priority treatment is no longer required. The MCVideo server cancels/resets the in-progress imminent peril state.
4. MCVideo server resolves the MCVideo group ID to determine the members of that MCVideo group and their affiliation status, based upon the information from group management server.
5. The MCVideo server sends an MCVideo imminent peril group call cancel request to the MCVideo group members.
6. MCVideo group members are notified of the in-progress imminent peril cancel.
7. The receiving MCVideo group members send the MCVideo imminent peril group call cancel response to the MCVideo server to acknowledge the in-progress MCVideo imminent peril group call cancel request. For a multicast scenario, these acknowledgements are not set.
8. The MCVideo server sends the MCVideo imminent peril group call cancel response to the MCVideo user 1 to confirm the MCVideo imminent peril group call cancel request.
NOTE 2: Step 8 can occur at any time following step 4, depending on the conditions to proceed with the call.
7.1.2.6 MCVideo emergency alert (on-network and off-network)
The MCVideo server shall support the procedures and related information flows as specified in subclauses 10.10 of 3GPP TS 23.280 [6] with the following clarifications:
– The MC service ID is the MCVideo ID;
– The MC service server is the MCVideo server;
– The MC service group ID is the MCVideo group ID and
– The MC service user profile index is the MCVideo user profile index.