Content for TS 23.379 Word version: 19.4.0
1…
7…
10…
10.5…
10.6…
10.6.2.3…
10.6.2.4…
10.6.2.5…
10.6.2.6…
10.6.2.9…
10.6.3…
10.7…
10.7.3…
10.7.5…
10.7.6…
10.9…
10.9.1.3.3…
10.9.1.4…
10.9.2…
10.10…
10.12…
10.19…
10.19.3…
10.19.3.1.4…
10.19.3.2…
10.19.3.2.4…
10.19.3.2.6…
A…
10.9 Floor control
10.9.1 Floor control for on-network MCPTT service
10.9.1.1 General
10.9.1.2 Information flows for floor control for on-network
10.9.1.3 Floor control with a single floor control server
10.9.1.3.1 Floor request, floor granted and floor taken during an MCPTT session
10.9.1.3.1a Floor request, floor granted and multi-talker floor taken during an MCPTT session enhanced with multi-talker control
10.9.1.3.2 Floor override
...
...
10.9 Floor control p. 162
10.9.1 Floor control for on-network MCPTT service p. 162
10.9.1.1 General p. 162
The procedure is for providing a floor control to MCPTT UE in an on-network case and applies for both private call and group call. Floor control is performed by using floor control information flows between the floor participant and the floor control server. The procedures with a single floor control server are applicable to both, all participants are in a single MC system and when participants are in multiple MC systems. The floor control procedures with multiple floor control servers are only applicable when participants are in multiple MC systems.
10.9.1.2 Information flows for floor control for on-network p. 162
10.9.1.2.1 General p. 162
When the floor control server receives a floor request from the floor participant, it decides whether to give a grant or not based on, e.g., the session status (i.e., whether the grant is given to another user or not), user profile, priority. The result is informed to the requesting floor participant. When the floor participant receives a floor granted message, it can send voice media over the uplink bearer established beforehand. The floor revoked message can be used as part of override. The floor queue status request can be used to know current position in the queue for floor.
Some floor control information flows can also piggyback call control information flows to provide efficient call setup and clearing:
- Call setup request is optionally carried in floor request (uplink) or floor taken (downlink, can be broadcast); and
- Call release request is optionally carried in floor release (uplink) or floor idle (downlink, can be broadcast).
10.9.1.2.2 Floor request p. 163
Table 10.9.1.2.2-1 describes the information flow floor request, from the floor participant to the floor control server and from the floor control server to the floor control server, which is used to request the floor for media transfer. This information flow is sent in unicast to the floor control server.
| Information Element | Status | Description |
|---|---|---|
| MCPTT ID | M | Requester identity |
| Functional alias | O | Functional alias of the requester |
| Floor priority | M | Priority of the request |
| Source identifier | O | Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing |
| Location Information | O | Location information |
10.9.1.2.3 Floor granted p. 163
Table 10.9.1.2.3-1 describes the information flow floor granted, from the floor control server to the floor participant and from the floor control server to the floor control server or MC gateway server, which is used to indicate that a request for floor is granted and media transfer is possible. This information flow is sent in unicast (to the granted floor participant).
| Information Element | Status | Description |
|---|---|---|
| MCPTT ID | M | Granted party identity |
| Functional alias | O | Functional alias of the requester |
| Duration | M | The time for which the granted party is allowed to transmit |
| Source identifier | O | Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing |
| Acknowledgement required | O | Indicates if acknowledgement from the floor participant is required |
10.9.1.2.4 Floor rejected p. 163
Table 10.9.1.2.4-1 describes the information flow floor rejected, from the floor control server to the floor participant and from the floor control server to the floor control server or MC gateway server, which is used to indicate that a request for the floor is rejected. This information flow is sent in unicast (to the refused floor participant).
| Information Element | Status | Description |
|---|---|---|
| MCPTT ID (see NOTE) | O | Rejected party identity |
| Functional alias (see NOTE) | O | Functional alias of the requester |
| Source identifier | O | Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing |
| Rejection cause | O | Indicates the cause for floor rejection |
| Acknowledgement required | O | Indicates if acknowledgement from the floor participant is required |
|
NOTE:
MCPTT ID is present, and functional alias may be present, in messages between the floor control servers in different MCPTT systems, and between floor control server and MC gateway server.
|
||
10.9.1.2.5 Floor request cancel p. 164
Table 10.9.1.2.5-1 describes the information flow floor request cancel, from the floor participant to the floor control server, which is used to request cancelling the floor request from the floor request queue. This information flow is sent in unicast to the floor control server.
| Information Element | Status | Description |
|---|---|---|
| MCPTT ID | M | Identity for the requester |
| Functional alias | O | Functional alias for the requester |
| List of MCPTT IDs (see NOTE) | O | Target identity (identities) whose floor request is to be cancelled |
| Source identifier | O | Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing |
|
NOTE:
If this information element is not present all the entries in the floor request queue are cancelled.
|
||
10.9.1.2.6 Floor request cancel response p. 164
Table 10.9.1.2.6-1 describes the information flow floor request cancel response, from the floor control server to the floor control participant and from the floor control server to the floor control server or MC gateway server, which is used to indicate the response for the floor request cancellation. This information flow is sent in unicast.
| Information Element | Status | Description |
|---|---|---|
| MCPTT ID | M | Identity of party that initiated the cancellation request |
| Functional alias | O | Functional alias of the requester |
| Source identifier | O | Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing |
| Acknowledgement required | O | Indicates if acknowledgement from the floor participant is required |
10.9.1.2.7 Floor request cancel notify p. 164
Table 10.9.1.2.7-1 describes the information flow floor request cancel notify, from the floor control server to the floor control participant, which is used to indicate the floor request is cancelled by the administrator/floor control server. This information flow is sent in unicast or broadcast.
| Information Element | Status | Description |
|---|---|---|
| MCPTT ID | M | Identity of the administrator |
| Functional alias | O | Functional alias of the administrator |
| Source identifier | O | Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing |
| Acknowledgement required | O | Indicates if acknowledgement from the floor participant is required |
10.9.1.2.8 Floor idle p. 164
Table 10.9.1.2.8-1 describes the information flow floor idle, from the floor control server to the floor participant, which is used to indicate that a session is in idle status, i.e. the floor is not granted to any party. This information flows is sent in unicast or broadcast.
| Information Element | Status | Description |
|---|---|---|
| Source identifier | O | Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing |
| Acknowledgement required | O | Indicates if acknowledgement from the floor participant is required |
10.9.1.2.9 Floor release p. 165
Table 10.9.1.2.9-1 describes the information flow floor release, from the floor participant to the floor control server, which is used to indicate the media transfer is completed and floor is released. This information flow is sent in unicast to the floor control server.
| Information Element | Status | Description |
|---|---|---|
| MCPTT ID | M | Identity of party that initiated the cancellation request |
| Functional alias | O | Functional alias of the requester |
| Source identifier | O | Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing |
10.9.1.2.9a Multi-talker floor release |R15| p. 165
Table 10.9.1.2.9a-1 describes the information elements of floor release for multi-talker control, from the floor control server to the floor participants, which is used to indicate the media transfer is completed and floor is released. This information flow is sent in unicast from the floor control server.
| Information Element | Status | Description |
|---|---|---|
| MCPTT ID (see NOTE) | M | Identity of participant releasing the floor |
| List of functional aliases (see NOTE) | O | Functional alias(es) of participant releasing the floor |
| Source identifier | O | Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing |
|
NOTE:
One or more functional aliases may be associated with the MCPTT ID.
|
||
10.9.1.2.10 Floor taken p. 165
Table 10.9.1.2.10-1 describes the information flow floor taken, from the floor control server to the floor participant, which is used to indicate the floor is granted to another MCPTT user. This information flows is sent in unicast or broadcast.
| Information Element | Status | Description |
|---|---|---|
| MCPTT ID | M | Identity for the granted party |
| Functional alias | O | Functional alias for the granted party |
| Source identifier | O | Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing |
| Permission to request the floor | O | Indicates whether receiving parties are allowed to request the floor or not (e.g. broadcast call) |
| Acknowledgement required | O | Indicates if acknowledgement from the floor participant is required |
| Location Information | O | Location information |
10.9.1.2.10a Multi-talker floor taken |R15| p. 166
Table 10.9.1.2.10a-1 describes the information elements of floor taken for multi-talker control, from the floor control server to the floor participant, which is used to indicate when the floor is simultaneously granted to multiple MCPTT users. The multi-talker floor taken is sent in unicast or broadcast.
| Information Element | Status | Description |
|---|---|---|
| List of MCPTT IDs (see NOTE) | M | Identity (identities) of the granted participant(s) |
| List of functional aliases (see NOTE) | O | Functional alias(es) of the granted participant(s) |
| List of source identifiers (see NOTE) | O | Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing |
| Acknowledgement required | O | Indicates if acknowledgement from the floor participant is required |
|
NOTE:
One or more functional aliases and one source identifier may be associated with an MCPTT ID.
|
||
10.9.1.2.11 Floor revoked p. 166
Table 10.9.1.2.11-1 describes the information flow floor revoked, from the floor control server to the floor participant and from the floor control server to the floor control server or MC gateway server, which is used to indicate the floor is revoked from its current holder (the floor participant who was granted the floor). This information flows is sent in unicast (to the revoked floor participant).
| Information Element | Status | Description |
|---|---|---|
| MCPTT ID | M | Revoked party identity |
| Functional alias | O | Functional alias of the requester |
| Source identifier | O | Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing |
| Acknowledgement required | O | Indicates if acknowledgement from the floor participant is required |
10.9.1.2.12 Floor acknowledgement p. 166
Table 10.9.1.2.12-1 describes the information flow floor acknowledgement, from the floor participant to the floor control server, which is used to provide an acknowledgement if the acknowledgement is required in the received floor control message.
| Information Element | Status | Description |
|---|---|---|
| MCPTT ID | M | Identity of the sender |
| Functional alias | O | Functional alias of the sender |
10.9.1.2.13 Queue position request p. 166
Table 10.9.1.2.13-1 describes the information flow queue position request, from the floor participant to the floor control server and from the floor control server to the floor control server or MC gateway server, which is used to request the position in the floor request queue. The MCPTT server and the MCPTT client support queuing of the floor control requests shall support this information flow. This information flow is sent in unicast to the floor control server.
| Information Element | Status | Description |
|---|---|---|
| MCPTT ID | M | Identity of party whose floor position is requested |
| Functional alias | O | Functional alias of the requester |
| Source identifier | O | Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing |
10.9.1.2.14 Queue position info p. 167
Table 10.9.1.2.14-1 describes the information flow queue position info, from the floor control server to the floor participant and from the floor control server to the floor control server or MC gateway server, which is used to indicate the floor request is queued and the queue position to the floor requesting UE and optionally to the authorized user. The MCPTT server and the MCPTT client support queuing of the floor control requests shall support this information flow. This information flow is sent in unicast (to the queued floor participant and optionally to the authorized user).
| Information Element | Status | Description |
|---|---|---|
| MCPTT ID | M | Identity of party whose floor position is provided |
| Functional alias | O | Functional alias of the requester |
| Queue position info | M | Position of the queued floor request in the queue |
| Source identifier | O | Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing |
| Acknowledgement required | O | Indicates if acknowledgement from the floor participant is required |
10.9.1.2.15 Unicast media stop request |R15| p. 167
Table 10.9.1.2.15-1 describes the information flow unicast media stop request from the floor participant to the floor control server, which is used by the floor participant to indicate that the unicast media flow of the designated communication does not need to be sent to the MCPTT client.
| Information Element | Status | Description |
|---|---|---|
| MCPTT ID | M | Identity of the requester |
| Functional alias | O | Functional alias for the requester |
| Source identifier | O | Identifies the communication whose media flow is to be stopped, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing |
10.9.1.2.16 Unicast media resume request |R15| p. 167
Table 10.9.1.2.16-1 describes the information flow unicast media resume request from the floor participant to the floor control server, which is used by the floor participant to request that the unicast media flow of the designated communication is to be sent to the MCPTT client.
| Information Element | Status | Description |
|---|---|---|
| MCPTT ID | M | Identity of the requester |
| Functional alias | O | Functional alias of the requester |
| Source identifier | O | Identifies the communication whose media flow is to be resumed, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing |
10.9.1.2.17 floor revoke request |R19| p. 168
Table 10.9.1.2.17-1 describes the information flow floor revoke request, from an authorized floor participant user to floor control server, which is used to revoke the floor from its current holder (the floor participant who was granted the floor).
| Information element | Status | Description |
|---|---|---|
| MCPTT ID | M | The identity of the user who requests to revoke the floor from another talker |
| MCPTT ID | M | Revoked party identity |
| Functional alias | O | Functional alias of the requester |
| Source identifier | O | Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing |
10.9.1.3 Floor control with a single floor control server p. 168
10.9.1.3.1 Floor request, floor granted and floor taken during an MCPTT session p. 168
Figure 10.9.1.3.1-1 shows the high level procedure that the floor control is conducted for the MCPTT session already established between the floor participant and the floor control server. Only three UEs involved in the session are shown for the simplicity.
Pre-condition:
- MCPTT session is established between MCPTT clients (client A, client B and client C) and MCPTT server.
- The user at MCPTT client C is an authorized user (e.g., dispatcher) allowed to remove a floor request of other MCPTT users from the floor queue and can receive notifications about another user when their floor request is queued, when their queued floor request is rejected and when their queued floor request is removed from the queue.
Step 1.
The floor control is established between the floor participants and floor control server. It is assumed that the floor is now in idle status.
Step 2.
Floor participant A wants to send voice media over the session.
Step 3.
Floor participant A sends a floor request message to floor control server which includes floor priority and other information as necessary.
Step 4.
Floor control server makes the determination on what action (grant, deny, or queue) to take on the request based on criteria (e.g., floor priority, participant type) and determines to accept the floor request from floor participant A. The floor control server may limit the time a user talks (hold the floor) as allowed by the configuration.
Step 5a.
Floor control server responds with a floor granted message to floor participant A including the maximum floor granted duration e.g., if no other floor participant has the permission for transmission.
Step 5b.
Floor control server sends a floor taken message to the other floor participant (floor participant B) including information about who is granted the floor.
Step 5c.
Floor participant A sends a floor acknowledgement if indicated to do so by the floor granted message.
Step 5d.
Floor participant B sends a floor acknowledgement if indicated to do so by the floor taken message.
Step 5e.
Floor control server sends a floor taken message to the other floor participant (floor participant C) including information about who is granted the floor.
Step 5f.
Floor participant C sends a floor acknowledgement if indicated to do so by the floor taken message.
Step 6a.
The floor granted shall cause the user of UE A where the floor participant A is located to be notified.
Step 6b.
The receipt of the floor taken may be used to inform the user of UE B where the floor participant B is located.
Step 6c.
The receipt of the floor taken may be used to inform the user of UE C where the floor participant C is located.
Step 7.
Floor participant A starts sending voice media over the session established beforehand.
Step 8.
Suppose there are one or more users requesting to talk at this time, the floor request(s) are queued as decided by floor control server e.g., based on floor priority.
Step 9.
Floor participant B sends a floor request message.
Step 10.
Floor control server queues the request of floor participant B.
Step 11a.
Floor control server sends queue position info to floor participant B.
Step 11b.
Floor participant B sends a floor acknowledgement if indicated to do so by the queue position info message.
Step 12.
Floor control server may send the queue position info to floor participant C who is an authorized user to indicate floor participant user B's floor request is queued.
Step 13.
Floor participant C sends a floor acknowledgement if indicated to do so by the queue position info message.
10.9.1.3.1a Floor request, floor granted and multi-talker floor taken during an MCPTT session enhanced with multi-talker control |R15| p. 170
Figure 10.9.1.3.1a-1 shows the high level procedure that allows several participants to talk simultaneously in a MCPTT session already established between the floor participant and the floor control server. Three UEs involved in the session are shown for simplicity.
Pre-conditions:
- The MCPTT group is configured to support multi-talker control and audio mixing by the network is applied.
- MCPTT session is established between MCPTT clients (client A, client B and client C) and MCPTT server.
- Participants and A and B have the permission to talk to all other participants and the floor is granted to floor participant B.
Step 1.
Floor participant B is talking and is sending the voice media.
Step 2.
Floor participant A wants to send voice media over the session.
Step 3.
Floor participant A sends a floor request message to the floor control server which includes the necessary information, e.g. floor priority.
Step 4.
Based on applicable criteria (e.g. floor priority, participant type, allowance to transmit, maximum number of simultaneous talkers) floor control server determines what action (grant, deny, or queue) shall be applied to the request. In this case, the floor request from floor participant A will be accepted. Simultaneous floor requests to transmit are handled in a sequential order. Based on the group configuration repository data, the floor control server may limit the time a floor participant is allowed to talk.
Step 5a.
Floor control server responds with a floor granted message to floor participant A.
Step 5b.
Floor control server sends a multi-talker floor taken message to floor participant B.
Step 5c.
Floor control server sends a multi-talker floor taken message to floor participant C.
Step 5d.
Floor control server may send a multi-talker floor taken message to floor participant A.
Step 6a.
The floor granted shall cause the user of UE A, where the floor participant A is located, to be notified.
Step 6b.
The multi-talker floor taken shall inform the user of UE B, that the floors are granted to other floor participants, but the floor is not revoked.
Step 6c.
The multi-talker floor taken shall inform the user of UE C floor participants list the floor are currently granted to.
Step 7.
Floor participant A starts sending voice media over the session established beforehand, i.e. participants A and B receive and transmit voice media; participant C only receives voice media.
10.9.1.3.2 Floor override p. 172
10.9.1.3.2.1 Floor override using floor revoked (also floor rejected) during an MCPTT session p. 172
Figure 10.9.1.3.2.1-1 shows the high level procedure that the floor control is conducted for the MCPTT session already established between the floor participant (with floor granted to floor participant B) and the floor control server (with an override based on priority). Only two UEs involved in the session are shown for the simplicity.
Step 1.
It is assumed that floor participant B has been given floor and is transmitting voice media.
Step 2.
Floor participant A having a priority which is relatively higher than that of floor participant B wants to send voice media over the session.
Step 3.
Floor participant A sends a floor request message to the floor control server.
Step 4.
The floor control server determines to accept the floor request from floor participant A based on arbitration result e.g., according to the priority information that is received in the floor request message. The floor control server sends a floor revoked message to floor participant B stopping the voice media transmission from floor participant B.
Step 5.
The user of floor participant B may be notified that the floor is revoked.
Step 6.
The Floor control server sends a floor granted message to floor participant A, while sending a floor taken message to floor participant B with information of who is granted the floor.
Step 7.
The user of floor participant A may be notified that he is granted the floor. Similarly, the user of floor participant B may be notified who is granted the floor.
Step 8.
Floor participant A starts sending voice media over the session established beforehand.
Step 9.
Now floor participant B may want the floor to start sending voice media.
Step 10.
Floor participant B sends a floor request message to floor control server which may include priority information.
Step 11.
Floor control server determines whether to accept the floor request from floor participant B based on arbitration result e.g., according to the priority information that is received in the floor request message.
Step 12.
The floor control server responds with a floor rejected message to floor participant B.
Step 13.
Floor participant B may be notified that he is rejected.
10.9.1.3.2.2 Floor override without using floor revoked during an MCPTT session p. 173
Figure 10.9.1.3.2.2-1 shows the high level procedure that the floor control is conducted for the MCPTT session already established between the floor participants (with floor granted to floor participant B) and the floor control server (with an override based on priority and configured to permit the transmission of the overridden floor participant B to continue). Only two UEs involved in the session are shown for the simplicity.
Pre-conditions
- The floor control server has been configured to support override.
- The override supported in this case permits both the overridden floor participant and the overriding floor participant to be transmitting.
Step 1.
It is assumed that floor participant B has been given the floor and is transmitting voice media.
Step 2.
Floor participant A having a floor priority which is relatively higher than that of floor participant B wants to send voice media over the session.
Step 3.
Floor participant A sends a floor request message to the floor control server.
Step 4.
The floor control server determines to accept the floor request from floor participant A based on arbitration result e.g., according to the floor priority information that is received in the floor request message.
Step 5a.
Floor control server responds with a floor granted message to floor participant A.
Step 5b.
Floor control server sends a floor taken message to the other floor participants (including floor participant B). Floor participant B continues transmitting the (overridden) voice media transmission.
Step 6a.
The floor granted causes the user of floor participant A to be notified.
Step 6b.
The user of floor participant B is notified of the status that the floor is now taken by floor participant A.
Step 7.
Floor participant A (overriding) starts sending voice media over the session established beforehand.
10.9.1.3.2.3 Floor override using floor revoked (also floor rejected) during an MCPTT session enhanced with multi-talker control p. 173
Figure 10.9.1.3.2.3-1 shows the high-level procedure that the floor control allows several participants to talk simultaneously in a MCPTT session already established between the floor participant (with floor granted to floor participant B) and the floor control server. Only two UEs involved in the session are shown for the simplicity.
Pre-conditions:
- The MCPTT group is configured to support multi-talker control.
- MCPTT session is established between MCPTT clients (client A, client B and client C) and MCPTT server.
- The maximum number of simultaneous talkers is set to 2.
- The floor priority of floor participant A is higher than of floor participant B.
- The floor is granted to floor participant B and floor participant C.
Step 1.
Floor participant B and floor participant C are sending voice media over the session established.
Step 2.
Floor participant A wants to send voice media over the session.
Step 3.
Floor participant A wants to talk (i.e. send voice media) over the session. Floor participant A sends a floor request message to the floor control server.
Step 4.
Based on an arbitration result (e.g. per the priority information that is received in the floor request message), the floor control server determines to accept the floor request from floor participant A. The maximum number of simultaneous talkers in the MCPTT group has been reached, the floor control server decides to apply the override mechanism.
Step 5.
The floor control server sends a floor revoked message to floor participant B stopping the voice media transmission of floor participant B.
Step 6.
The user of floor participant B may be notified that the floor is revoked.
Step 7.
The Floor control server sends a floor granted message to floor participant A, while sending a multi-talker floor taken message to floor participant B and floor participant C including the information to whom the floor has been granted.
Step 8.
The user of floor participant A may be notified that the floor has been granted to him. Similarly, the user of floor participant B and floor participant C may be notified to whom the floor has been granted.
Step 9.
Floor participant A starts sending voice media over the session established beforehand.
Step 10.
Now floor participant B may want the floor to start sending voice media.
Step 11.
Floor participant B sends a floor request message to floor control server that may include participant priority information.
Step 12.
Based on arbitration result, e.g. per the priority information that is received in the floor request message, and if the number of MCPTT Users has already reached the maximum number of simultaneous talkers in the group, the floor control server determines whether to accept or reject the floor request from floor participant B. Due to lower priority of participant B and the applicable limitation of simultaneous talkers, the floor control server rejects the floor request.
Step 13.
The floor control server responds with a floor rejected message to floor participant B.
Step 14.
Floor participant B may be notified about the floor rejection.
10.9.1.3.2.4 Floor release during an MCPTT session enhanced with multi-talker control p. 175
Figure 10.9.1.3.2.4-1 shows the high-level procedure where the floor controller allows a participant to release the floor while other participants continue to talk simultaneously in a MCPTT session already established between the floor participants and the floor control server. Only three UEs involved in the session are shown for simplicity.
Pre-conditions:
- The MCPTT group is configured to support multi-talker control and audio mixing by the network is applied.
- MCPTT session is established between MCPTT clients (client A, client B, and client C) and the MCPTT server.
- Participants A, B, and C have the permission to talk to all other participants, and the floor is granted to floor participants A, B, and C.
Step 1.
Floor participants A, B and C are sending voice media over the established session.
Step 2.
User A stops talking and wants to stop sending voice media over the session.
Step 3.
Floor participant A sends a floor release message to the floor control server.
Step 4.
The floor control server accepts the floor release from floor participant A and sends a multi-talker floor release message to floor participant B and floor participant C.
Step 4a.
The users of floor participant B and floor participant C may be notified that floor participant A has released the floor.
Step 5.
Floor participants B and C continue sending voice media over the established session.
