6.3.2 Controlling MCPTT function procedures at MCPTT call initialization

24.3803GPPMission Critical Push To Talk (MCPTT) media plane controlProtocol specificationRelease 18TS

6.3.2.1 General

The clause 6.3.2.2 describes the initial procedures when a new SIP session is establishing a group session or a private session with floor control.

The clause 6.3.2.3 describes the procedures when a non-controlling MCPTT function switches from the non-controlling mode to the controlling mode.

6.3.2.2 Initial procedures

When an MCPTT call is established a new instance of the floor control server state machine for ‘general floor control operation’ is created.

For each MCPTT client added to the MCPTT call, a new instance of the floor control server state machine for ‘basic floor control operation towards the floor participant’ is added.

If the optional "mc_queueing" feature is supported and has been negotiated as specified in clause 14, the floor control server could queue the implicit floor control request for the media-floor control entity.

The initial SIP INVITE request or SIP REFER request to establish an MCPTT chat group call or to rejoin an ongoing MCPTT call is not handled as an implicit floor control request message by the floor control server unless explicitly stated in the SIP INVITE request or in the SIP REFER request.

The permission to send media to the inviting MCPTT client due to implicit floor control request is applicable to both confirmed indication and unconfirmed indication.

When the first unconfirmed indication is received from the invited participating MCPTT function (see 3GPP TS 24.379 [2]) the floor control server optionally can give an early indication to send RTP media packets, to the inviting MCPTT client.

If an early indication to send RTP media packets is given to the inviting MCPTT client, the floor participant is granted the permission to send media and the MCPTT server buffers RTP media packets received from the MCPTT client at least until the first invited MCPTT client accepts the invitation or until the RTP media packet buffer maximum limit is exceeded.

If the MCPTT server does not support or does not allow media buffering then an early indication to send RTP media packets is not given to the inviting MCPTT client, the floor participant is granted the permission to send media when the first invited MCPTT client accepts the media.

Before the floor control server sends the first floor control message in the MCPTT call, the floor control server has to assign itself a SSRC identifier to be included in media floor control messages and quality feedback messages if the MCPTT server is supporting that option. A suitable algorithm to generate the SSRC identifier is described in IETF RFC 3550 [3].

The floor participant and the floor control server can negotiate the maximum priority level that the floor participant is permitted to request. The floor control server can pre-empt the current sender based on the negotiated maximum priority level that the floor participant is permitted to request and the priority level included in the Floor Request message.

NOTE: The maximum priority level that a floor participant can use is negotiated as specified in clause 14.3.3 and is based on group configuration data retrieved by the controlling MCPTT function from the group management server as described in 3GPP TS 24.481 [12] and service configuration data retrieved by the controlling MCPTT function from the configuration management server as described in 3GPP TS 24.484 [13].

For groups configured for audio cut-in floor control, pre-empting of the current sender is not according to priority. Each new floor request results in the floor being revoked from the current talker and being granted to the new requesting talker.

The floor participant and the floor control server can negotiate queueing of floor requests using the "mc_queueing" fmtp attribute as described in clause 14. If queueing is supported and negotiated, the floor control server queues the floor control request if a Floor Request message is received when another floor participant has the floor and the priority of the current speaker is the same or higher. Queueing is not permitted for groups configured for audio cut-in floor control.

6.3.2.3 Switching from a non-controlling MCPTT function mode to a controlling MCPTT function mode

When the MCPTT server switches from the non-controlling MCPTT function mode to controlling MCPTT function mode a new instance of the floor control server state machine for ‘general floor control operation’ is created.

For each MCPTT client in the MCPTT call a new instance of the floor control server state machine for ‘basic floor control operation towards the floor participant’ is added.

Any floor request in the passive floor request queue is moved to the active floor request queue.

NOTE: The passive floor request queue is a floor request queue used by the non-controlling MCPTT function as specified in clause 6.5.4 to monitor floor request sent by floor participants controlled by the non-controlling MCPTT function.