Content for  TS 23.333  Word version:  17.1.0

Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. It enables applications or users to gain safe and mutually exclusive or non-exclusive input access to the shared object or resource. The "Floor" is an individual temporary access or manipulation permission for a specific shared resource (or group of resources) RFC 4376. Floor control is an optional procedure; where "shall" is used it is meant that this is basic required functionality within the feature.

The functional architecture concerning Floor control is presented in Figure 5.14.2.1 below.

The functional entities are described by solid line, and the roles are described by broken line. The functional entities consist of the following:

• User Equipment (UE), a UE shall support the "Client" role of BFCP as specified by RFC 4582. the Client may be a "Floor Participant" or "Floor Chair" .
• Media Resource Function (MRF), an MRF shall support the "Floor Control Server" role.

The roles consist of the following:

• Floor Participant, the Floor Participant shall support general Client operations and Floor Participant operations as described in RFC 4582.
• Floor Chair, the Floor Chair shall support Client operations and Floor Chair operations as described in RFC 4582.
• Floor Control Server, the Floor Control Server (FCS) shall support Floor Control Server operations as described in RFC 4582.

The MRF shall support the Floor Control function, including: the "conference policy" related to Floor control and the communication between the Floor control functional entities (the Floor Participant, the Floor Chair and the Floor Control Server).

This clause covers the information flows between the UE and MRF.

A MRFC/MRFP may support Multimedia Telephony using Explicit Congestion Notification see RFC 3168, and may act as an ECN endpoint to enable ECN with a local ECN-capable terminal within a local network that properly handles ECN-marked packets. This requires that the MRFC performs the following:

• support SDP ability to negotiate ECN as described in TS 26.114.

This requires the MRFP to be capable of enabling end-to-end rate adaptation due to congestion between the local Multimedia Telephony terminal and the MRFP by performing the following towards the local Multimedia Telephony terminal:

• trigger rate adaptation request towards the Multimedia Telephony terminal when receiving incoming IMS media flow IP packets marked with ECN-CE;
• perform media adaptation (e.g. reduce media bit-rate) towards the Multimedia Telephony terminal when receiving from the latter an adaptation request;
• if requested by the MRFC, provide notification and an ECN failure event if ECN errors or packet losses occur.

The MRFC and the MRFP may support Interactive Connectivity Establishment defined in RFC 8445 and RFC 8839, and TS 24.229 for NAT traversal as required by TS 23.228. The present clause describes the requirements for MRFC and MRFP when the ICE procedures are supported. Support of full ICE functionality is optional, but if ICE is supported, the MRFC and MRFP shall at least support ICE lite as specified in RFC 8445. The MRFC and MRFP shall only use host candidates as local ICE candidates. If ICE is supported, the MRFC shall perform separate ICE negotiation and procedures independentantly on each call leg (e.g. with each conference participant). Furthermore, the MRFC may be configured to apply ICE procedures only towards the access network side. When the MRFC detects no ICE parameters in the received SDP, it shall not configure the MRFP to apply any ICE and STUN related procedures toward the call leg from where the SDP has been received. Any MRFC supporting ICE shall advertise its support of incoming STUN continuity check procedures. An MRFC supporting full ICE procedures shall in addition advertise its support for originating STUN connectivity check procedures. If the MRFP does not indicate the support of STUN procedures, or if the MRFC is configured not to apply ICE toward a call leg, the MRFC shall not configure the MRFP to apply STUN procedures.

If the MRFC is configured to use ICE lite, or supports only ICE lite, or controls an MRFP that only support ICE lite, the procedures in the present clause apply. If the MRFC receives an initial SDP offer with ICE candidate information but no "a=ice-lite" attribute, the MRFC:

