S.7 BFCP

26.1143GPPIP Multimedia Subsystem (IMS)Media handling and interactionMultimedia telephonyRelease 18TS

S.7.1 General

BFCP with TCP transport according to [149][150] shall be supported. An MSMTSI client in terminal shall be capable of indicating to the user when it is granted a floor, when a floor request is rejected, and when a floor grant is revoked. The details of such indication are left for MSMTSI client implementation. If the MSMTSI client in terminal supports floor control of more than a single video, it shall be able to make such indications separately for each supported floor.

An MSMTSI client may support functionality for moderated BFCP floor handling, involving a floor chair.

An MSMTSI MRF should silently ignore and discard any received video that is currently under active floor control, but where another MSMTSI or MTSI client than the one sending such received stream currently owns the floor.

S.7.2 Floor controlled main video

An MSMTSI client shall support BFCP [147][149] to control the main video.

When BFCP is used to control the MSMTSI client main video, all MSMTSI clients are allowed to send video as long as no one owns that BFCP floor. Whenever any MSMTSI client owns the main video floor, only that MSMTSI client is allowed to send main video in the group video call, and the MSMTSI MRF forwards that video to all other participants. The MSMTSI MRF should continue to use any previously used video forwarding strategy towards the MSMTSI client in the terminal that owns the main video floor.

S.7.3 Floor controlled screenshare video

If screeenshare video is supported by an MSMTSI client, BFCP [147][149] to control the screenshare video shall also be supported.

If BFCP is not available to control the screenshare video, and considering that the MSMTSI client supports screenshare video as a separate video "m="-line, implicit screenshare floor control of that "m="-line shall be assumed. Such implicit floor control shall here be taken to mean that the MSMTSI client is allowed to start sending screenshare video at any point in time, whenever initiated by the user of the MSMTSI client. No explicit screenshare floor grant indication to the sending MSMTSI client is possible in this case. An MSMTSI client in the terminal using implicitly floor controlled screenshare video that begins receiving screenshare video after itself started sending, shall immediately stop sending screenshare video, since this shall be interpreted as the implicit screenshare floor grant being revoked.

S.7.4 Implicit floor control for audio

An MSMTSI client in terminal is allowed to receive more audio streams than it is capable of decoding concurrently at a given time. In such case, the MSMTSI client in terminal shall have means for choosing which streams to prioritize and which ones to ignore. This selection can be made based on which streams are not in DTX mode. Media streams may also be prioritized based on the active level or volume of the audio stream. However, this requires decoding of the media from each stream to determine the loudest stream. The prioritized streams may further be spatially mixed for rendering.

S.7.5 Floor control interworking with DTMF-capable MTSI clients

If MTSI clients participate in the group video call, not supporting BFCP for the main video but having successfully negotiated use of DTMF with the MSMTSI MRF according to Annex G, the MSMTSI MRF may act as a signalling gateway between DTMF and BFCP main video floor control. It is then assumed that the MSMTSI MRF is configured with a DTMF sequence that can be used to request and release that BFCP floor, and that this DTMF sequence is somehow communicated to the MTSI client, but the details of that are out of scope for this specification.

If such MTSI client uses the designated DTMF sequence to request the main video floor, it shall be treated in the MSMTSI MRF as equivalent to receiving a BFCP request for the main video floor.

Lacking other possibilities to indicate main video floor grant status back to such DTMF-requesting MTSI client, the MSMTSI MRF should send its main video back to it as long as it owns the main video floor.

When the MTSI client owning the main video floor uses the DTMF sequence to release the main video floor, it shall be treated in the MSMTSI MRF as equivalent to receiving a BFCP release for the main video floor.