• shall request the MRFP for each media line where it decides to use ICE to reserve an ICE host candidate and provide its address information and a related ICE user name fragment and password;
• shall configure the MRFP to act as STUN server at the host candidate address, i.e. to answer STUN connectivity checks;
• may provide received remote ICE candidates and the received related ICE user name fragment and password to the MRFP;
• if an "a=ice-options" attribute with the value "ice2" was present in the received SDP offer, shall include the "a=ice-options" attribute with the value "ice2" in the SDP answer;
• shall include the host candidate and related ICE user name fragment and password received from the MRFP in the SDP answer; and
• shall include the "a=ice-lite" attribute in the SDP answer.

If the MRFC receives SDP offer with ICE candidate information and an "a=ice-lite" attribute, the MRFC shall not apply ICE towards that call leg and not include any ICE related SDP attributes in the SDP answer. If the MRFC sends an SDP offer towards a call leg where ICE is to be applied, the MRFC:

• shall request the MRFP to reserve a host candidate for each media line where it decides to use ICE and provide its address information, user name fragment and password;
• shall configure the MRFP to act as STUN server at the host candidate address, i.e. to answer STUN connectivity checks;
• shall include the "a=ice-options" attribute with the value "ice2" in the SDP offer;
• shall include the host candidate provided by the MRFP and related ICE user name fragment and password in the SDP offer; and
• shall include the "a=ice-lite" attribute in the SDP offer.

If the MRFC then receives an SDP answer with candidate information from the call leg where ICE is to be applied, the MRFC may provide received remote ICE candidates and the received related ICE user name fragment and password to the MRFP. After the initial SDP offer-answer exchange, the MRFC can receive a new offer from the peer that includes updated address and port information in the SDP "c=" line, "m=" line, or "a=rtcp" line SDP attributes. If the ICE user name fragment and password in the SDP offer differ from the ones received in the previous SDP (i.e. the peer restarts ICE), the MRFC shall apply the same procedures as for the initial SDP offer. When receiving a request for a host candidate for a media line, the MRFP shall allocate one host candidate for that media line and send it to the MRFC within the reply. The IP address and port shall be the same as indicated separately as Local IP Resources. The MRFP shall also indicate that it supports ICE lite in the reply. When receiving a request for an ICE user name fragment and password, the MRFP shall generate an ICE user name fragment and password and send it to the MRFC within the reply. The MRFP shall store the password and user name fragment to be able to authenticate incoming STUN binding request according to Section 7.2 of RFC 8445. When receiving a request to act as STUN server, the MRFP shall be prepared to answer STUN binding request according to Section 7.2 of RFC 8445. Once a STUN binding request with the "USE-CANDIDATE" flag has been received, the MRFP may send media towards the source of the binding request.

If the MRFC supports and is configured to use full ICE, and controls an MRFP that supports full ICE, the procedures in the present clause apply. If the MRFC receives an initial SDP offer with ICE candidate information, the MRFC:

• shall request the MRFP for each media line where it decides to use ICE to reserve an ICE host candidate and provide its address information and a related ICE user name fragment and password;
• shall request the MRFP to provide the desired pacing value for connectivity checks (Ta timer value);
• shall configure the MRFP to act as STUN server at the host candidate address, i.e. to answer STUN connectivity checks;
• shall provide received remote ICE candidates and the received related ICE user name fragment and password to the MRFP;
• shall provide the remote pacing value to the MRFP as follows:
  1. if the "a=ice-pacing" attribute was present in the received SDP answer, the received pacing value; or
  2. otherwise the default pacing value of 50 ms;
• if an "a=ice-options" attribute with the value "ice2" was present in the received SDP offer, shall include the "a=ice-options" attribute with the value "ice2" in the SDP answer;
• shall include the "a=ice-pacing" attribute with the pacing value provided by the MRFP in the SDP answer;
• shall include the host candidate and related ICE user name fragment and password received from the MRFP in the SDP answer;
• shall determine the role of the MRFC in ICE (controlling or controlled) according to Section 6.1.1 of RFC 8445;
• shall configure the MRFP to perform connectivity checks in accordance with the determined ICE role;
• shall configure the MRFP to report connectivity check results; and
• shall configure the MRFP to report a new peer reflexive candidate if discovered during the connectivity check.

If the MRFC sends an SDP offer towards a call leg where ICE is to be applied, the MRFC:

• shall request the MRFP to reserve a host candidate for each media line were it decides to use ICE and provide its address information, ICE user name fragment and password;
• shall request the MRFP to provide the pacing value for connectivity checks;
• shall configure the MRFP to act as STUN server at the host candidate address, i.e. to answer STUN connectivity checks;
• shall include the "a=ice-options" attribute with the value "ice2" in the SDP offer;
• shall include the "a=ice-pacing" attribute with the pacing value provided by the MRFP in the SDP offer; and
• shall include the host candidate provided by the MRFP and related ICE user name fragment and password in the SDP offer.

If the MRFC then receives an SDP answer with candidate information from the call leg where ICE is to be applied, the MRFC:

• shall provide received remote ICE candidates and the received related ICE user name fragment and password to the MRFP;
• shall provide the remote pacing value to the MRFP as follows:
  1. if the "a=ice-pacing" attribute was present in the received SDP answer, the received pacing value; or
  2. otherwise the default pacing value of 50 ms;
• shall determine the role of the MRFC in ICE (controlling or controlled) according to Section 6.1.1 of RFC 8445;
• shall configure the MRFP to perform connectivity checks in accordance with the determined ICE role;
• shall configure the MRFP to report connectivity check results; and
• shall configure the MRFP to report a new peer reflexive candidate if discovered during the connectivity check.

When the MRFC is informed by the MRFP about new peer reflexive candidate(s) discovered by the connectivity checks, it shall configure the MRFP to perform additional connectivity checks for those candidates, When the MRFC is informed by the MRFP about successful candidate pairs determined by the connectivity checks, the MRFC shall send a new SDP offer to its peer with contents according to Section 4.4.1 of RFC 8839 if it has the controlling role and the highest-priority candidate pair differs from the default candidates in previous SDP. After the initial SDP offer-answer exchange, the MRFC can receive a new offer from the peer that includes updated address and port information in the SDP "c=" line, "m=" line, or "a=rtcp" line SDP attributes. If the ICE user name fragment and password in the SDP offer differ from the ones received in the previous SDP (i.e. the peer restarts ICE), the MRFC shall apply the same procedures as for the initial SDP offer. When receiving a request for a host candidate for a media line, the MRFP shall allocate one host candidate for that media line and send it to the MRFC within the reply. The IP address and port shall be the same as indicated separately as Local IP Resources. When receiving a request to provide a desired pacing value for connectivity checks (Ta timer value), the MRFP shall calculate Ta timer value based on the characteristics of the associated data or shall use the default value of 50 ms and provide it as desired Ta timer value. The MRFP shall compare the own desired Ta timer value with the Ta timer value provided by the MRFC and shall use the higher value for connectivity checks (as specified in RFC 8445). When receiving a request for an ICE user name fragment and password, the MRFP shall generate an ICE user name fragment and password and send it to the MRFC within the reply. The MRFP shall store the password and user name fragment to be able to authenticate incoming STUN binding request according to Section 7.3 of RFC 8445. When receiving a request to act as STUN server, the MRFP shall be prepared to answer STUN binding request according to Section 7.3 of RFC 8445. Once a STUN binding request with the "USE-CANDIDATE" flag has been received, the MRFP may send media towards the source of the binding request. When receiving a request to perform connectivity checks and to report connectivity check results, the IMS AGW:

• shall compute ICE candidate pairs according to Section 6.1.2 of RFC 8445;
• shall schedule checks for the ICE candidate pairs according to Section 6.1.4 of RFC 8445;
• shall send STUN connectivity checks for the scheduled checks according to Section 7.2 of RFC 8445;
• shall inform the MRFC about successful candidate pairs determined by the connectivity checks;
• shall inform the MRFC about new peer reflexive candidate(s) discovered by the connectivity checks; and
• should send media using the highest priority candidate pair for which connectivity checks have been completed.

The MRFC and the MRFP shall check the conformance of the selected candidate pair with the media address information in SDP.