5 Functional Requirements

23.3333GPPMultimedia Resource Function Controller (MRFC) - Multimedia Resource Function Processor (MRFP) Mp interface: Procedures descriptionsRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.1 General

All functions are optional. Within a given function some components and procedures might be optional to still support the function but some will be required. Normative text in the following clauses thus describes requirements for support within an optional feature where it is desired to differentiate between optional and mandatory parts of the feature.

5.2 Play Tone

The MRFC shall request the MRFP to send tones to one, one of several, multiple or all parties connected in a call/session with a given tone identifier for each specific tone.

The MRFC may request the tone to be played continuously until requested to be stopped.

The MRFC may include in the request the length of time that the tone shall be played; the duration may be provisioned.

The MRFC may then request a notification from the MRFP when the tone is completed.

The MRFC may request DTMF detection while playing a tone.

The MRFC may request that upon DTMF detection the MRFP stops playing a tone.

5.3 Play Announcement

The function of playing announcement is to play audio media streams to the subscriber. The function can be used in services such as audio announcements, mail box services, play back recorded audio etc.

The MRFC shall request the MRFP to play announcements to one, one of several, multiple or all parties connected in a call/session.

The announcement may be referenced by identifiers that may be pre-configured, or dynamically obtained from the same MRFP for example due to Audio Record.

The MRFC shall request sequences of predefined fixed announcements within one request to the MRFP.

The MRFC may request announcements to be played in a loop until it commands the MRFP to stop.

The MRFC may request the MRFP to play an announcement for a fixed number of times.

The MRFC may request DTMF detection while playing an announcement.

The MRFC may request the MRFP to stop playing an announcement when a DTMF digit is detected.

The MRFC may request the MRFP to add the following variants to the announcements:

– Date/Day/Month

– Time

– Digits (the announcement may contain a number of digits to be controlled by the MRFC for example a telephone number)

– Money (currency)

– Integer (a value within the announcement that is controlled by the MRFC, e.g. "you are caller number 3 in the queue")

– Variants may have predefined default values for a given network.

The MRFC may request the MRFP to indicate when a specific announcement previously requested has been played successfully.

The MRFP shall indicate error cases such as announcement not played successfully.

5.4 Text to Speech

TTS (Text To Speech) is the process of automatic generation of speech output from text or annotated text input.

The MRFC shall request the MRFP to play the text to one, one of several, multiple or all parties connected in a call/session.

The text format shall comply with the SSML format as specified in [11].

The MRFC shall extract the SSML script from the VXML or other format XML script if received

If the received text is another format than SSML, the MRFC shall generate a SSML script that may include the basic SSML text and the language type.

The MRFC shall indicate to the MRFP the text-to-speech, by sending the SSML script or sending an URI reference to this SSML script.

If the MRFC indicates the SSML script to the MRFP, the SSML text is sent inline in a H.248 command of Mp; the size shall be limited to avoid the segmentation in the Mp interface. The MRFC may remove unnecessary elements, such as the comments element, from the SSML document, providing that the result is a Conforming Speech Synthesis Markup Language Fragment as described in clause 2.2.1 of SSML ref [11]. This is however outside the scope of the current Mp specification work. If the SSML script size pre-processed results in segmentation in the Mp interface, the URI reference should be used.

When the MRFC indicates the SSML script using an URI reference to the MRFP, two options can exist:

– the file (referenced by the URI) is located in the MRFP and it is a SSML text, hence the MRFP should play the text;

– the file (referenced by the URI) is located outside the MRFP; the MRFP may fetch the text and play it to the user otherwise the MRFP indicates an error.

The MRFP shall execute the basic SSML elements and may ignore the SSML elements not supported. The basic SSML elements include the root element "speak", language type and spoken text.

The MRFC may request the MRFP to play a text in a loop until it commands the MRFP to stop.

The MRFC may request the MRFP to play a text for a fixed number of times.

The MRFC may request DTMF detection while playing a text.

The MRFC may request the MRFP to stop playing a text when a DTMF digit is detected.

The MRFC may request the MRFP to indicate when a text has been played successfully.

The MRFP shall indicate error cases such as text not played successfully. Ignoring a non-supported SSML element shall not result in an error.

5.5 Audio Record

The function requirement of audio record is to record the audio media stream(s) and store it into a file. The function can be used in some services, such as the voice mail box service, conference service, etc.

The MRFC shall request the MRFP to start the audio record from one or all parties connected in a call/session. If it is to record one party in a call/session, only the input stream of the party is recorded. If it is to record all parties in a call/session, the mixed stream of all parties is recorded.

The MRFP file format shall comply with the 3GPP multimedia file formats as specified in the 3GPP TS 26.244[5].

The MRFC may request the MRFP to detect the DTMF digit while recording an audio.

The MRFC may request the MRFP to stop recording and still retain the recording file.

The MRFC may indicate to the MRFP the file format and the URI to store the recorded file or request the MRFP to return the record file URI.

The MRFC may indicate to the MRFP the maximum record time.

The MRFC shall request the MRFP to indicate the result and the cause of record completion when an audio has been recorded successfully.

The MRFP shall indicate error cases such as audio not recorded successfully.

The MRFC may indicate the MRFP to execute other functions, such as playing an announcement, when the MRFP is recording audio.

5.6 DTMF Collection

The MRFC shall request the MRFP to detect and report the DTMF digits.

The MRFP shall report DTMF Digits detected as RTP Telephony Events (see IETF RFC 2833 [10]) if the Telephony Event for DTMF Payload Type has been assigned to that interface. The MRFP shall report only single DTMF Digits.

5.7 Automatic Speech Recognition

ASR (Automatic Speech Recognition) function is that the recognizer processes the user input voice and may match that input against a target data to produce a recognition result that represents the detected input. In the IMS, the MRFP acts as the recognizer that is under control of the MRFC and finish the function of recognition.

The MRFC shall request the MRFP to start the automatic speech recognition.

The MRFC shall extract the SRGS recognition grammar script or URI from the VXML script if received or other format XML script if received.

The grammar format shall comply with the SRGS format as specified in W3C Recommendation [12].

The MRFC shall indicate the SRGS script or the SRGS URI to the MRFP using H.248 packages. If the SRGS script is sent inline,. the size of the SRGS script shall be limited to avoid segmentation in the Mp interface.

The MRFC may indicate to the MRFP the recognition mode: Normal Recognition Mode or Hotword Recognition Mode.

– If the MRFC indicates the Normal Recognition Mode to the MRFP, the MRFP shall attempt to match all of the speech against a recognition grammar and returns a no-match status if the input fails to match or the method times out.

– If the MRFC indicates the Hot-word Recognition Mode to the MRFP, the MRFP shall look for a match against specific speech grammar and ignores speech that does not match. The recognition completes only for a successful match of the recognition grammar or if the subscriber cancels the request or if the recognition time elapses.

The MRFP shall execute the recognition against the SRGS grammar and may ignore SRGS elements which are not supported.

The MRFC may request DTMF detection while executing ASR.

The MRFC may request the MRFP to stop ASR when a DTMF digit is detected.

The MRFC may request the MRFP to indicate when a specific ASR has been completed successfully.

When ASR is completed successfully, the MRFP may notify the MRFC the recognition result.

The recognition result shall comply with a single recognition format (e.g. the EMMA format as specified in W3C Recommendation [13] or the NLSML format as specified in W3C Recommendation [15]).

NOTE: The mandatory recognition result format may be defined in Stage 3 specification 3GPP TS 29.333 [16].The MRFP may notify the MRFC multiple recognition results that are mutually exclusive. Each result may be structured by multiple parts in time sequence with the input time, may include the text token that the value will correspond to tokens as defined by the SRGS grammar, may include the interpretation of application specific markup, may include the confidence score that represents the recognition quality.

The MRFP shall indicate error cases such as ASR not executed successfully.

5.8 Play Multimedia

5.8.1 General Play Multimedia

The function of playing multimedia is to play any combination of audio, video and messaging media streams (except for audio only play which is specified according to clause 5.2 or clause 5.3 ) to the subscriber. When playing combination of audio and video media stream(s), the media stream(s) shall be synchronized. The function can be used in the services, such as multimedia announcement, multimedia mail box service, etc.

The MRFC shall request MRFP to play multimedia to one, one of several, multiple or all parties connected in a call/session.

The multimedia to be played may be referenced by pre-configured identifiers or by reference to a file (location).

The MRFC shall request sequences of predefined fixed multimedia announcements within one request to the MRFP.

The MRFP multimedia of synchronized audio and video file format shall comply with the 3GPP multimedia file formats as specified in the 3GPP TS 26.244[5].

The MRFP may transcode the input codec into the session codec, if the multimedia file provides a different audio or video codec with the session codec.

The MRFC may request MRFP to play multimedia of synchronized audio and video in a loop until it commands the MRFP to stop.

The MRFC may request the MRFP to play multimedia of synchronized audio and video for a fixed number of times.

The MRFC may request DTMF detection while playing multimedia of synchronized audio and video.

The MRFC may request the MRFP to stop playing multimedia when a DTMF digit is detected.

The MRFC may indicate to the MRFP the multimedia file identifier and file format.

The MRFC may request the MRFP to indicate when a specific multimedia previously requested has been played successfully.

The MRFC may be able to decouple the play audio and play video request to the MRFP via separate sources for each media.

The MRFP shall indicate error cases such as multimedia not played successfully.

5.8.2 Play Message

The function specified in clause 5.8.1 for "General Play Multimedia" shall be followed. This clause describes the additional requirements to play the messaging media stream.

To detect DTMF digits is not required for message media stream.

To play message in a loop or in a loop with a fixed number of times is not required.

The MRFP message file formats shall comply with the file formats used inside MMS (Multimedia Messaging Service) as specified in the 3GPP TS 26.140 [22] in the current version.

5.9 Multimedia Record

5.9.1 General Multimedia Record

The function of the multimedia record is to record the any combination of audio, video and messaging media stream(s) (except for audio only record which are specified according to clause 5.5). When recording combination of audio and video media stream(s), the media stream(s) shall be synchronized and be stored into a multimedia file. The multimedia record function can be used in the services, such as multimedia mail box service, multimedia conference, etc.

The MRFC shall request the MRFP to start the multimedia record to one or all parties connected in a call/session. If it is to record one party in a call/session, only the input stream of the party shall be recorded.

If it is to record all parties in a call/session, the mixed stream of all parties shall be recorded. The MRFC may request the MRFP to detect the digit while recording a multimedia of synchronized audio and video.

The MRFP multimedia of synchronized audio and video file format shall comply with the 3GPP multimedia file formats as specified in the 3GPP TS 26.244[5].

The MRFC may request the MRFP to detect DTMF digits while recording multimedia of synchronized audio and video.

The MRFC may request the MRFP to stop recording and still retain the recording file.

The MRFC may indicate to the MRFP the file format and URI to store the recorded file or request the MRFP to return the URI.

The MRFC may indicate to the MRFP the maximum record time.

The MRFC may request the MRFP to indicate the result and the cause of record completion when a multimedia has been recorded successfully.

The MRFP shall indicate error cases such as multimedia not recorded successfully.

The MRFC may indicate the MRFP to execute other functions, such as playing an announcement, when the MRFP is recording multimedia.

5.9.2 Message Record

The function specified in clause 5.9.1 for "General Multimedia Record" shall be followed. This clause describes the additional requirements to record the messaging media stream.

The function of the message record is to record the messaging media stream(s) and store into a message file. The message record function can be used in the services, message conference, etc.

To detect DTMF digits is not required for message media stream.

The message file formats shall comply with the file formats used inside MMS (Multimedia Messaging Service) as specified in the 3GPP TS 26.140[22] in current version.

5.10 Audio Conference

Audio conferences allow users participating in the conference to communicate with all other participants simultaneously.

The details for conferencing within the IP Multimedia Core Network subsystem (IMS) are specified in 3GPP TS 24.147 [4].

The conference mixer is located in the MRFP.

The MRFC shall request the MRFP to create resources for an audio conference.

The MRFC shall create resources for users to join an existing conference, and to release resources for users to leave an existing conference.

The MRFC may request the MRFP to collect DTMF (according to clause5.5), play tones (according to clause 5.1) or announcements (according to clause 5.2), or record the audio during the conference (according to 5.4).

The MRFP may support transcoding between different users.

5.11 Multimedia Conference

5.11.1 General Multimedia Conferencing

Multimedia conferences allow users participating in the conference to communicate with all other participants simultaneously using any combination of voice, video and messaging (except for audio only conferences which are specified according to clause 5.10).

The details for conferencing within the IP Multimedia Core Network subsystem (IMS) are specified in 3GPP TS 24.147 [4]. In addition, optional enhancements to support Multi-stream Multiparty Conferencing Media Handling are specified in 3GPP TS 26.114 [23] annex S.

The conference mixer is located in the MRFP.

The MRFC shall request the MRFP to create resources for a multimedia conference.

The MRFC shall create resources for users to join an existing conference, and to release resources for users to leave an existing conference.

The MRFC may indicate to the MRFP to collect the DTMF (according to clause 5.6), play multimedia (according to clause 5.8), or record the multimedia (according to clause 5.9) during the conference. It is not required to collect DTMF when creating messaging conference separately.

The MRFP may support audio transcoding between different users.

The MRFP may support video transcoding between different users.

The MRFC may indicate to the MRFP to modify the media attribute, including:

– To create a video stream or close a video stream.

– To create an audio stream or close an audio stream.

– To create a messaging stream or close a messaging stream.

– To modify the codec of audio or video.

5.11.2 Message Conferencing

Messaging conferences allow users participating in the conference to communicate with all other participants simultaneously using session based message. Message content shall be possible to carry different media including text, image, video and audio.

The details for messaging conference within the IP Multimedia Core Network subsystem (IMS) are specified in 3GPP TS 24.247 [17].

The MRFC shall request the MRFP to create resources for a messaging conference.

The MRFC shall request the MRFP to create resources for users to join an existing conference, and to release resources for users to leave an existing conference.

The MRFC may indicate the granted quotas and valid time to the MRFP. The granted quotas indicate the units specifying the number of messages or volume (size) of messages allowed to be received or sent by users. The valid time indicates the validity time of the granted service units.

The MRFP may report statistics information of messages according to the indication by the MRFC when the granted quota is reached or the valid time elapses even if the granted service units have not been consumed within the validity time. The statistics information of messages may include any of the following received or sent by users in the conference:

– number of messages sent

– number of messages received

– volume (size) of messages sent

– volume (size) of messages received.

The MRFC may request the MRFP to report the statistics information of messages sent and/or received at the end of the session or during the session.

The MRFP may report the statistics information at the end of the session or during the session as requested by the MRFC. The statistics information of messages may includeany of the following received or sent by users in the conference:

– number of messages sent

– number of messages received

– volume (size) of messages sent

– volume (size) of messages received

The MRFP shall utilize the Message Session Relay Protocol (MSRP) (see IETF RFC 4975 [18]) to transport messages carrying different media including text, images, video and audio. The Media types shall be MIME encoded.

The MRFC may request the MRFP to play messaging (according to clause 5.8) during the conference.

The MRFC may request the MRFP to support the message record (according to clause 5.9), including global storage of sessions and personal storage during the conference.

The MRFC may request the MRFP to filter the message of the recipient. If the filtering capabilities are supported:

– The MRFC shall request the MRFP to start/stop message filtering.

– The MRFC shall indicate the filtering criteria to the MRFP. The filtering criteria may include sender address, message size, message content type (e.g. video, audio), message content format (e.g. mpeg, jpeg) and message subject.

– The MRFC shall indicate the message treatments to the MRFP. The message treatments include block the delivery of the message content, store the message content and redirect the message to another address.

– The MRFP shall execute the message treatment when the criteria is reached.

5.11.3 Multi-stream Multiparty Conferencing Media Handling

5.11.3.1 Introduction

The MRFC and the MRFP may support the Multi-stream Multiparty Conferencing Media Handling (MMCMH) using "simulcast" and "RTP-level pause and resume" functionality as specified in 3GPP TS 26.114 [23] annex S.

Usage of simulcast RTP streams is negotiated via SDP offer/answer exchange through media level SDP attributes:

– simulcast stream description ("a=simulcast" attribute defined in IETF RFC 8853 [57]); and

– restriction identifier ("a=rid" attribute defined in IETF RFC 8851 [58]).

When using simulcast, the "a=rid" identification of simulcast formats shall be unique within a media clause ("m=" line). SDP simulcast negotiation decides which simulcast formats, if any, are sent between the conference participant and the MRFP.

Furthermore, the media level SDP attribute "a=content" (defined in IETF RFC 4796 [59]) is used to indicate content of RTP stream.

The main video SDP "m=" line is indicated by the "a=content:main" under that "m=" line. The screenshare video is indicated as a separate SDP video "m=" line, identified by "a=content:slides" under that "m=" line. The screenshare video "m=" line shall be listed after the main video "m=" line. The "thumbnail" video is defined as unidirectional video which can be offered under the main video "m=" line with a smaller resolution then a main video or as a separate "m=" line that is not the first video "m=" line in the SDP, and that is also not identified with any "a=content:main" or "a=content:slides".

NOTE: A typical use case for MMCMH is that each conference participant sends a main and a thumbnail video, and that receives one main video (depicting the current speaker) and thumbnail videos for all other or some of the conference participants. For the current speaker, the MRF typically passes the main video to everybody. For each other participant, the MRF typically passes a thumbnail video to all other participants.

The main audio SDP "m=" line shall be the first "m=" line in an SDP offer, to increase the probability that it is accepted by a non-MMCMH capable conference participant. Support for multiple, simultaneous audio streams is indicated in SDP as separate audio "m=" lines. The number of supported channels in multi-channel audio is indicated per audio stream through the SDP "m=" line <encoding parameters>, with the default being a single channel when <encoding parameters> is omitted. The additional audio "m=" lines shall be listed after the main audio "m=" line.

"RTP-level pause and resume" functionality shall be supported by conference participants supporting MMCMH feature. The following RTCP feedback "CCM PAUSE-RESUME" messages are defined in IETF RFC 7728 [62]:

– "PAUSE" message to request an RTP stream sender to pause an RTP stream;

– "RESUME" message to request an RTP stream sender to resume an RTP stream;

– "REFUSED" message to notify an RTP stream receiver that a pause or resume request is not accepted; and

– "PAUSED" message to inform an RTP stream receiver that an RTP stream is paused.

Usage of "RTP-level pause and resume" functionality is negotiated via SDP offer/answer exchange through an extension of RTCP feedback capability attribute "a=rtcp-fb" (defined in IETF RFC 4585 [60]) to include request for pause and resume, as specified in IETF RFC 7728 [62]. The use of the "RTP-level pause and resume" functionality can be restricted according to a "config" pause attribute (defined in IETF RFC 7728 [62]), including not using it at all if that is the SDP offer/answer negotiation outcome.

Floor Control function using BFCP (as specified in clause 5.14) to control main video and screenshare video shall be supported by conference participants supporting MMCMH feature.

Examples of media portions from possible SDP offers and SDP answers related to a multi-stream multiparty conference establishment using simulcast and RTP-level pause and resume signalling are given in 3GPP TS 26.114 [23] annex T.

If the MRFC and the MRFP support the MMCMH feature, the requirements and procedures in the following clauses apply.

5.11.3.2 General MMCMH requirements

The MRFC shall support separating simulcast formats through referencing separate RTP payload types for each simulcast format, i.e., using the "pt=" parameter on the "a=rid" line (IETF RFC 8851 [58]). The MRFC and the MRFP may support restrictions parameters defined in IETF RFC 8851 [58].

The MRFP:

– shall support sending at least two thumbnails;

– may support sending any number of additional thumbnails;

– shall support receiving at least one thumbnail-sized simulcast format of the main video;

– may support receiving also other simulcast formats;

– shall support the BFCP floor control server role as specified in clause 5.14;

– shall support the "RTP-level pause and resume" functionality corresponding to "config=2" (as defined in IETF RFC 7728 [62], i.e. sending of "PAUSE", "RESUME" and "PAUSED", and reception of "PAUSED" and "REFUSED" RTCP feedback "CCM PAUSE-RESUME" messages); and

– should support the full "RTP-level pause and resume" functionality corresponding to "config=1" (as defined in IETF RFC 7728 [62], i.e. sending and receiving of all RTCP feedback "CCM PAUSE-RESUME" messages).

5.11.3.3 Negotiation in "dial-in" scenario

If the MRFC receives an SDP offer containing:

– an "a=simulcast" attribute; and

– the corresponding "a=rid" lines with a "pt" parameter defining the simulcast stream identification,

under an "m=" line then, in accordance with local configuration and SDP simulcast negotiation results on other call legs, the MRFC shall:

NOTE 1: The local configuration and SDP simulcast negotiation results on other call legs is also used to determine the expected number of conference participants and the corresponding number of thumbnail video streams to be accepted.

– if the MRFC supports the "Compact Concurrent Codec Negotiation and Capabilities" function specified in 3GPP TS 26.114 [23], clause S.5.7 and received the session level "a=ccc_list" attribute (defined in 3GPP TS 26.114 [23], clause S.5.7.2) within the SDP offer, use the information from the received "a=ccc_list" attribute in addition to the local configuration and SDP simulcast negotiation results on other call leg when deciding which media stream configuration to select towards the conference participant and when requesting the MRFP to reserve resources towards this conference participant;

– select the payload types (codecs and codec configurations) that it accepts to use for the accepted "m=" lines;

– select simulcast formats i.e. the MRFC shall:

a) verify the "pt" parameter from the "a=rid" line against the list of payload types listed on the "m=" line:

1) if payload type is not listed on the "m=" line, remove the payload type from the set of values in the "pt" parameter; and

2) if no values are left in the "pt=" parameter after this processing, then remove the "a=rid" line;

b) if the "a=rid" line contains a restrictions parameter which the MRFC does not support and if the "direction" field is "recv", remove the "a=rid" line; and

NOTE 2: The MRFC does not need to understand every restriction parameter present in a "send" line. If a stream sender restricts the stream in a way that the receiver does not understand, this causes no issues with interoperability.

c) change the directionality of the selected simulcast formats i.e. for the selected "a=simulcast" and "a=rid" attributes "send" from the received SDP offer becomes "recv" and "recv" becomes "send" in the SDP answer;

– if the "thumbnail" video descriptions are included in the SDP offer, based on the MRFP capabilities accept all or some of the offered the "thumbnail" video "m=" lines and change the directionality of the accepted "thumbnail" video "m=" lines from "recvonly" to "sendonly";

– if a video "m=" line with the "a=content:slides" attribute is included in the SDP offer and if the MRFP supports the screenshare video, accept the screenshare video "m=" line;

– when requesting the MRFP to configure resources towards the conference participant, for the accepted "m=" lines:

a) if the participant is the first conference participant, request the MRFP to create a new context and include a "MMCMH policy" information element to indicate to the MRFP that interconnection of video media streams with different StreamIDs is allowed in the context used for MMCMH and that the MRFP shall mix media streams autonomously based on policies for MMCMH. Within the "MMCMH policy" information element the MRFC:

1) shall indicate with the value "MMCMH basic policy" that the MRFP shall not send media streams received on a termination towards that termination and that the MRFP shall forward a received media stream of a particular media type (i.e. audio, main video or screenshare video) only towards outgoing media streams of the same media type. The MRFP shall select the video streams to be sent to a conference participant from among the videos received from the other conference participants in such a way that from each other conference participant at most one main video is sent to this conference participant and at most one screenshare video stream is sent to this conference participant;

2) may indicate with the value "Voice activity detected video" that the MRFP shall detect voice activity on audio streams and that the MRFP shall forward the main video received from the active speaker (i.e. from the media sender from which an audio stream is received where voice activity is currently detected) to all other conference participant;

3) may indicate with the value "Voice activity detected audio" that the MRFP shall detect voice activity on audio streams;

4) may indicate with the value "Mix audio" that the MRFP shall mix all the received audio streams from all other conference participants in the context and send the resulting audio stream(s) to each conference participant;

5) may indicate with the value "BFCP audio" that if the MRFP receives BFCP messages, the MRFP shall select received audio streams to forward or mix based on these BFCP messages;

6) may indicate with the value "BFCP video" that if the MRFP receives BFCP messages, the MRFP shall select received video streams to forward or mix based on these BFCP messages; and

7) may indicate with the value "BFCP screenshare" that if the MRFP receives BFCP messages, the MRFP shall select received screenshare streams to forward or mix based on these BFCP messages;

NOTE 3: A single context is used to handle all media types for an MMCMH conference.

b) include all accepted media streams sent to or received from the conference participant into the same termination;

c) include selected payload types for each accepted the "m=" line;

d) include a "Simulcast desc" information element with the selected simulcast streams for the accepted "m=" line and request the MRFP to configure termination with a simulcast capability;

e) include a "Simulcast format" information element with the accepted "a=rid" lines for the accepted "m=" line;

f) if the "a=content" attribute was received in the SDP offer, include a "Stream content" information element to indicate content of stream;

g) if the "a=rtcp-fb" line(s) with a "CCM" parameter (as defined in IETF RFC 5104 [61]) and a "pause" CCM parameter (as defined in IETF RFC 7728 [62]) was received in the SDP offer:

1) include a "CCM pause-resume" information element to indicate to the MRFP which RTCP feedback "CCM PAUSE-RESUME" messages the MRFP may send to the conference participant;

2) if a "nowait" pause attribute was received in the SDP offer, shall include a "nowait" pause attribute in the "CCM pause-resume" information element to indicate to the MRFP that exchange of the RTCP feedback "CCM PAUSE-RESUME" messages will be point-to-point and no hold-off period will therefore be necessary when resuming paused streams;

3) include a "Autonomous request" information element to indicate that the MRFP is allowed to autonomously send RTCP feedback CCM PAUSE and RESUME messages; and

4) include a "Autonomous response" information element to indicate that the MRFP is allowed to autonomously send RTCP feedback CCM PAUSED and REFUSED messages; and

NOTE 4: The MRFP will not send the RTCP feedback CCM REFUSED message if the "CCM pause-resume" information element contains the "config=2" pause attribute.

h) if the BFCP media stream was included in the SDP offer, apply additional specific procedures for BFCP in clause 5.14.5;

– include the accepted simulcast streams in the SDP answer;

– include the "thumbnail" video "m=" lines in the SDP answer;

– include the screenshare video "m=" line in the SDP answer;

– if the "a=rtcp-fb" line with a "pause" CCM parameter was included in the SDP offer:

a) include the "a=rtcp-fb" line with a "pause" CCM parameter in the SDP answer;

b) if the "nowait" pause attribute was received in the SDP offer, include the "nowait" pause attribute in the SDP answer; and

c) if the MRFP does not support the full "RTP-level pause and resume" functionality corresponding to "config=1" include the "config" pause attribute in the SDP answer with the value set according to the MRFP capability ("config=2") and the SDP offer/answer rules specified in IETF RFC 7728 [62];

– if an offered BFCP media stream was accepted, include in the SDP answer:

a) an "a=floorctrl:s-only" attribute to indicate that the MRFP will act as a floor control server;

b) an "a=confid" attribute indicating the conference identity to be used by BFCP signalling;

c) an "a=userid" attribute indicating the user identity to be used by BFCP signalling;

d) "a=floorid" attribute line(s) containing the BFCP floor identity(ies) to be used to control acceped audio and/or video media streams;

e) "a=label" attribute line(s) indicating which of the accepted audio and/or video media streams will be BFCP controlled;

NOTE 5: The "a=floorctrl", "a=confid", "a=userid" and "a=floorid" attributes are defined in IETF RFC 4583 [21]. The "a=label" attribute is defined in IETF RFC 4574 [64].

f) an "a=connection:new" attribute to request a new TCP connection; and

g) an "a=setup" attribute to indicate which end point will act as a TCP client; and

NOTE 6: The "a= connection" and "a= setup" attributes are defined in IETF RFC 4145 [36].

NOTE 7: For the TCP support see clause 5.21.

– include in the SIP message containing the SDP answer an "isfocus" media feature tag, defined in IETF RFC 3840 [63].

If the MRFP supports the "Compact Concurrent Codec Negotiation and Capabilities" function specified in 3GPP TS 26.114 [23] and if the MRFC received the session level "a=ccc_list" attribute within the SDP offer, then when requesting the MRFP to configure resources towards the conference participant, the MRFC may provide to the MRFP a "Concurrent Codec Capabilities" information element to indicate the concurrent codec capabilities of the conference participant.

5.11.3.4 Negotiation in "dial-out" scenario

If the MRFC receives a trigger to add a new participant in the MMCMH conference, then in accordance with local configuration and SDP simulcast negotiation results on other call legs, the MRFC shall decide which media stream configuration to offer to a new conference participant. If the MRFC supports the "Compact Concurrent Codec Negotiation and Capabilities" function specified in 3GPP TS 26.114 [23], clause S.5.7 and received the "a=ccc_list" attribute (defined in 3GPP TS 26.114 [23], clause S.5.7.2) within the 200 (OK) final response to the OPTIONS request, the MRFC shall use the information from the received "a=ccc_list" attribute in addition to the local configuration and SDP simulcast negotiation results on other call legs when deciding which media stream configuration to offer to a new conference participant and when requesting the MRFP to reserve resources towards this conference participant. The MRFC:

– should offer an audio media stream as simulcasted media stream;

– should offer a main video media stream as simulcasted media stream;

– shall decide if a "screenshare" video media stream will be offered;

– shall decide the number of "thumbnail" video media streams that will be offered in a sending direction towards the conference participant;

– should offer a BFCP media stream to control the audio and the main video media streams, and, if a "screenshare" video media stream is offered, to control the "screenshare" video media stream and should assign separate floor identities for each of these streams;

– for each offered audio and video media stream, shall select the payload types (codecs and codec configurations);

– for each offered simulcasted media stream, shall select a simulcast configuration (the number of RTP media streams which will be offered in a sending and in a receiving direction towards the conference participant) i.e. shall create the "a=simulcast" attribute, and shall select the corresponding simulcast formats i.e. shall create the corresponding "a=rid" lines with the "pt" parameter defining the simulcast stream identification; and

– for each offered audio and video media stream, shall decide if the "RTP-level pause and resume" functionality corresponding to "config=1" or "config=2" (see figure 7 in IETF RFC 7728 [62]) will be offered.

The MRFC shall then, in accordance with the selected media stream configuration, request the MRFP to reserve resources towards the conference participant. The MRFC shall:

– if the participant is the first conference participant, request the MRFP to create a new context and include a "MMCMH policy" information element to indicate to the MRFP that interconnection of video media streams with different StreamIDs is allowed in the context used for MMCMH and that the MRFP shall mix RTP media streams autonomously based on the MMCMH policies. Within the "MMCMH policy" information element the MRFC:

a) shall indicate with the value "MMCMH basic policy" that the MRFP shall not send media streams received on a termination towards that termination and that the MRFP shall forward a received media stream of a particular media type (i.e. audio, main video or screenshare video) only towards outgoing media streams of the same media type. The MRFP shall select the video streams to be sent to a conference participant from among the videos received from the other conference participants in such a way that from each other conference participant at most one main video is sent to this conference participant and at most one screenshare video stream is sent to this conference participant;

b) may indicate with the value "Voice activity detected video" that the MRFP shall detect voice activity on audio streams and that the MRFP shall forward the main video received from the active speaker (i.e. from the media sender from which an audio stream is received where voice activity is currently detected) to all other conference participant;

c) may indicate with the value "Voice activity detected audio" that the MRFP shall detect voice activity on audio streams;

d) may indicate with the value "Mix audio" that the MRFP shall mix all the received audio streams from all other conference participants in the context and send the resulting audio stream(s) to each conference participant;

e) may indicate with the value "BFCP audio" that if the MRFP receives BFCP messages, the MRFP shall select received audio streams to forward or mix based on these BFCP messages;

f) may indicate with the value "BFCP video" that if the MRFP receives BFCP messages, the MRFP shall select received video streams to forward or mix based on these BFCP messages; and

g) may indicate with the value "BFCP screenshare" that if the MRFP receives BFCP messages, the MRFP shall select received screenshare streams to forward or mix based on these BFCP messages;

– include all offered media streams to that conference participant into the same termination;

– request the local IP address and the port for each offered audio and video media stream;

– include selected payload types for each offered audio and video media stream;

– include a "Stream content" information element with the value "main" for the main video media stream;

– if the "screenshare" video media stream is offered, include a "Stream content" information element with the value "slides";

– for each offered simulcast media stream:

a) include a "Simulcast desc" information element with the selected simulcast configuration (containing the "a=simulcast" attribute) and request the MRFP to configure the termination with the simulcast capability; and

b) include a "Simulcast format" information element with selected simulcast formats (the corresponding "a=rid" lines) to indicate to the MRFP the simulcast stream identification and which payload type to reserve for the particular simulcast format;

– for each audio and video media stream offered with the "RTP-level pause and resume" functionality:

a) include a "CCM pause-resume" information element to indicate to the MRFP which RTCP feedback "CCM PAUSE-RESUME" messages the MRFP may send to the end user;

b) include a "nowait" pause attribute in the "CCM pause-resume" information element to indicate to the MRFP that exchange of the RTCP feedback "CCM PAUSE-RESUME" messages will be point-to-point and no hold-off period will therefore be necessary when resuming paused streams;

c) include an "Autonomous request" information element to indicate that the MRFP is allowed to autonomously send RTCP feedback CCM PAUSE and RESUME messages; and

d) include an "Autonomous response" information element to indicate that the MRFP is allowed to autonomously send RTCP feedback CCM PAUSED and REFUSED messages; and

NOTE 1: The MRFP will not send the RTCP feedback CCM REFUSED message if the "CCM pause-resume" information element contains the "config=2" pause attribute.

– apply additional specific procedures for BFCP in clause 5.14.5.

Upon receipt of a confirmation from the MRFP about local IP address and port and reserved resources for each selected media stream, the MRFC shall include in the SIP request an "isfocus" media feature tag (defined in IETF RFC 3840 [63]), and the SDP offer with the selected audio, video and BFCP media streams. The MRFC shall include in the SDP offer:

– selected payload types for each offered audio and video media stream;

– an "a=content:main" attribute under the main video "m=" line;

– if the "screenshare" video media stream is offered, an "a=content: slides" attribute under the "screenshare" video "m=" line;

– for each offered simulcast media stream, an "a=simulcast" attribute and related "a=rid" attribute lines with a "pt" parameter defining the simulcast stream identification under the corresponding "m=" line;

– "a=label" attribute line(s) indicating which of the offered audio and/or video media streams will be BFCP controlled;

NOTE 2: The "a=label" attribute is defined in IETF RFC 4574 [64].

– for each offered "thumbnail" video media stream, an "a=sendonly" attribute under the corresponding "m=" line;

– for each offered audio and video media stream, an "a=rtcp-fb" line with a "pause" CCM parameter, a "nowait" pause attribute and a "config" pause attribute; and

NOTE 3: If the MRFP supports the full "RTP-level pause and resume" functionality, as defined in IETF RFC 7728 [62], the "config" pause attribute may be omitted.

– under BFCP over TCP "m=" line:

a) an "a=floorctrl:s-only" attribute to indicate that the MRFP will act as a floor control server;

b) an "a=confid" attribute indicating the conference identity to be used by BFCP signalling;

c) an "a=userid" attribute indicating the user identity to be used by BFCP signalling;

d) "a=floorid" attribute line(s) containing the BFCP floor identity(ies) to be used to control offered audio and/or video media streams;

NOTE 4: The "a=floorctrl", "a=confid", "a=userid" and "a=floorid" attributes are defined in IETF RFC 4583 [21].

e) an "a=connection:new" attribute to request a new TCP connection; and

f) an "a=setup" attribute to negotiate which end point will act as a TCP client;

NOTE 5: The "a= connection" and "a= setup" attributes are defined in IETF RFC 4145 [36].

NOTE 6: For the TCP support see clause 5.21. The MRFC and the MRFP may support IMS media plane security and then procedures from clause 5.20 will be also applied.

Upon receipt of the corresponding SDP answer, the MRFC shall request the MRFP to modify termination towards the conference participant accordingly. The MRFC shall provide to the MRFP:

– the remote IP address and the port for each accepted media stream;

– payload types for each accepted audio and video media stream;

– for each accepted simulcast media stream:

a) the "Simulcast desc" information element with the accepted simulcast configuration (containing the "a=simulcast" attribute); and

b) the "Simulcast format" information element with accepted simulcast formats (the corresponding "a=rid" lines); and

– if the "a=rtcp-fb" line(s) with a "CCM" parameter and a "pause" CCM parameter was included in the SDP answer for the accepted audio or video media stream:

a) the "CCM pause-resume" information element;

b) if a "nowait" pause attribute was included in the SDP answer, the "nowait" pause attribute in the "CCM pause-resume" information element;

c) the "Autonomous request" information element; and

d) the "Autonomous response" information element.

If the MRFP supports the "Compact Concurrent Codec Negotiation and Capabilities" function specified in 3GPP TS 26.114 [23] and if the MRFC received the "a=ccc_list" attribute from the conference participant then when requesting the MRFP to modify termination towards the conference participant, the MRFC may provide to the MRFP a "Concurrent Codec Capabilities" information element to indicate the concurrent codec capabilities of the conference participant.

5.11.3.5 MMCMH handling at MRFP

Upon reception of a request from the MRFC to configure resources towards the conference participant, the MRFP:

– shall assign the requested resources:

a) shall configure termination to handle simulcast RTP streams; and

b) shall start monitoring voice activity for audio media streams when instructed by the MRFC;

– if "Concurrent Codec Capabilities" information element was received from the MRFC, shall store the concurrent codec capabilities of the conference participant i.e. the maximum number of concurrent encoders and decoders the conference participant can operate and take these constraints into account when selecting the media streams to/from a conference participant;

– shall select the media source (among the received RTP streams) to be sent as one of the RTP streams, and then among the available simulcast streams the MRFP shall select for the most appropriate one to the sent to the particular conference participant, as specified in IETF RFC 8853 [57]; and

– based on the value of the received "CCM pause-resume" information element, may send the RTCP "CCM PAUSE" messages towards the conference participant following the rules specified in IETF RFC 7728 [62].

Upon reception of a request from the MRFC to create a context with an "MMCMH policies" capability, the MRFP shall create that context and shall configure it according to value(s) received within the "MMCMH policy" information element. The MRFP shall handle media streams placed into the context as follows:

– The MRFP shall not send media streams received from a conference participant towards that conference participant.

– The MRFP shall forward a received media stream of a particular media type (i.e. audio, video or screenshare) only towards outgoing media streams of the same media type.

NOTE: The stream ID of a received media stream does not determine on which outgoing media streams the media are to be forwarded.

– The MRFP should forward the received audio stream of the active speaker (i.e. the audio stream where voice activity is detected) to all other conference participants. If simulcasted audio streams are received from the active speaker, the MRFP should select for each other conference participant an audio encoding among the received audio simulcast formats that is supported at the termination towards that participant to avoid transcoding.

– Alternatively, the MRFP may mix all the received audio streams from all other conference participants in the context and send the resulting audio stream(s) to a conference participant. If two audio streams were reserved towards a conference participant, the MRFP may distribute the received audio stream from each other conference participant in a specific way to render a stereo impression.

– The MRFP shall select the video streams to be sent to a conference participant from among the videos received from the other conference participants in such a way that:

a) from each other conference participant at most one main video is sent to this conference participant; and

b) at most one screenshare video stream is sent to this conference participant.

If simulcasted video streams are received from a participant, the MRFP should select for each other conference participant a video encoding among the received video simulcast formats that is supported at the termination towards that participant to avoid transcoding.

– The MRFP should forward the main video received from the active speaker (i.e. from the media sender from which an audio stream is received where voice activity is currently detected) to all other conference participant. If several video streams are simulcasted from the active speaker, the MRFP should select for each other conference participant the simulcast format that matches the configured encoding and resolution of the main video stream towards that conference participant to avoid transcoding.

– The MRFP should forward the main video of the previous speaker (i.e. received from the media sender from which an audio stream was received where the most recent past voice activity has been detected) to the active speaker (i.e. towards the media receiver associated with the media sender from which an audio stream is received where voice activity is currently detected). If several video streams are simulcasted from the previous speaker, the MRFP should select the simulcast format that matches the configured encoding and resolution of the main video stream towards the active speaker to avoid transcoding.

– The MRFP should forward received thumbnail video streams from the most recent previous speaker(s) (i.e. from the media sender(s) from which audio stream(s) was/were received where the most recent past voice activities have been detected). If several video streams are simulcasted from a previous speaker, the MRFP should select for each other conference participant the simulcast format that matches the configured encoding and resolution of a thumbnail video stream towards that conference participant to avoid transcoding.

– In order to avoid a too frequent switching of video images, the MRFP should wait for a short period when detecting voice activity from a new source before switching the video image.

– If the MRFC receives RTCP feedback about increased packet loss from a media receiver, the MRFP should reduce the number of video streams sent towards that media receiver and select only video streams with lower resolution (e.g. thumbnail video streams); the MRFP should select video streams received from the most recent speaker(s) (i.e. from the media sender(s) from which audio stream(s) are received where the most recent voice activities are or have been detected).

– If BFCP is configured at the MRFP and the MRFP receives BFCP messages, the MRFP should select received streams to forward or mix based on these BFCP messages.

– If the MRFP does not pass a received media stream to any conference participant, based on any of the criteria above, and the "RTP-level pause resume" capability was configured for that media stream, the MRFP should signal to the sender of that media stream to pause sending that media stream in accordance with IETF RFC 7728 [62].

– If the MRFP has previously signalled to a sender to pause sending a media stream and decides to pass that media stream to some conference participant(s), based on any of the criteria above, the MRFP shall signal to the sender to resume sending that media stream in accordance with IETF RFC 7728 [62].

5.12 Audio Transcoding

5.12.1 General

The MRFP shall support audio transcoding between streams of two Terminations within the same context where the streams are encoded differently, in accordance with standard H.248.1 principles, see ITU-T H.248.1 [3]. As minimum requirement the MRFP shall support the default 3GPP audio codec AMR (narrowband), and optionally any other audio codecs as specified in 3GPP TS 26.114 [23].

5.12.2 Handling of common codec parameters

Table 5.12.2.1 describes the MRFC handling of codec related parameters applicable to multiple codecs when the MRFC sends an SDP offer.

Table 5.12.2.1: MRFC handling of common codec parameters when the MRFC acts as offerer.

Parameter	Handling of common codec parameter in sent SDP offer	Handling of common codec parameter in received SDP answer
ptime (NOTE)	The MRFC may add the parameter with a value according to configured preferences to the SDP offer.	If the ptime parameter is included in the received SDP answer, the MRFC shall supply the parameter to the MRFP for the termination towards the answerer in the remote descriptor.
maxptime (NOTE)	The MRFC may add the parameter with a value according to the MRFP capabilities to the SDP offer.	If the maxptime parameter is included in the received SDP answer, the MRFC shall supply the parameter to the MRFP for the termination towards the answerer in the remote descriptor.
NOTE: This SDP attribute is defined in IETF RFC 4566 [44]. It applies to all codecs offered in an SDP media line.

Table 5.12.2.2 describes the MRFC handling of codec related parameters applicable to multiple codecs when the MRFC receives an SDP offer.

Table 5.12.2.2: MRFC handling of common codec parameters when the MRFC acts as answerer.

Parameter	Handling of common codec parameter in received SDP offer	Handling of common codec parameter in sent SDP answer
ptime (NOTE)	If the ptime parameter is included in the received SDP offer, the MRFC shall supply the parameter to the MRFP for the termination towards the offerer in the remote descriptor.	The MRFC may add the ptime parameter with a value according to configured preferences to the SDP answer.
maxptime (NOTE)	If the maxptime parameter is included in the received SDP offer, the MRFC shall supply the parameter to the MRFP for the termination towards the offerer in the remote descriptor.	The MRFC may add the maxptime parameter with a value according to the MRFP capabilities to the SDP answer.
NOTE: This SDP attribute is defined in IETF RFC 4566 [44]. It applies to all codecs offered in an SDP media line.

The MRFP handling of codec related parameters applicable to multiple codecs shall follow table 5.13.2.2 in 3GPP TS 23.334 [41].

5.12.3 Handling of the EVS speech codec

The Enhanced Voice Services (EVS) speech codec is defined in 3GPP TS 26.441 [42]. Its RTP payload type is defined in 3GPP TS 26.445 [43], and procedures for its usage as IMS Multimedia Telephony speech codec are defined in 3GPP TS 26.114 [23].

The MRFC and the MRFP may support transcoding to and from the EVS speech codec. If they do so, the procedures in the present clause apply.

Table 5.12.3.1 describes the MRFC handling of EVS codec parameters when the MRFC sends an SDP offer for an EVS payload type, and that EVS payload type is selected in the SDP answer. In addition, rules for the parameter handling in 3GPP TS 26.445 [43] shall apply.

Table 5.12.3.1: MRFC handling of EVS related SDP parameters when the MRFC adds the EVS payload type to the SDP offer it sends out.

Parameter	Handling for EVS payload type added to an SDP offer	Handling if offered EVS payload type is accepted in the SDP answer
evs-mode-switch (NOTE 1)	If the MRFC expects that interworking between AMR-WB and EVS is required, it shall include the evs-mode-switch with value 1. Otherwise the MRFC shall not include the evs-mode-switch.	If the evs-mode-switch parameter is contained in the SDP answer, the MRFC shall forward this parameter to the MRFP for the termination towards the answerer in the remote descriptor.
hf-only (NOTE 1)	If the MRFC is configured to negotiate using only the header-full EVS RTP payload format, the MRFC shall include the hf-only parameter with a value 1.	If the hf-only parameter is contained in the SDP answer, the MRFC shall forward this parameter to the MRFP in the remote descriptor.
dtx (NOTE 1)	If the usage of DTX is not desired in the sending and receiving direction (e.g. due to DTX capabilities of expected codecs to transcode with), the MRFC shall include the dtx parameter with a value 0.	If the dtx parameter is contained in the SDP answer, the MRFC shall forward this parameter to the MRFP in the remote descriptor.
dtx-recv (NOTE 1)	If receiving DTX is not desired and the dtx parameter is not included, the MRFC shall include the dtx-recv parameter with a value 0. If both the dtx and dtx-recv parameters are included, those parameters shall have the same value; however, inclusion of the dtx-recv parameter is not required if the dtx parameter is included.	If the dtx-recv parameter is contained in the SDP answer, the MRFC shall forward this parameter to the MRFP in the remote descriptor.
br (NOTE 1)	If the MRFC desires the same bit rate range for the send and receive direction in EVS primary mode, and wants to restrict the bit rate range to match MRFP capabilities and possible configured policies, it shall supply the br parameter in the SDP offer it sends. Otherwise the MRFC shall not include this parameter in the SDP offer. If the MRFC also supplies the bw, bw-send or bw-recv parameter, the value of the br parameter shall be compatible with the values of those parameters.	If the br parameter is contained in the SDP answer, the MRFC shall forward this parameter to the MRFP in the remote descriptor.
br-send (NOTE 1)	If the MRFC desires a different bit rate (range) for the send and receive direction in EVS primary mode, and wants to restrict the bit rate range for the send direction to match MRFP capabilities and possible configured policies, it shall supply the br-send parameter in the SDP offer it sends. Otherwise the MRFC shall not include this parameter in the SDP offer. If the MRFC also supplies the bw or bw-send parameter, the value of the br-send parameter shall be compatible with the values of those parameters.	If the br-send parameter is contained in the SDP answer, the MRFC shall forward this parameter to the MRFP in the remote descriptor.
br-recv (NOTE 1)	If the MRFC desires a different bit rate (range) for the send and receive direction in EVS primary mode, and wants to restrict the bit rate range for the receive direction to match MRFP capabilities and possible configured policies, it shall supply the br-recv parameter in the SDP offer it sends. Otherwise the MRFC shall not include this parameter in the SDP offer. If the MRFC also supplies the bw or bw-recv parameter, the value of the br-recv parameter shall be compatible with the values of those parameters.	If the br-recv parameter is contained in the SDP answer, the MRFC shall forward this parameter to the MRFP in the remote descriptor.
bw (NOTE 1)	If the MRFC desires the same sampling bandwidth(s) for the send and receive direction in EVS primary mode, and wants to restrict the sampling bandwidths to match MRFP capabilities, sampling bandwidths of expected codecs EVS will be transcoded to, and possible configured policies, it shall supply the bw parameter in the SDP offer it sends. Otherwise the MRFC shall not include this parameter in the SDP offer.	If the bw parameter is contained in the SDP answer, the MRFC shall forward this parameter to the MRFP in the remote descriptor.
bw-send (NOTE 1)	If the MRFC desires different sampling bandwidths for the send and receive direction in EVS primary mode, and wants to restrict the sampling bandwidths in the send direction to match MRFP capabilities, sampling bandwidths of expected codecs EVS will be transcoded to and possible configured policies, it shall supply the bw-send parameter in the SDP offer it sends. Otherwise the MRFC shall not include this parameter in the SDP offer.	If the bw-send parameter is contained in the SDP answer, the MRFC shall forward this parameter to the MRFP in the remote descriptor.
bw-recv (NOTE 1)	If the MRFC desires different sampling bandwidths for the send and receive direction in EVS primary mode, and wants to restrict the sampling bandwidths in the receive direction to match MRFP capabilities, sampling bandwidths of expected codecs EVS will be transcoded to, and possible configured policies, it shall supply the bw-recv parameter in the SDP offer it sends. Otherwise the MRFC shall not include this parameter in the SDP offer.	If the bw-recv parameter is contained in the SDP answer, the MRFC shall forward this parameter to the MRFP in the remote descriptor.
cmr (NOTE 1)	If the MRFC desires to disable codec mode requests within the RTP payload of the EVS primary mode (due to the MRFP capabilities or policies), it shall include the cmr parameter with value -1 in the SDP offer it sends.	If the cmr parameter is contained in the SDP answer, the MRFC shall forward this parameter to the MRFP in the remote descriptor.
ch-aw-recv (NOTE 1)	The MRFC shall include the ch-aw-recv parameter in the SDP offer if it desires to control the channel-aware mode of EVS in the receive direction, e.g. to disable it with value -1. The MRFC shall consider the capabilities of the MRFP when it chooses an appropriate value.	If the ch-aw-recv parameter is contained in the SDP answer, the MRFC shall forward this parameter to the MRFP in the remote descriptor.
number of channels (NOTE 2)	The MRFC shall only include the "number of channels" parameter in the SDP offer if it desires to send or receive multiple channels. If the desired number of channels in the send and receive direction differs, the MRFC shall include the higher value. The MRFC should consider the number of channels of expected codecs EVS will be transcoded to.	If the "number of channels" parameter is contained in the SDP answer, the MRFC shall forward this parameter to the MRFP in the remote descriptor.
ch-send (NOTE 1)	The MRFC shall only include the ch-send parameter in the SDP offer if it desires to send multiple channels, with different numbers of channels in the send and receive direction. The MRFC should consider the number of channels of expected codecs EVS will be transcoded to.	If the ch-send parameter is contained in the SDP answer, the MRFC shall forward this parameter to the MRFP in the remote descriptor.
ch-recv (NOTE 1)	The MRFC shall only include the ch-recv parameter in the SDP offer if it desires to receive multiple channels, with different numbers of channels in the send and receive direction. The MRFC should consider the number of channels of expected codecs EVS will be transcoded to.	If the ch-recv parameter is contained in the SDP answer, the MRFC shall forward this parameter to the MRFP in the remote descriptor.
mode-set (NOTE 3)	The MRFC shall only include the mode-set parameter in the SDP offer if it desires to restrict the mode-set of AMR-WB IO mode. The MRFC should only restrict the mode-set if the expected codecs EVS will be interworked with is AMR-WB and has a restricted mode-set.	If the mode-set parameter is contained in the SDP answer, the MRFC shall forward this parameter to the MRFP in the remote descriptor.
mode-change-period (NOTE 3)	The MRFC shall only include the mode-change-period parameter with value 2 in the SDP offer if it desires to restrict the mode-change-period of received packets in AMR-WB IO mode. The MRFC should only restrict the mode-change-period if the expected codec EVS will be interworked with is AMR-WB and has such a restriction.	If the mode-change-period parameter is contained in the SDP answer, the MRFC shall forward this parameter to the MRFP in the remote descriptor.
mode-change-capability (NOTE 3)	The MRFC shall either include the mode-change-capability parameter with value 2 or omit the parameter in the SDP offer.	If the mode-change-capability parameter is contained in the SDP answer, the MRFC may forward this parameter to the MRFP in the remote descriptor.
mode-change-neighbor (NOTE 3)	The MRFC shall only include the mode-change-neighbor parameter in the SDP offer if it desires to restrict the mode-change within received packets of AMR-WB IO mode to neighboring modes. The MRFC should consider the mode-change-neighbor parameter of the expected codec EVS will be interworked with if this is AMR-WB.	If the mode-change-neighbor parameter is contained in the SDP answer, the MRFC shall forward this parameter to the MRFP in the remote descriptor.
max-red (NOTE 5)	The MRFC shall only include the max-red parameter in the SDP offer if it desires to restrict the maximum redundancy of received packets. MRFC shall consider the capabilities of the MRFP, and should consider a max-red parameter of the expected codec EVS will be interworked with if this is AMR-WB.	If the max-red parameter is contained in the SDP answer, the MRFC shall forward this parameter to the MRFP in the remote descriptor.
3gpp_mtsi_app_adapt (NOTE 4)	If the MRFP supports RTCP APP based adaptation messages defined in 3GPP TS 26.114 [23], and the MRFC has a policy to negotiate the usage of those messages, the MRFC shall include the 3gpp_mtsi_app_adapt SDP attribute indicating the supported APP messages in the SDP offer.	If the 3gpp_mtsi_app_adapt attribute is contained in the SDP answer, the MRFC shall forward this parameter to the MRFP in the remote descriptor.
NOTE 1: This MIME parameter of the EVS RTP payload type is defined in 3GPP TS 26.445 [43]. It is encapsulated within the SDP "a=fmtp" attribute defined IETF RFC 4566 [44]. NOTE 2: This number of channels are encoded as "encoding parameters" of the SDP "a=rtpmap" attribute defined in IETF RFC 4566 [44]. NOTE 3: This MIME parameter of the EVS RTP payload type relates to AMR-WB IO mode and is defined in IETF RFC 4867 [45]. It is encapsulated within the SDP "a=fmtp" attribute defined IETF RFC 4566 [44]. NOTE 4: This SDP attribute is defined in 3GPP TS 26.114 [23]. It applies to all codecs offered in an SDP media line. However, some values are specific to EVS. NOTE 5: This MIME parameter of the EVS RTP payload type is defined in IETF RFC 4867 [45]. It is encapsulated within the SDP "a=fmtp" attribute defined IETF RFC 4566 [44].

When receiving an SDP offer that contains an EVS codec payload type, the MRFC shall handle the EVS codec parameters as described in table 5.12.3.2. In addition, rules for the parameter handling in 3GPP TS 26.445 [43] shall apply.

Table 5.12.3.2: MRFC handling of EVS related SDP parameters when the MRFC receives the EVS payload type in an SDP offer.

Parameter	Handling of EVS payload type parameter received in the SDP offer	EVS payload type supplied in the SDP answer
evs-mode-switch (NOTE 1)	If the evs-mode-switch parameter is contained in the SDP offer and the MRFC select the EVS payload type, the MRFC shall forward this parameter to the MRFP for the termination towards the offerer in the remote descriptor.	If the evs-mode-switch parameter is contained in the SDP offer, the MRFC shall include the evs-mode-switch parameter with unmodified value in the SDP answer. Otherwise, if the MRFC decides to interwork between AMR-WB and EVS, it shall include the evs-mode-switch with value 1. Otherwise the MRFC shall not include the evs-mode-switch. If the MRFC supplies the evs-mode-switch in the SDP answer, it shall also supply it to the MRFP in the local descriptor for the termination towards the offerer with the same value.
hf-only (NOTE 1)	If the hf-only parameter is contained in the SDP offer and the MRFC select the EVS payload type, the MRFC shall forward this parameter to the MRFP for the termination towards the offerer in the remote descriptor.	If the hf-only parameter is contained in the SDP offer, the MRFC shall include the hf-only parameter with unmodified value in the SDP answer. Otherwise, the MRFC may include the hf-only parameter with a value matching negotiated values of possible other EVS call legs in the conference. If the MRFC supplies the hf-only parameter in the SDP answer, it shall also supply it to the MRFP in the local descriptor for the termination towards the offerer with the same value.
dtx (NOTE 1)	If the dtx parameter is contained in the SDP offer and the MRFC select the EVS payload type, the MRFC shall forward this parameter to the MRFP for the termination towards the offerer in the remote descriptor.	If the dtx parameter is contained in the SDP offer, the MRFC shall include the dtx parameter with unmodified value in the SDP answer. If the dtx parameter is not contained in the SDP offer and if a dtx-recv parameter is contained in the SDP offer, the MRFC may include the dtx parameter in the SDP answer, and the value of the dtx parameter shall then be identical to that of the dtx-recv parameter in the SDP offer (e.g, if that value matches negotiated values of possible other EVS call legs in the conference). If the dtx parameter is not contained in the SDP offer and if the dtx-recv parameter is not contained in the SDP offer the MRFC may include in the SDP answer the dtx parameter with a value matching negotiated values of possible other EVS call legs in the conference. If the MRFC supplies the dtx parameter in the SDP answer, it shall also supply it to the MRFP in the local descriptor for the termination towards the offerer with the same value.
dtx-recv (NOTE 1)	If the dtx-recv parameter is contained in the SDP offer and the MRFC select the EVS payload type, the MRFC shall forward this parameter to the MRFP for the termination towards the offerer in the remote descriptor.	If no dtx parameter is included in the SDP answer and if the reception of DTX is not desired, the MRFC shall include in the SDP answer the dtx-recv parameter with a value 0. If both the dtx and dtx-recv parameters are included, those parameters shall have the same value; however, inclusion of the dtx-recv parameter is not required if the dtx parameter is included. If the MRFC supplies the dtx-recv parameter in the SDP answer, it should also supply it to the MRFP in the local descriptor for the termination towards the offerer with the same value.
br (NOTE 1)	If the br parameter is contained in the SDP offer, the MRFC shall check if the MRFP supports the indicated bitrates, or a subset of them, in EVS primary mode in the send and receive direction. If the indicated bitrates, and even each subset of them, are not supported, the MRFC shall not select the EVS payload type. If the MRFC selects the EVS payload type, it shall forward this parameter to the MRFP for the termination towards the offerer in the remote descriptor.	If the br parameter is contained in the SDP offer, the MRFC shall select a bitrate value, which is either the received br value or a subset of it, based on MRFP capabilities, possible configured policies, and the negotiated br range of possible other EVS call legs in the conference, and shall include the br parameter with the selected value that is also supplied towards the MRFP in the SDP answer. Otherwise, if the MRFC desires the same bit rate range for the send and receive direction in EVS primary mode, and wants to restrict the bit rate range to match MRFP capabilities, possible configured policies, and the negotiated br range of possible other EVS call legs in the conference, the MRFC shall supply the br parameter in the SDP answer it sends. Otherwise the MRFC shall not include this parameter in the answer. If the MRFC also supplies the bw, bw-send or bw-recv parameter, the value of the br parameter shall be compatible with the values of those parameters. If the MRFC supplies the br parameter in the SDP answer, it shall also supply to the MRFP the br parameter in the local descriptor for the termination towards the offerer with the same value.
br-send (NOTE 1)	If the br-send parameter is contained in the SDP offer, the MRFC shall check if the MRFP supports the indicated bitrates, or a subset of them, in EVS primary mode in the receive direction. If the indicated bitrates, and even each subset of them, are not supported, the MRFC shall not select the EVS payload type. If the MRFC selects the EVS payload type, it shall forward this parameter to the MRFP for the termination towards the offerer in the remote descriptor.	If the br-recv parameter is contained in the SDP offer, the MRFC shall select a bitrate value, which is either the received br-recv value or a subset of it, based on MRFP capabilities possible configured policies, and the negotiated br range of possible other EVS call legs in the conference, and the MRFC shall include the br-send parameter with the selected value that is also supplied towards the MRFP in the SDP answer. Otherwise, if the MRFC desires a different bit rate (range) for the send and receive direction in EVS primary mode, and wants to restrict the bit rate range for the send direction to match MRFP capabilities and possible configured policies, it shall supply the br-send parameter in the SDP answer it sends. Otherwise the MRFC shall not include the br-send parameter in the SDP answer. If the MRFC also supplies the bw or bw-send parameter, the value of the br-send parameter shall be compatible with the values of those parameters. If the MRFC supplies the br-send parameter in the SDP answer, it shall also supply to the MRFP the br-send parameter in the local descriptor for the termination towards the offerer with the same value.
br-recv (NOTE 1)	If the br-recv parameter is contained in the SDP offer, the MRFC shall check if the MRFP supports the indicated bitrates, or a subset of them, in EVS primary mode in the send direction. If the indicated bitrates, and even each subset of them, are not supported, the MRFC shall not select the EVS payload type. If the MRFC selects the EVS payload type, it shall forward this parameter to the MRFP for the termination towards the offerer in the remote descriptor.	If the br-send parameter is contained in the SDP offer, the MRFC shall select a bitrate value, which is either the received br-send value or a subset of it, based on MRFP capabilities, possible configured policies, and the negotiated br range of possible other EVS call legs in the conference, and the MRFC shall include the br-recv parameter with the selected value that is also supplied towards the MRFP in the SDP answer. Otherwise, if the MRFC desires a different bit rate (range) for the send and receive direction in EVS primary mode, and wants to restrict the bit rate range for the receive direction to match MRFP capabilities and possible configured policies, it shall supply the br-recv parameter in the SDP answer it sends. Otherwise the MRFC shall not include the br-recv parameter in the SDP answer. If the MRFC also supplies the bw or bw-recv parameter, the value of the br-recv parameter shall be compatible with the values of those parameters. If the MRFC supplies the br-recv parameter in the SDP answer, it shall also supply to the MRFP the br-recv parameter in the local descriptor for the termination towards the offerer with the same value.
bw (NOTE 1)	If the bw parameter is contained in the SDP offer, the MRFC shall check if the MRFP supports the indicated sampling bandwidth(s), or a subset of them, in EVS primary mode in the send and receive direction. If the indicated sampling bandwidth(s), and even each subset of them, are not supported, the MRFC shall not select the EVS payload type. If the MRFC selects the EVS payload type, it shall forward this parameter to the MRFP for the termination towards the offerer in the remote descriptor.	If the bw parameter is contained in the SDP offer, the MRFC shall select a sampling bandwidth value, which is either the received bw value or a subset of it, based on MRFP capabilities, possible configured policies, and the negotiated bw range of possible other EVS call legs in the conference, and the MRFC shall include the bw parameter with the selected value that is also supplied towards the MRFP in the SDP answer. Otherwise, if the MRFC desires the same sampling bandwidth(s) for the send and receive direction in EVS primary mode, and wants to restrict the sampling bandwidth(s) to match MRFP capabilities, possible configured policies, and the negotiated bw range of possible other EVS call legs in the conference, the MRFC shall supply the bw parameter in the SDP answer it sends. Otherwise the MRFC shall not include this parameter in the SDP answer. If the MRFC also supplies the br, br-send or br-recv parameter, the value of the bw parameter shall be compatible with the values of those parameters. If the MRFC supplies the bw parameter in the SDP answer, it shall also supply to the MRFP the bw parameter in the local descriptor for the termination towards the offerer with the same value.
bw-send (NOTE 1)	If the bw-send parameter is contained in the SDP offer, the MRFC shall check if the MRFP supports the indicated sampling bandwidths, or a subset of them, in EVS primary mode in the receive direction. If the indicated sampling bandwidths, and even each subset of them, are not supported, the MRFC shall not select the EVS payload type. If the MRFC selects the EVS payload type, it shall forward this parameter to the MRFP for the termination towards the offerer in the remote descriptor.	If the bw-recv parameter is contained in the SDP offer, the MRFC shall select a sampling bandwidths value, which is either the received bw-recv value or a subset of it, based on MRFP capabilities, possible configured policies, and the negotiated bw range of possible other EVS call legs in the conference, and the MRFC shall include the bw-send parameter with the selected value in the SDP answer. Otherwise, if the MRFC desires a different sampling bandwidths for the send and receive direction in EVS primary mode, and wants to restrict the sampling bandwidths for the send direction to match MRFP capabilities, possible configured policies, and the negotiated bw range of possible other EVS call legs in the conference, the MRFC shall supply the bw-send parameter in the SDP answer it sends. Otherwise the MRFC shall not include the br-send parameter in the SDP answer. If the MRFC also supplies the bw or bw-send parameter, the value of the br-send parameter shall be compatible with the values of those parameters. If the MRFC supplies the bw-send parameter in the SDP answer, it shall also supply to the MRFP the bw-send parameter in the local descriptor for the termination towards the offerer with the same value.
bw-recv (NOTE 1)	If the br-recv parameter is contained in the SDP offer, the MRFC shall check if the MRFP supports the indicated sampling bandwidths, or a subset of them, in EVS primary mode in the send direction. If the indicated sampling bandwidths, and even each subset of them, are not supported, the MRFC shall not select the EVS payload type. If the MRFC selects the EVS payload type, it shall forward the bw-recv parameter to the MRFP for the termination towards the offerer in the remote descriptor.	If the bw-send parameter is contained in the SDP offer, the MRFC shall select a sampling bandwidths value, which is either the received bw-send value or a subset of it, based on MRFP capabilities, possible configured policies, and the negotiated bw range of possible other EVS call legs in the conference, and the MRFC shall include the bw-recv parameter with the selected value in the SDP answer. Otherwise, if the MRFC desires a different sampling bandwidths for the send and receive direction in EVS primary mode, and wants to restrict the sampling bandwidths for the receive direction to match MRFP capabilities, possible configured policies, and the negotiated bw range of possible other EVS call legs in the conference, the MRFC shall supply the bw-recv parameter in the SDP answer it sends. Otherwise the MRFC shall not include the bw-recv parameter in the SDP answer. If the MRFC also supplies the br or br-recv parameter, the value of the bw-recv parameter shall be compatible with the values of those parameters. If the MRFC supplies the bw-send parameter in the SDP answer, it shall also supply it to the MRFP in the local descriptor for the termination towards the offerer with the same value.
cmr (NOTE 1)	If the cmr parameter is contained in the SDP offer and the MRFC select the EVS payload type, the MRFC shall forward this parameter to the MRFP for the termination towards the offerer in the remote descriptor.	If the cmr parameter is contained in the SDP offer, the MRFC shall include the cmr parameter with unmodified value in the SDP answer. Otherwise, if the MRFP desires to disable codec mode requests within the RTP payload of the EVS primary mode (due to the MRFP capabilities, possible configured policies, and the negotiated CMR mode of possible other EVS call legs in the conference, it shall include the cmr parameter with value -1 in the SDP answer it sends. If the MRFC supplies the cmr parameter in the SDP answer, it shall also supply it to the MRFP in the local descriptor for the termination towards the offerer with the same value.
ch-aw-recv (NOTE 1)	If the ch-aw-recv parameter is contained in the SDP offer the MRFC shall check if the MRFP supports the indicated mode in the send direction. If the indicated mode is not supported, the MRFC shall not select the EVS payload type. If the MRFC selects the EVS payload type, the MRFC shall forward this parameter to the MRFP for the termination towards the offerer in the remote descriptor.	If the MRFC it desires to control the channel-aware mode of EVS in the receive direction, e.g. to disable it with value -1, it shall include the ch-aw-recv parameter in the SDP offer and shall also supply the ch-aw-recv parameter to the MRFP in the local descriptor for the termination towards the offerer with the same value. The MRFC shall consider the capabilities of the MRFP and the negotiated ch-aw-recv mode of possible other EVS call legs in the conference when it chooses an appropriate value.
number of channels (NOTE 2)	If the "number of channels" parameter is contained in the SDP offer the MRFC shall check if the MRFP supports the indicated number of channels. If the indicated number of channels is not supported, the MRFC shall not select the EVS payload type. If the MRFC selects the EVS payload type, the MRFC shall forward this parameter to the MRFP for the termination towards the offerer in the remote descriptor.	If the "number of channels" parameter is contained in the SDP offer, the MRFC shall include the "number of channels" parameter with unmodified value in the SDP answer and shall also supply it to the MRFP in the local descriptor for the termination towards the offerer with the same value.
ch-send (NOTE 1)	If the ch-send parameter is contained in the SDP offer the MRFC shall check if the MRFP supports the indicated number of channels in the receive direction. If the indicated number of channels is not supported, the MRFC shall not select the EVS payload type. If the MRFC selects the EVS payload type, the MRFC shall forward the ch-send parameter to the MRFP for the termination towards the offerer in the remote descriptor.	If the ch-recv parameter is contained in the SDP offer, the MRFC shall include the ch-send parameter with unmodified value in the SDP answer and shall also supply the ch-send parameter to the MRFP in the local descriptor for the termination towards the offerer with the same value.
ch-recv (NOTE 1)	If the ch-recv parameter is contained in the SDP offer the MRFC shall check if the MRFP supports the indicated number of channels in the send direction. If the indicated number of channels is not supported, the MRFC shall not select the EVS payload type. If the MRFC selects the EVS payload type for transcoding, the MRFC shall forward the ch-recv parameter to the MRFP for the termination towards the offerer in the remote descriptor.	If the ch-send parameter is contained in the SDP offer, the MRFC shall include the ch-recv parameter with unmodified value in the SDP answer and shall also supply the ch-recv parameter to the MRFP in the local descriptor for the termination towards the offerer with the same value.
mode-set (NOTE 3)	If the mode-set parameter is contained in the SDP offer and the MRFC select the EVS payload type, the MRFC shall forward this parameter to the MRFP for the termination towards the offerer in the remote descriptor.	If the mode-set parameter is contained in the SDP offer, the MRFC shall include the mode-set parameter with unmodified value in the SDP answer. Otherwise, if EVS or AMR-WB is used on possible other call legs in the conference, the MRFC should include the mode-set parameter with a value indicating the mode that was negotiated on those other call legs (or omit it if no restrictions applied before). If the MRFC supplies the mode-set parameter in the SDP answer, it shall also supply it to the MRFP in the local descriptor for the termination towards the offerer with the same value.
mode-change-period (NOTE 3)	If the mode-change-period parameter is contained in the SDP offer and the MRFC select the EVS payload type, the MRFC shall forward this parameter to the MRFP for the termination towards the offerer in the remote descriptor.	If the MRFC select the EVS payload type, the MRFC shall either include the mode-change-capability parameter with value 2 or omit it. If the MRFC supplies the mode-change-capability parameter in the SDP answer, it may also supply it to the MRFP in the local descriptor for the termination towards the offerer with the same value.
mode-change-capability (NOTE 3)	If the mode-change-capability parameter is contained in the SDP offer and the MRFC select the EVS payload type, the MRFC may forward this parameter to the MRFP for the termination towards the offerer in the remote descriptor.	If EVS or AMR-WB is used on possible other EVS call legs in the conference, the MRFC should include the mode-change-capability parameter with a value indicating the mode that was negotiated on those other call legs (or omit it if no restrictions applied before). If the MRFC supplies the mode-change-capability parameter in the SDP answer, it may also supply it to the MRFP in the local descriptor for the termination towards the offerer with the same value.
mode-change-neighbor (NOTE 3)	If the mode-change-neighbor parameter is contained in the SDP offer and the MRFC select the EVS payload type, the MRFC shall forward this parameter to the MRFP for the termination towards the offerer in the remote descriptor.	If EVS or AMR-WB was used on possible other EVS call legs in the conference, the MRFC should include the mode-change-neighbor parameter with a value indicating the mode that was negotiated on those other call legs (or omit it if no restrictions applied before). If the MRFC supplies the mode-change-neighbor parameter in the SDP answer, it shall also supply it to the MRFP in the local descriptor for the termination towards the offerer with the same value.
max-red (NOTE 5)	If the max-red parameter is contained in the SDP offer and the MRFC select the EVS payload type, the MRFC shall forward this parameter to the MRFP for the termination towards the offerer in the remote descriptor.	The MRFC shall only include the max-red parameter in the SDP answer if it desires to restrict the maximum redundancy of received packets. When selecting the value of the max-red parameter, the MRFC shall consider the capabilities of the MRFP and, if EVS or AMR-WB is used on possible other EVS call legs in the conference, the redundancy that was negotiated on those call legs. If the MRFC supplies the max-red parameter in the SDP answer, it shall also supply it to the MRFP in the local descriptor for the termination towards the offerer with the same value.
3gpp_mtsi_app_adapt (NOTE 4)	If the 3gpp_mtsi_app_adapt parameter is contained in the SDP answer, and the MRFC select the EVS payload type, the MRFC shall forward this parameter to the MRFP the MRFC shall forward this parameter to the MRFP in the remote descriptor.	If the MRFP supports RTCP APP based adaptation messages defined in 3GPP TS 26.114 [23], and the MRFC has a policy to negotiate the usage of those messages, the MRFC shall include the 3gpp_mtsi_app_adapt SDP attribute indicating the allowed APP messages in the SDP answer. If EVS is used possible other EVS call legs in the conference, the MRFC should consider the negotiated RTCP APP packet types on those call legs in addition to the MRFP capabilities when selecting the allowed RTCP APP messages.
NOTE 1: This MIME parameter of the EVS RTP payload type is defined in 3GPP TS 26.445 [43]. It is encapsulated within the SDP "a=fmtp" attribute defined IETF RFC 4566 [44]. NOTE 2: This number of channels are encoded as "encoding parameters" of the SDP "a=rtpmap" attribute defined in IETF RFC 4566 [44]. NOTE 3: This MIME parameter of the EVS RTP payload type relates to AMR-WB IO mode and is defined in IETF RFC 4867 [45]. It is encapsulated within the SDP "a=fmtp" attribute defined IETF RFC 4566 [44]. NOTE 4: This SDP attribute is defined in 3GPP TS 26.114 [23]. It applies to all codecs offered in an SDP media line. However, some values are specific to EVS. NOTE 5: This MIME parameter of the EVS RTP payload type is defined in IETF RFC 4867 [45]. It is encapsulated within the SDP "a=fmtp" attribute defined IETF RFC 4566 [44].

The MRFP handling of EVS codec parameters shall follow table 5.13.3.3 in 3GPP TS 23.334 [41]. The MRFP should support transcoding of EVS with bandwidths (sampling rates) which are supported by codec the MRFP is capable to transcode EVS to/from (e.g. NB for AMR, and WB for AMR-WB).

5.13 Video Transcoding

The MRFP shall support video transcoding between streams of two Terminations within the same context where the streams are encoded differently, in accordance with standard H.248 principles, see ITU-T H.248.1 [3].

NOTE: 3GPP video codecs are specified in 3GPP TS 26.114 [23].

5.14 Floor Control Service Requirement

5.14.1 General

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) IETF RFC 4376 [19]. Floor control is an optional procedure; where "shall" is used it is meant that this is basic required functionality within the feature.

5.14.2 Architecture

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

Figure 5.14.2.1: Functionality Architecture of Floor Control

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 IETF RFC 4582 [20]. 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 IETF RFC 4582 [20].

– Floor Chair, the Floor Chair shall support Client operations and Floor Chair operations as described in IETF RFC 4582 [20].

– Floor Control Server, the Floor Control Server (FCS) shall support Floor Control Server operations as described in IETF RFC 4582 [20].

5.14.3 Services Requirements

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).

1. The MRF shall support the following Floor control policy related to Floor control:

– Whether the Floor control is in use or not.

– The algorithm to be used in granting the Floor.

The following algorithms shall be supported:

– FCFS (First Come First Served)

The following algorithms may be supported:

– Chair-Controlled

– The maximum number of users who can hold the Floor at the same time.

– To assign and modify the Floor Chair, if the Floor is Chair-controlled.

The MRF may support the following:

– Announcements/tones from network for indicating when a user gets and looses the hold of the Floor (note: announcement may also be text or indication in video)

2. The MRF, acting as FCS, shall support the communication with the Floor Participants and the Floor Chairs according to the BFCP protocol as described in IETF RFC 4582 [20] , providing:

– Communication between Floor Participant and FCS such that the participant shall be able to request/ modify /release a Floor for the Floor Participant himself or a third-party Floor Participant;

– Communication between Floor Chair and FCS such that the Chair shall be able to receive Floor requests and to grant/ reject/ revoke the Floor requests.

5.14.4 Information Flows

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

5.14.4.1 User requesting the Floor during a conference

Figure 5.14.4.1.1 shows a Floor Participant requesting the Floor to obtain the right to talk during a conference. The UE#1 is a Floor Participant, the Floor of the "right to talk" is Chair-controlled and the UE#2 is the Floor Chair of the conference.

Figure 5.14.4.1.1: User requesting the Floor to obtain the right to talk during a conference

The details of the flows are as follows:

1. Conference session with UE#1 & UE#2 established

The UE#1 and UE#2 are participants of an existing conference. The BFCP connections between the participant and the MRF need to be established before the BFCP communication.

2. FloorRequest

The UE#1 requests the MRF for the Floor of the "right to talk". The message format is described in IETF RFC 4582 [20].

3. FloorStatus

The MRF notifies the UE#2 the Floor request from UE#1. The message format is described in IETF RFC 4582[20].

4. ChairAction

The UE#2 grants the Floor request and sends instruction to the MRF to action. The message format is described in IETF RFC 4582[20].

5. ChairActionAck

The MRF acknowledges the ChairAction message. The message format is described in IETF RFC 4582[20].

6. Floor RequestStatus

The MRF informs UE#1 about the status of their Floor requests. The message format is described in IETF RFC 4582[20].

7. UE#1 send and receive media (or audio) from/to the conference

Now the UE#1 has been granted the Floor of the "right to talk", it may send and receive the audio stream to the MRF.

5.14.4.2 User releasing the Floor during a conference

Figure 5.14.4.2.1 shows a Floor Participant requesting to release the Floor to give up the right to talk during a conference. The UE#1 is a Floor Participant and owns the Floor of the "right to talk", the Floor is Chair-controlled and the UE#2 is the Floor Chair of the conference.

Figure 5.14.4.2.1: User releasing the Floor to give up the right to talk during a conference

The details of the flows are as follows:

1. Conference session with UE#1 & UE#2 established

The UE#1 and UE#2 are participants of an existing conference. The BFCP connections between the participant and the MRF need to be established before the BFCP communication.

2. FloorRelease

The UE#1 requests to release the MRF for the Floor of the "right to talk". The message format is described in IETF RFC 4582 [20].

3. FloorStatus

The MRF notifies the UE#2 the Floor release request from UE#1. The message format is described in IETF RFC 4582[20].

4. Floor RequestStatus

The MRF informs UE#1 about the status of the Floor release request. The message format is described in IETF RFC 4582[20].

5. UE#1 receive stream from the conference

Now the UE#1 has been revoked the right to talk, he may receive the audio stream from the MRF only.

5.14.5 Requirements on Mp interface

5.14.5.1 Requirements for MRFP based FCS

The MRFC shall indicate to the MRFP the Floor Control Policy:

– The algorithm to be used in granting the Floor.

– The FCFS algorithm shall be supported.

– The Chair-controlled algorithm may be supported.

– The maximum number of users who can hold the same Floor at the same time.

– To assign and modify the Floor Chair, if the Floor is Chair-controlled.

– The Floor media type shall be audio, video or a combination of one or more media type.

– The association between Floors and resources.

The MRFP shall maintain the state of the Floor(s), including which Floors exists, which terminations hold which Floors, and which termination is the Floor Chair, if the floor is Chair-controlled.

The MRFC may request the MRFP to establish a BFCP connection between the MRFP (FCS) and the Client (via Floor control Client Termination).

The MRFP shall support the communication with a Floor Participant such that the participant may request/ modify /release a Floor for the Floor Participant himself or a third-party Floor Participant according to the BFCP protocol [20].

The MRFP may support the communication with Floor Chair such that the Chair shall be able to receive Floor requests and to grant/ reject/ revoke the Floor according to the BFCP protocol [20].

The MRFP shall (if requested by the MRFC) report to the MRFC any requests to change the Floor holding status. The MRFC shall indicate to the MRFP to modify the Client’s access right to the media according to the changes in Floor status.

The MRFC may request the MRFP to play tones (according to clause 5.1) or announcements (according to clause 5.2) for indicating when a Client gains or loses a Floor.

5.15 Explicit Congestion Notification Service Requirement

5.15.1 General

A MRFC/MRFP may support Multimedia Telephony using Explicit Congestion Notification see IETF RFC 3168 [24], 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 3GPP TS 26.114 [23].

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.

5.16 Multimedia Priority Service (MPS) Support

The Multimedia Priority Service (MPS) is specified in 3GPP TS 22.153 [26]. The MRFC and MRFP may support the priority treatment of a call/session identified as an MPS call/session. If MPS is supported then upon receipt of the MPS priority information in the call control signalling:

– The MRFC shall recognise the call/session as having priority.

– The MRFC shall send the Priority information for a context to the MRFP to enable the priority treatment described below related to the MRFP.

– The MRFC shall apply priority handling to H.248 transactions related to priority calls/sessions when network resources are congested, e.g., preferential treatment in any queues or buffers.

– If the H.248 control association utilises a transport with the possibility for prioritisation, the MRFC may apply priority using the appropriate prioritisation procedures.

– If the MPS Priority service requires a specific MPS DSCP setting, the MRFC shall configure the MRFP to apply a specific MPS DSCP marking to the user data transport packets to indicate that the packets are of a higher priority than those for normal calls.

– If the MRFP receives an indication to apply a specific MPS DSCP marking to the user data transport packets, it shall apply this DSCP marking to the IP headers.

NOTE 1: Support of Diffserv procedures by the MRFP assumes an operator uses Diffserv for prioritising user plane traffic related to an MPS call/session.

– When the MRFC marks a Context with Priority information, the MRFP may use the Priority information for selecting resources for the media and signaling transport with priority. The following actions may be taken by the MRFP if it has reached a congested state:

i) seize priority reserved resources; or

ii) if resources are completely congested, indicate that in a Command Response error code.

NOTE 2: The Priority information can be used to derive Layer 2 QoS marking and trigger priority identification and priority treatment for other QoS technologies than Diffserv.

5.17 Coordination of Video Orientation

The MRFC and the MRFP may support the Coordination of Video Orientation (CVO) as defined in 3GPP TS 26.114 [23].

Upon receipt of an SDP offer containing the RTP header extension attribute(s) "a=extmap" as defined in IETF RFC 5285 [27] and if the "a=extmap" attribute indicates the CVO URN(s) (i.e. the CVO URN for a 2 bit granularity of rotation and/or the CVO URN for a higher granularity of rotation) as defined in 3GPP TS 26.114 [23], then:

a) if the MRFC and the MRFP support the CVO feature, the MRFC shall:

– include an "extended RTP header for CVO" information element when seizing resources in the MRFP to indicate the MRFP that it shall allow the RTP header extension for CVO to pass; and

– select exactly one of the CVO related "a=extmap" attribute from the SDP offer and include the "a=extmap" attribute indicating selected CVO URN in the SDP answer that will be sent within the SIP signalling; or

b) if the MRFP does not support the CVO feature the MRFC shall send the SDP answer without any CVO related "a=extmap" attribute within the SIP signalling.

NOTE 1: The UE supporting the CVO feature will not send the extended RTP headers for CVO if the UE did not receive any SDP answer with the CVO related "a=extmap" attribute.

When the MRFC selects one of the CVO related "a=extmap" attribute(s) from the SDP offer the MRFC shall take into consideration which CVO variant it has negotiated for CVO for other call leg(s) in the session.

If the MRFC and MRFP support the CVO feature then before sending an SDP offer, the MRFC shall:

a) determine based on the local policy and the CVO negotiation results on other call legs if, and with which granularity to offer CVO; and

b) if the MRFC determines to offer CVO:

– the MRFC shall include the "extended RTP header for CVO" information element when seizing resources in the MRFP to indicate the MRFP that it shall allow the RTP header extension for CVO to pass; and

– the MRFC shall include the CVO related "a=extmap" attribute in the SDP offer it sends within the SIP signalling.

If the MRFP does not support the CVO feature, the MRFC shall send the SDP offer without any CVO related "a=extmap" attribute within the SIP signalling.

NOTE 2: The UE supporting the CVO feature will not send the extended RTP headers for CVO if the UE did not receive any SDP offer with the CVO related "a=extmap" attribute.

If the MRFP supports the CVO feature and has been instructed to pass on the extended RTP header for CVO as described above then:

– if the MRFP does not apply video transcoding, it shall pass any received RTP CVO header extension to succeeding RTP streams; or

– if the MRFP applies video transcoding, it shall keep the video orientation unchanged during the transcoding and copy the received RTP CVO header extension into the succeeding RTP streams after transcoding the associated group of packets.

NOTE 3: IETF RFC 5285 [27] provides a framework for header extensions and can also be used for non-CVO related purposes. It is an implementation decision of the MRFP if it only passes CVO related RTP header extensions, or if it passes any RTP header extension when being instructed with the "extended RTP header for CVO" information element.

NOTE 4: The behaviour of the MRFP when being instructed with "an extended RTP header for CVO" information element may be variable due to the settings on the incoming and outgoing directions as listed in the table 5.17.1 and left further for implementation decision.

NOTE 5: Unknown IETF RFC 5285 [27] RTP header extensions are ignored by the destination RTP end system.

NOTE 6: In the conference scenarios when the picture mixing is needed, the MRFP can perform the video rotation of picture elements according to the received RTP CVO header extension for the associated pictures to achieve a consistent orientation for all of the components in the mixture collage.

Table 5.17.1: MRFP behaviour with different settings of "extended RTP header for CVO" information element in a particular direction

Connection Point A in incoming direction	Connection Point B in outgoing direction	MRFP behaviour on CVO processing
With CVO	With CVO	Received RTP CVO header extension is forwarded to the outgoing direction.
With CVO	No CVO	Received RTP CVO header extension is forwarded to the outgoing direction.
No CVO	With CVO	No RTP CVO header extension is forwarded since the source video does not contain any CVO information.

5.18 Generic image attributes

The MRFC and the MRFP may support the generic image attributes to negotiate the image size for sending and receiving video as required by 3GPP TS 26.114 [23].

If the MRFP and the MRFC support the negotiation of the image size and the MRFC receives an SDP offer with the media-level SDP image attribute(s) "a=imageattr", as defined in IETF RFC 6236 [28], and if the received image sizes are supported by the MRFP then the MRFC shall:

– include the generic image attribute parameters for the send and receive directions when seizing or modifying resources in the MRFP; and

– include the SDP image attribute "a=imageattr" indicating the supported image sizes in the SDP answer on the Mr interface.

NOTE 1: The image attribute may be used within the SDP capability negotiation framework and its use is then specified using the "a=acap" parameter.

NOTE 2: The MRFC not supporting the negotiation of the image size will ignore received generic image attributes and will return the SDP answer without any associated generic image attribute.

When sending the SDP body with image attribute(s) on the Mr interface the MRFC shall include in the "a=imageattr":

– "recv" keyword and corresponding image sizes which the MRFP supports in the receiving direction; and

– "send" keyword and corresponding image sizes which the MRFP supports in the sending direction.

If the MRFP and the MRFC support the negotiation of the image size and the MRFC sends an SDP offer for subsequent call leg in a conference, the MRFC should include the SDP image attribute(s) "a=imageattr", with image sizes as supported by the MRFP and negotiated at other call legs in the session.

If the MRFC receives an SDP answer containing the SDP image attribute "a=imageattr", it shall modify resources in the MRFP if needed by indicating the supported image sizes within the generic image attribute parameter.

If the MRFC supports the negotiation of the image size and if the MRFC sends on the Mr interface the SDP body (offer or answer) it shall adjust the image sizes to be the same for the call legs in the session.

If the MRFP does not support the negotiation of the image size the MRFC shall send on the Mr interface the SDP body (offer or answer) without any image attribute "a=imageattr".

If the MRFP is configured with different image sizes on the receive direction of one termination and the send direction of another interconnected termination, then it shall adjust the frame sizes accordingly when forwarding video media streams and use the image size as described in 3GPP TS 26.114 [23] when sending media.

NOTE 3: The relation between the negotiated image sizes and CVO are specified in 3GPP TS 26.114 [23].

NOTE 4: The generic image attribute includes information related to the send and receive capabilities of a single termination, and the adjustment of image sizes is typically based on the setting of two connected terminations in a single context.

5.19 Interactive Connectivity Establishment support

5.19.1 General

The MRFC and the MRFP may support Interactive Connectivity Establishment defined in IETF RFC 8445 [66] and IETF RFC 8839 [67], and 3GPP TS 24.229 [30] for NAT traversal as required by 3GPP TS 23.228 [1]. 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 IETF RFC 8445 [66].

The MRFC and MRFP shall only use host candidates as local ICE candidates.

NOTE: MRFC and MRFP are not located behind a NAT from perspective of the ICE deployment model according to figure 1 in IETF RFC 8445 [66].

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.

5.19.2 ICE lite

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;

NOTE 1: Requesting only one host candidate per m-line prevents that the MRFC will receive "a=remote-candidates" SDP attributes in a subsequent SDP. Requesting separate ufrag and password for each media line simplifies H.248 encoding.

– 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.

NOTE 2: This avoids that the ICE lite peer needs to send extra SDP offers to complete ICE procedures.

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 clause 7.2 of IETF RFC 8445 [66].

When receiving a request to act as STUN server, the MRFP shall be prepared to answer STUN binding request according to clause 7.2 of IETF RFC 8445 [66]. 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.

5.19.3 Full ICE

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;

NOTE: Requesting only one host candidate per m-line prevents that the MRFC will receive "a=remote-candidates" SDP attributes in a subsequent SDP. Requesting separate ufrag and password for each media line simplifies H.248 encoding.

– 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:

a) if the "a=ice-pacing" attribute was present in the received SDP answer, the received pacing value; or

b) 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 clause 6.1.1 of IETF RFC 8445 [66];

– 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:

a) if the "a=ice-pacing" attribute was present in the received SDP answer, the received pacing value; or

b) otherwise the default pacing value of 50 ms;

– shall determine the role of the MRFC in ICE (controlling or controlled) according to clause 6.1.1 of IETF RFC 8445 [66];

– 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 clause 4.4.1 of IETF RFC 8839 [67] if it has the controlling role and the highest-priority candidate pair differs from the default candidates in previous SDP.

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 IETF RFC 8445 [66]).

When receiving a request to act as STUN server, the MRFP shall be prepared to answer STUN binding request according to clause 7.3 of IETF RFC 8445 [66]. 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 clause 6.1.2 of IETF RFC 8445 [66];

– shall schedule checks for the ICE candidate pairs according to clause 6.1.4 of IETF RFC 8445 [66];

– shall send STUN connectivity checks for the scheduled checks according to clause 7.2 of IETF RFC 8445 [66];

– 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.

5.20 IMS Media Plane Security

5.20.1 General

The MRFC and the MRFP may support IMS media plane security as specified in 3GPP TS 33.328 [31]. They may support end-to-end security (e2e) for a TCP (see IETF RFC 793 [38]) based media using TLS and the Key Management Service (KMS). The e2e media security of TCP is based on the session keys negotiated via the TLS handshake protocol between the served UE and the MRFP as specified in 3GPP TS 33.328 [31].

E2e security for TCP based media using TLS and KMS is applicable for MSRP (see IETF RFC 4975 [18]; used in IMS session-based messaging conference) and BFCP (see IETF RFC 4582 [20]; used in IMS conferencing). The MRFC and the MRFP may support e2e security for MSRP, BFCP, or both protocols.

E2e protection of the MSRP and BFCP sessions is achieved through the KMS and a "ticket" concept:

– The session initiator requests keys and a ticket from the KMS. The ticket contains the keys in a protected format. The initiator then sends the ticket to the recipient.

– The recipient presents the ticket to the KMS and the KMS returns the keys on which the media security shall be based.

5.20.2 End-to-end security for TCP-based media using TLS

The e2e protection of the TCP based media relies on the usage of TLS according to the TLS profiles specified in Annex E of 3GPP TS 33.310 [47] and Annex M of 3GPP TS 33.328 [31].

The end-to-end security protection of session based messaging (MSRP) and conferencing (BFCP) is based on the pre-shared key ciphersuites for TLS (specified in IETF RFC 4279 [34] and with the profile defined in Annex H of 3GPP TS 33.328 [31]) and the MIKEY-TICKET mechanism (specified in IETF RFC 6043 [33] with the profiling of the tickets and procedures given in 3GPP TS 33.328 [31].

The Pre-Shared Key (PSK) is the Traffic-Encrypting Key (TEK) associated with the Crypto Session (CS) that shall be used in the TLS handshake.

NOTE 1: The Security Parameters Index (SPI) in the CS points to a TEK Generation Key (TGK) that is used to derive the TEK for the crypto session using the CS ID (and some other parameters). The SPI could also point to a TEK directly.

If the MRFC and the MRFP support and are configured to use the e2e protection of the TCP based media using the pre-shared key ciphersuites for TLS and the MIKEY-TICKET mechanism, the following functional requirements apply.

The list of pre-shared key ciphersuites for TLS supported by the MRFP shall be preconfigured in the MRFC.

According to the TLS profile specified in Annex E of 3GPP TS 33.310 [47], the MRFP shall accept TLS renegotiation only if it is secured according to IETF RFC 5746 [46].

NOTE 2: IETF RFC 5746 [46] defines a "TLS secure renegotiation" procedure, which leaves the definition of a basic TLS renegotiation still open. H.248 based support to enable the MRFC to allow or not allow the MRFP to perform client initiated or server initiated TLS renegotiation is not addressed in the present release. The behaviour of the MRFP for "TLS session renegotiation" procedure is hence not further defined in the present release.

The MRFC acting as the session initiator shall:

– prepare the media security offer in the SDP body of the SIP INVITE request;

– include a single crypto session of type TLS in the TRANSFER_INIT message according to procedures specified in 3GPP TS 33.328 [31]; and

NOTE 3: Depending on the KMS and a local policy, the MRFC will either interact with the KMS to obtain keys and the MIKEY-TICKET ticket usable for the served UE or will create the ticket by itself. In the latter case, MIKEY-TICKET mode 3 as specified in IETF RFC 6043 [33] is used, and the MRFC will then perform all key and ticket generation functions otherwise performed by the KMS.

– insert in the SDP offer the SDP key management protocol attribute "a=key-mgmt" specified in IETF RFC 4567 [35] which indicates use of the MIKEY-TICKET ticket and contains the TRANSFER_INIT message.

Upon receipt of the SIP response with the SDP answer the MRFC shall check that the responder is authorized before completing the media security setup. If the MRFC notices that the other endpoint is not as expected, the MRFC shall abort the session setup. Otherwise the MRFC shall derive the PSK and shall send it to the MRFP.

Upon receipt of the SIP INVITE request with the SDP offer containing the media security offer and the SDP key management protocol attribute "a=key-mgmt" specified in IETF RFC 4567 [35] which indicates use of the MIKEY-TICKET ticket and contains the TRANSFER_INIT message the MRFC shall:

– check if it is authorized to resolve the ticket and if that is the case the MRFC interacts with the KMS to resolve the ticket and receive keys;

– include the MIKEY-TICKET response in the generated TRANSFER_RESP message;

– insert in the SDP answer the SDP key management protocol attribute "a=key-mgmt" specified in IETF RFC 4567 [35] which indicates use of the MIKEY-TICKET ticket and contains the TRANSFER_RESP message; and

– shall derive the PSK and shall send it to the MRFP.

The MRFC acting as the session initiator or the session responder shall:

– determine via SDP negotiation as specified in IETF RFC 4145 [36] if the MRFP needs to act as TCP client or server;

– request the MRFP to start the TCP connection establishment if the MRFP needs to act as TCP client;

– determine via SDP negotiation if the MRFP needs to act as TLS client or server as specified in the clauses below;

NOTE 4: The determination of the TLS client/server role relies on different rules for MSRP and BFCP.

– if the MRFP needs to act as TLS client, request the MRFP to start the TLS session setup once the TCP connection is established towards the served UE; and

– apply additional specific procedures specified for the MSRP in clause 5.20.3 or for the BFCP in clause 5.20.4.

The MRFP shall:

– upon request from the MRFC, start a TCP connection establishment by sending a TCP SYN;

– release the underlying TCP bearer connection as soon as the TLS session is released;

– be capable to support both the TLS server and TLS client roles;

– when being instructed to start the TLS session setup, act as a TLS client and establish the TLS session as soon as the underlying TCP bearer connection is established;

– uniquely associate the PSK received from the MRFC with the corresponding TCP based media stream;

– use the received PSK in the TLS handshake; and

– apply additional specific procedures specified for the MSRP in clause 5.20.3 or for the BFCP in clause 5.20.4.

5.20.3 Specific requirements for session based messaging (MSRP)

For the each MSRP media stream requiring e2e security, the MRFC shall:

a) indicate "TCP/TLS/MSRP" as transport protocol when requesting resources from the MRFP; and

b) determine via SDP negotiation if the MRFP needs to act as TLS client or TLS server as specified in IETF RFC 8122 [39] using the IETF RFC 4145 [36] "a=setup" SDP attribute as follows:

– if the MRFC sends the "a=setup:active" SDP attribute in the SDP answer towards the UE, the MRFP shall act as TLS client;

– if the MRFC sends the "a=setup:passive" SDP attribute in the SDP answer towards the UE, the MRFP shall act as TLS server;

– if the MRFC receives the "a=setup:active" SDP attribute in the SDP answer from the UE, the MRFP shall act as TLS server; and

– if the MRFC receives the "a=setup:passive" SDP attribute in the SDP answer from the UE, the MRFP shall act as TLS client.

NOTE: Since the "a=setup:" SDP attribute is used for the negotiation of the client/server roles for both protocols, TCP and TLS, then the assignment of a particular endpoint role (client or server) also applies for both protocols (e.g. the TLS server role assignment means also the TCP server role assignment).

The MRFP shall send the TLS protected MSRP packets to the served UE and shall accept the TLS protected MSRP packets from the served UE as requested by the MRFC.

5.20.4 Specific requirements for conferencing (BFCP)

For the each BFCP media stream requiring e2e security, the MRFC shall:

a) indicate "TCP/TLS/BFCP" as transport protocol when requesting resources from the MRFP; and

b) determine via SDP negotiation (see IETF RFC 4583 [21]) if the MRFP needs to act as TLS client or TLS server as follows:

– if the MRFC receives an initial SDP offer from the served UE, the MRFP shall act as TLS server; or

– if the MRFC sends an initial SDP offer towards the served UE, the MRFP shall act as TLS client.

The MRFP shall send the TLS protected BFCP packets to the served UE and shall accept the TLS protected BFCP packets from the served UE as requested by the MRFC.

5.21 TCP bearer connection control

If an MRFC and an MRFP support TCP as transport protocol (see IETF RFC 793 [38] and IETF RFC 4145 [36]), the following functional requirements apply.

NOTE 1: Support of TCP is required if the MRFC and the MRFP support the session based messaging (MSRP), (see IETF RFC 4975 [18]), and the conferencing using the floor control service (BFCP), (see IETF RFC 4582 [20]).

NOTE 2: It is assumed that these requirements also apply to pre-Release 12 MRFCs and MRFPs.

Upon reception of an SDP offer or an SDP answer containing a media line for a new TCP based media stream, the MRFC shall for that TCP based media stream:

– determine via SDP negotiation if the MRFP needs to act as TCP client or TCP server using the IETF RFC 4145 [36] "a=setup" SDP attribute as follows:

a) if the MRFC sends the "a=setup:active" SDP attribute in the SDP answer towards the conference participant, the MRFP shall act as TCP client;

b) if the MRFC sends the "a=setup:passive" SDP attribute in the SDP answer towards the conference participant, the MRFP shall act as TCP server;

c) if the MRFC receives the "a=setup:active" SDP attribute in the SDP answer from the conference participant, the MRFP shall act as TCP server; and

d) if the MRFC receives the "a=setup:passive" SDP attribute in the SDP answer from the conference participant, the MRFP shall act as TCP client;

– if no media security is applied, indicate "TCP/MSRP" (for session based messaging) or "TCP/BFCP" (for conferencing) as transport protocol to the MRFP;

– if media security is applied, indicate the transport protocol according to clause 5.20 to the MRFP;

– request the MRFP to allocate a TCP port at the termination towards the SDP offerer/answerer;

– indicate TCP port number from the received SDP offer/answer in the remote descriptor at the termination towards the SDP offerer/answerer;

– request the MRFP to start a TCP connection establishment if the MRFP needs to act as TCP client; and

– request the MRFP to report TCP connection establishment related failures.

Upon request from the MRFC to reserve and/or configure resources for TCP based media the MRFP shall:

– if being instructed to start TCP connection establishment at a given termination, start TCP connection establishment at that TCP termination by sending a TCP SYN message;

– if not being instructed to start TCP connection establishment at a given termination, answer any received TCP SYN message at a given termination with appropriate messages according to TCP procedures; and

NOTE 3: The MRFP will use the source IP address and TCP port of the received TCP SYN message as a destination address for the TCP SYN ACK message.

– report TCP connection establishment related failures to the MRFC.

5.22 Support of Telepresence

5.22.1 General

If the MRFC and the MRFP support telepresence, as specified in 3GPP TS 24.103 [52] and if the CLUE data channel used for telepresence is terminated in the MRFP, the following requirements and procedure apply.

5.22.2 Characteristics of the Telepresence support

The characteristics of the telepresence support by the MRFC and the MRFP are the following:

1) Regarding usage of CLUE data channel with respect to H.248 context/termination/stream model:

a) there is only one single H.248 termination for the telepresence bearer traffic of a single conference participant, which covers all telepresence media traffic flows and CLUE for control purposes;

b) there is only one CLUE data channel per conference participant (i.e., per H.248 termination);

c) the CLUE protocol including the underlying transport of a CLUE data channel, SCTP association, DTLS and lower layer protocols are modelled by a single H.248 stream; and

d) there is only one single CLUE data channel per SCTP association, hence a single SCTP stream only;

2) Regarding the transport protocol stack:

a) the L4 protocol is always "UDP";

NOTE 1: Any switchover to or alternative usage of "TCP" (due to possible NAT traversal issues) is out of scope. The option of DTLS-over-TCP is not supported (despite the fact that the CLUE data channel is based on the framework of WebRTC data channels).

3) For the protocol termination of SCTP in the MRFP:

a) the protocol parameter configuration for the SCTP is done via configuration management or default value settings, apart from the information elements (specified in clause 5.22.3) which are signalled between the MRFC and the MRFP using the SDP for SCTP;

4) Regarding the establishment procedures for DTLS and SCTP:

a) the establishment of a SCTP association is tightly coupled to the successful establishment of the underlying DTLS session/connection;

b) only an immediate SCTP establishment is supported;

NOTE 2: Hence, an explicit information element for triggering the sending of an outgoing SCTP establishment request is not required.

c) the MRFP will immediately send an outgoing SCTP establishment request (SCTP INIT) when DTLS layer connectivity is available, if the MRFP did not already receive an incoming SCTP establishment request;

5) Regarding the procedure for closing the CLUE data channel:

NOTE 3: The closure procedure according to clause 3.2.7 of IETF RFC 8850 [49] is not supported (because the correspondent "SCTP reset message" cannot be explicitly triggered by the MRFC.

a) the MRFP will deny during the SCTP association establishment phase the negotiation of SCTP extensions (such as the SCTP stream reset capability) in order to prevent their later usage for a closure procedure; and

b) a CLUE data channel is released by a removal of the H.248 stream endpoint or the subtraction of the H.248 termination, or a release procedure of the DTLS bearer session. All these triggers lead firstly to a SCTP shutdown procedure and then a subsequent DTLS bearer session release procedure;

6) security aspects:

a) incoming DTLS session/connection establishment request is not blocked; and

b) incoming SCTP association establishment request is not blocked.

5.22.3 CLUE data channel establishment

For establishing a CLUE data channel an SDP-based "SCTP over DTLS" data channel negotiation mechanism is used. SDP offer/answer transactions between the MRFC and the served TP UE are based on the SDP offer/answer procedure specified in IETF RFC 8841 [48] and IETF RFC 8842 [65]. The SDP describing an SCTP association over DTLS/UDP to be used to realize a CLUE data channel contains:

– "m=" line with "UDP/DTLS/SCTP" as transport protocol and UDP port;

– associated pair of "tls-id" SDP attribute values (the attribute values of the TP UE and the MRFC, see IETF RFC 8842 [65]);

– associated "sctp-port" and optional "max-message-size" attributes (see IETF RFC 8841 [48]); and

– associated "dcmap" attribute (specified in IETF RFC 8864 [50]) with a "stream-id" parameter set to a value of the used SCTP stream and a subprotocol parameter set to "CLUE" as specified in IETF RFC 8850 [49].

For the media line with "UDP/DTLS/SCTP" as transport protocol to be set up for a CLUE data channel, the MRFC:

– shall send the remote UDP port and SCTP port to the MRFP;

– shall request the local UDP port and SCTP port from the MRFP;

– shall indicate the MRFP to start a DTLS bearer session establishment at the termination towards the SDP offerer, if the received SDP offerer contains an "a=setup:passive" SDP attribute;

– shall send the dcmap-stream-id parameter that is contained in the received SDP offer, indicating the actual SCTP stream identifier with the SCTP association (over DTLS/UDP) used to realize the CLUE data channel;

– shall send the subprotocol value of "CLUE", indicating the protocol to be exchanged via the data channel;

– if the max-message-size parameter is contained in the received SDP offer, may forward the received max-message-size parameter, indicating to the MRFP the maximum message size the served TP UE is willing to accept;

– may request the maximum message size the MRFP is willing to accept;

– shall send the received TP UE certificate fingerprint to the MRFP that is then able to correlate the fingerprint within the CLUE data channel uniquely; and

– shall request the certificate fingerprint from the MRFP, for the "m=" line to be transported between the served TP UE and the MRFP using CLUE data channel.

For the media line with "UDP/DTLS/SCTP" as transport protocol to be set up for a CLUE data channel, the MRFP shall:

– allocate the local UDP port and SCTP port, and send them to the MRFC;

– when being instructed to start the DTLS bearer session setup, act as a DTLS client and establish the DTLS bearer session;

– if it is requested from the MRFC, set the maximum message size that is acceptable for the CLUE data channel and send it to the MRFC;

– upon request from the MRFC, select an own certificate for the CLUE data channel, and send the fingerprint of the own certificate to the MRFC;

– uniquely associate the certificate fingerprint received from the MRFC with the corresponding CLUE data channel, and subsequently use the certificate fingerprint to verify the establishment of the DTLS bearer session;

– if the verification of the remote certificate fingerprint during the DTLS bearer session establishment fails, regard the remote DTLS endpoint as not authenticated, terminate the DTLS bearer session and report the unsuccessful DTLS bearer session setup to the MRFC; and

– indicate the support of the required SCTP extensions (i.e. RE-CONFIG) and other SCTP considerations as defined in clause 3.2 of IETF RFC 8850 [49] at the start of the SCTP association.

5.22.4 Release of CLUE data channel

To close the CLUE data channel, the MRFC may instruct the MRFP to release the underlying communication (i.e., protocol stack UDP/DTLS/SCTP) for the CLUE data channel, which may result in triggering the release of the DTLS bearer session (which then will implicitly lead to a SCTP association shutdown procedure).

Regarding the SCTP reset, the MRFP shall provide a pre-configured (i.e., autonomous) behaviour by preventing "SCTP Stream Reconfiguration" procedures as specified in IETF RFC 6525[51], which results in:

1) for an outgoing direction: the MRFP shall not initiate any "Sender-Side Procedures for the RE-CONFIG Chunk", as specified in IETF RFC 6525[51]; and

2) for an incoming direction: the MRFP shall deny any SCTP re-configuration request (as part of "Receiver-Side Procedures for the RE-CONFIG Chunk", as specified in IETF RFC 6525[51]) in order to prevent possible later usage of SCTP stream reset requests.

5.22.5 CLUE transport between MRFC and MRFP

When the data channel is terminated in the MRFP for telepresence, CLUE messages (e.g. OPTIONS, ADVERTISEMENT, CONFIGURE etc.) are sent from the MRFC to the MRFP to be exchanged via the CLUE data channel between the MRFP and the TP UE.

When the MRFC requests the MRFP to establish a CLUE data channel the MRFC shall include a Notify CLUE Message Received Event information element to request the MRFP a reporting of the received CLUE message.

When a CLUE message needs to be sent to the TP UE the MRFC shall request the MRFP to send the CLUE message.

Upon reception of the request to send CLUE message from the MRFC containing the CLUE message content the MRFP shall send the CLUE message to the TP UE.

When a CLUE message is received from the TP UE, the MRFP shall send the content of the received CLUE message to the MRFC.

5.23 SDP Capability Negotiation (SDPCapNeg)

The SDP Capability Negotiation (SDPCapNeg) as specified in IETF RFC 5939 [53] is adopted as an optional functionality to negotiate capabilities and their associated configurations according to 3GPP TS 24.229 [30].

Upon receipt of an incoming SDP offer containing the attributes of SDP capability negotiation, e.g. offer AVPF and AVP together for the RTP profile negotiation using "a=tcap", "a=pcfg" and "a=acfg" attributes, the MRFC acting as the session responder shall make the decision on support of the alternative configurations based on the MRFC/MRFP capability as provision, and request the MRFP to reserve resources only for the configuration as selected. The MRFC then send the SDP answer indicating the selected configuration in the "a=acfg" attribute for actual configurations.

The MRFC acting as the session initiator may signal SDPCapNeg to the MRFP, e.g. the MRFC wildcards the supporting configurations from the MRFP in order to construct an SDP offer with the alternative configurations via SDPCapNeg attributes.

NOTE: The additional benefit of signalling SDPCapNeg between the MRFC and the MRFP is to check the resource availability for the corresponding configurations and to avoid the further session failure in case of inadequate resources for the configuration changes in the final confirmation. However, due to the extra resources reserved only during the call establishment phase, there is increased risk of call establishment failure.

In case the MRFC decides to request the MRFP to reserve resources for all of those configurations, the MRFC shall:

– use legacy SDP attributes as specified in IETF RFC 4566 [53] to do the mapping of actual and potential configurations with the H.248 ReserveGroup concept; or

– use SDP extensions for SDP capability negotiation as specified in IETF RFC 5939 [53], if supported by the MRFP.

Before using SDP extensions for SDP capability negotiation as specified in IETF RFC 5939 [53] towards the MRFP, the MRFC shall perform the necessary checks (i.e. through auditing or via prior provisioning) to ensure that the MRFP supports the syntax and capabilities requested. For an auditing the procedure in clause 6.1.8.1 is used with the "SDPCapNeg Supported Capabilities" as the object.

When receiving a request from the MRFC with information element "SDPCapNeg configuration" indicating the potential use of multiple configurations, the MRFP shall reserve resources for all of those configurations that it supports and shall send indicate the configurations for which it reserved resources in an "SDPCapNeg configuration" information element in the response. The MRFC shall update the SDP offer with SDPCapNeg configurations in the response from the MRFP and shall forward the SDP offer to the next hop.

On receipt of an SDP answer with SDPCapNeg, the MRFC shall request the MRFP to configure the resources for the selected configuration. If the MRFP previously reserved any temporary resources for configurations that were not selected, the MRFC shall also request the MRFP to release those resources.

5.24 Video Region-of-Interest (ROI)

5.24.1 General

The MRFC and the MRFP may support the video Region-of-Interest (ROI) as defined in 3GPP TS 26.114 [23]. Three modes are specified for supporting ROI, including "Far End Camera Control (FECC)", "Arbitrary ROI" and "Predefined ROI". The MRFC and the MRFP may independently support any of these modes.

For the forthcoming clauses on "Far End Camera Control (FECC)", "Arbitrary ROI" and "Predefined ROI", the MRF procedures allow for only a single ROI-sending client in a given conference to receive and act on ROI requests for a given ROI mode, but they allow for multiple ROI-receiving clients to issue and send ROI requests. Once the MRFC successfully completes the ROI capability negotiation with the ROI-sending client, it offers the corresponding ROI capabilities to other ROI-receiving clients in the conference and instructs the MRFP to signal ROI request(s) to the ROI-sending client based on the ROI requests it receives from the ROI-receiving clients.

5.24.2 "Far End Camera Control" mode

The MRFC and MRFP may support the "Far End Camera Control" mode as specified in 3GPP TS 26.114 [23]. If the MRFC and MRFP support the "Far End Camera Control" mode, the MRFC and MRFP shall apply the procedures in the present clause.

Upon receipt of an SDP offer containing an "m=" line with a media type "application/h224", as defined by IETF RFC 4573 [54] which indicates support for FECC (ITU-T Recommendation H.281 [56]) using ITU-T Recommendation H.224 [55], the MRFC shall determine based on the local policy and the ROI negotiation results on other call legs whether to accept this "FECC" offer. If the "FECC" offer is accepted, the MRFC shall:

– include the "m=" and "a=" lines related to the "application/h224" media types (see the related SDP examples in annex A.4.2e of 3GPP TS 26.114 [23]) in the SDP answer that will be sent within the SIP signalling;

– request the MRFP to provide a separate IP/UDP/RTP transport for the "application/h224" media stream by setting the "m=" line media type to "application" and "RTP/AVP" or "RTP/AVPF" over UDP as transport protocol when reserving the transport resources, and forward transparently RTP/UDP packets (with the transparent (H.224)-PDU); and

– only one of the SDP offers containing "a=sendrecv" or "a=recvonly" capabilities shall be responded by the MRFC with an SDP answer with an indication of "a=sendonly" and other such SDP offers, if accepted, shall be responded by the MRFC with an SDP answer with an indication of "a=recvonly".

– request the MRFP to pass RTP flows from the terminations where the MRFC replied with "a=recvonly" in the SDP answer to the termination where the MRFC replied with "a=sendonly" in the SDP answer.

NOTE 1: There may be one media type "application/h224" "m=" line for each video "m=" line.

NOTE 2: The use of FECC itself is internal to the H.224 frame and is identified by the client ID field of the H.224 packet. The MRFC only indicates the use of IP/UDP/RTP. The use of FECC is signalled via H.224 by a MTSI client.

If the MRFP does not support the FECC feature or the MRFC determines that the "FECC" offer should not be accepted based on the local policy and the ROI negotiation results on other call legs, the MRFC shall send the SDP answer without any "m=" and "a=" lines related to the "application/h224" media types within the SIP signalling.

If the MRFC and MRFP support the FECC feature then before sending an SDP offer, the MRFC shall:

a) determine based on the local policy and the FECC negotiation results on other call legs to offer FECC; and

b) if the MRFC determines to offer FECC:

– the MRFC shall include the "m=" and "a=" lines related to the "application/h224" media types in the SDP offer it sends within the SIP signalling; and

– only one of the SDP offers from the MRFC shall contain "a=sendonly" and remaining SDP offers from the MRFC shall contain "a=recvonly".

– request the MRFP to pass RTP flows from the terminations where the MRFC indicated with "a=recvonly" in the SDP offer to the termination where the MRFC indicated with "a=sendonly" in the SDP offer.

If the MRFP does not support the FECC feature, the MRFC shall send the SDP offer without any FECC related SDP attributes within the SIP signalling.

5.24.3 "Predefined ROI" mode

The MRFC and MRFP may support the "Predefined ROI" mode as specified in 3GPP TS 26.114 [23]. If the MRFC and MRFP support the "Predefined ROI", the MRFC and MRFP shall apply the procedures in the present clause.

Upon receipt of an SDP offer containing the predefined ROI attribute(s) "a=predefined_ROI" defined in 3GPP TS 26.114 [23], the MRFC shall determine based on the local policy and the ROI negotiation results on other call legs whether to accept this "Predefined ROI" offer. If the "Predefined ROI" offer is accepted, the MRFC shall include the accepted set of predefined ROIs in the SDP answer by indicating them using the "a=predefined_ROI" attributes that will be sent within the SIP signalling (see the related SDP examples in annex A.4.2e of 3GPP TS 26.114 [23]). The accepted set of predefined ROIs shall be based on the predefined ROIs offered by the client designated by the MRFC as the ROI-sending client. For the response to the ROI-sending client, the SDP answer from the MRFC shall not contain "a=predefined_ROI" attributes. If the MRFP does not support the Predefined ROI feature or the MRFC determines that the "Predefined ROI" offer should not be accepted based on the local policy and the ROI negotiation results on other call legs, the MRFC shall send the SDP answer without any "a=predefined_ROI" attributes within the SIP signalling.

Upon receipt of an SDP offer containing an "a=rtcp-fb" line with the "Predefined ROI" type expressed by the parameter "3gpp-roi-predefined", as described in 3GPP TS 26.114 [23], the MRFC shall determine based on the local policy and the ROI negotiation results on other call legs whether to accept this "Predefined ROI" offer. If the "Predefined ROI" offer is accepted, the MRFC shall:

– at the termination towards the ROI-sending client, include the "Predefined ROI Sent" information element when seizing resources in the MRFP to indicate to the MRFP that it shall signal RTCP "FB ROI" feedback message(s) related to predefined ROI on that termination and request the MRFP to assign the related resources for the corresponding RTCP control flow to convey pre-defined ROI information;

– at a termination towards an ROI-receiving client, include the "Predefined ROI Received" information element when seizing resources in the MRFP to indicate to the MRFP that it shall accept RTCP "FB ROI" feedback message(s) related to predefined ROI on that termination and request the MRFP to assign the related resources for the corresponding RTCP control flow to convey pre-defined ROI information; and

– include "a=rtcp-fb" lines related to the "3gpp-roi-predefined" parameter in the SDP answer that will be sent within the SIP signalling (see the related SDP examples in annex A.4.2e of 3GPP TS 26.114 [23]); and

NOTE: The RTCP control flow contains multiple RTCP packet types.

If the MRFP does not support the Predefined ROI feature or the MRFC determines that the "Predefined ROI" offer should not be accepted based on the local policy and the ROI negotiation results on other call legs, the MRFC shall send the SDP answer without any "a=rtcp-fb" lines related to the "3gpp-roi-predefined" parameter within the SIP signalling.

Upon receipt of an SDP offer containing "a=extmap" attribute(s), as defined in IETF RFC 5285 [27], and the "a=extmap" attribute(s) contain the pre-defined ROI URN(s) (i.e. the ROI URN for carriage of pre-defined region of interest information in the sent video stream is given by "urn:3gpp:predefined-roi-sent") as defined in 3GPP TS 26.114 [23], then the MRFC shall determine based on the local policy and the ROI negotiation results on other call legs whether to accept this "Predefined ROI" offer. If the "Predefined ROI" offer is accepted, the MRFC shall:

– include the "Extended RTP header for Sent ROI" information element when seizing resources in the MRFP to indicate to the MRFP that it shall allow the RTP header extension for predefined ROI to pass; and

– include "a=extmap" attributes containing the pre-defined ROI URN in the SDP answer that will be sent within the SIP signalling (see the related SDP examples in annex A.4.2e of 3GPP TS 26.114 [23]).

If the MRFP does not support the Predefined ROI feature or the MRFC determines that the "Predefined ROI" offer should not be accepted based on the local policy and the ROI negotiation results on other call legs, the MRFC shall send the SDP answer without any Predefined ROI related "a=extmap" attribute within the SIP signalling.

If the MRFC and MRFP support the Predefined ROI feature then before sending an SDP offer, the MRFC shall:

a) determine based on the local policy and the Predefined ROI negotiation results on other call legs if, and with what configurations to offer Predefined ROI; and

b) if the MRFC determines to offer Predefined ROI:

– at the termination towards the ROI sending client, the MRFC shall include the "Predefined ROI Sent" information element when seizing resources in the MRFP to indicate to the MRFP that it shall signal RTCP "FB ROI" feedback message(s) related to predefined ROI on that termination and request the MRFP to assign the related resources for the corresponding RTCP control flow to convey pre-defined ROI information;

– at a termination towards an ROI receiving client, the MRFC shall include the "Predefined ROI Received" information element when seizing resources in the MRFP to indicate to the MRFP that it shall accept RTCP "FB ROI" feedback message(s) related to predefined ROI on that termination and request the MRFP to assign the related resources for the corresponding RTCP control flow to convey pre-defined ROI information;

– the MRFC shall include "a=rtcp-fb" lines related to the "3gpp-roi-predefined" parameter along with the associated "a=predefined_ROI" attributes in the SDP offer it sends within the SIP signalling;

– the MRFC shall include the offered set of predefined ROIs by indicating them using the "a=predefined_ROI" attributes in the SDP offer it sends within the SIP signalling, where the offered set of predefined ROIs shall be based on the predefined ROIs offered by the client designated by the MRFC as the ROI-sending client.;

– the MRFC shall include the "extended RTP header for Sent ROI" information element for Predefined ROI when seizing resources in the MRFP to indicate the MRFP that it shall allow the RTP header extension for predefined ROI to pass; and

– the MRFC shall include the Predefined ROI related "a=extmap" attribute in the SDP offer it sends within the SIP signalling.

If the MRFP does not support the Predefined ROI feature, the MRFC shall send the SDP offer without any Predefined ROI related SDP attributes within the SIP signalling.

If the MRFP has been instructed to pass on the extended RTP header for predefined ROI as described above then:

– if the MRFP does not apply video transcoding, it shall pass any received RTP header extension for Predefined ROI to succeeding RTP streams; or

– if the MRFP applies video transcoding, it shall keep the predefined ROI information unchanged during the transcoding and copy the received RTP header extension for Predefined ROI to the succeeding outgoing RTP stream(s) after transcoding the associated group of packets.

5.24.4 "Arbitrary ROI" mode

The MRFC and MRFP may support the "Arbitrary ROI" mode as specified in 3GPP TS 26.114 [23]. If the MRFC and MRFP support the "Arbitrary ROI", the MRFC and MRFP shall apply the procedures in the present clause.

Upon receipt of an SDP offer containing an "a=rtcp-fb" line with the " Arbitrary ROI" type expressed by the parameter "3gpp-roi-arbitrary", as described in 3GPP TS 26.114 [23], the MRFC shall determine based on the local policy and the ROI negotiation results on other call legs whether to accept this "Arbitrary ROI" offer. If the "Arbitrary ROI" offer is accepted, the MRFC shall:

– at the termination towards the ROI-sending client, include the "Arbitrary ROI Sent" information element when seizing resources in the MRFP to indicate to the MRFP that it shall signal RTCP "FB ROI" feedback message(s) related to arbitrary ROI on that termination and request the MRFP to assign the related resources for the corresponding RTCP control flow to convey arbitrary ROI information;

– at a termination towards an ROI-receiving client, include the "Arbitrary ROI Received" information element when seizing resources in the MRFP to indicate to the MRFP that it shall accept RTCP "FB ROI" feedback message(s) related to arbitrary ROI on that termination and request the MRFP to assign the related resources for the corresponding RTCP control flow to convey arbitrary ROI information; and

– include "a=rtcp-fb" lines related to the "3gpp-roi-arbitrary" parameter in the SDP answer that will be sent within the SIP signalling (see the related SDP examples in annex A.4.2e of 3GPP TS 26.114 [23]).

NOTE: The RTCP control flow contains multiple RTCP packet types.

If the MRFP does not support the Arbitrary ROI feature or the MRFC determines that the "Arbitrary ROI" offer should not be accepted based on the local policy and the ROI negotiation results on other call legs, the MRFC shall send the SDP answer without any "a=rtcp-fb" lines related to the "3gpp-roi-arbitrary" parameter within the SIP signalling.

Upon receipt of an SDP offer containing "a=extmap" attribute(s), as defined in IETF RFC 5285 [27], and the "a=extmap" attribute(s) contain the arbitrary ROI URN(s) (i.e. the ROI URN for carriage of arbitrary region of interest information in the sent video stream is given by "urn:3gpp:roi-sent") as defined in 3GPP TS 26.114 [23], then the MRFC shall determine based on the local policy and the ROI negotiation results on other call legs whether to accept this "Arbitrary ROI" offer. If the "Arbitrary ROI" offer is accepted, the MRFC shall:

– include the "Extended RTP header for Sent ROI" information element when seizing resources in the MRFP to indicate to the MRFP that it shall allow the RTP header extension for arbitrary ROI to pass; and

– include "a=extmap" attributes containing the arbitrary ROI URN in the SDP answer that will be sent within the SIP signalling (see the related SDP examples in annex A.4.2e of 3GPP TS 26.114 [23]).

If the MRFP does not support the Arbitrary ROI feature or the MRFC determines that the "Arbitrary ROI" offer should not be accepted based on the local policy and the ROI negotiation results on other call legs, the MRFC shall send the SDP answer without any Arbitrary ROI related "a=extmap" attribute within the SIP signalling.

If the MRFC and MRFP support the Arbitrary ROI feature then before sending an SDP offer, the MRFC shall:

a) determine based on the local policy and the Arbitrary ROI negotiation results on other call legs if, and with what configurations to offer Arbitrary ROI; and

b) if the MRFC determines to offer Arbitrary ROI:

– at the termination towards the ROI-sending client, the MRFC shall include the "Arbitrary ROI Sent" information element when seizing resources in the MRFP to indicate to the MRFP that it shall signal RTCP "FB ROI" feedback message(s) related to arbitrary ROI on that termination and request the MRFP to assign the related resources for the corresponding RTCP control flow to convey arbitrary ROI information;

– at a termination towards an ROI-receiving client, the MRFC shall include the "Arbitrary ROI Received" information element when seizing resources in the MRFP to indicate to the MRFP that it shall accept RTCP "FB ROI" feedback message(s) related to arbitrary ROI on that termination and request the MRFP to assign the related resources for the corresponding RTCP control flow to convey arbitrary ROI information;

– the MRFC shall include "a=rtcp-fb" lines related to the "3gpp-roi-arbitrary" parameter in the SDP offer it sends within the SIP signalling;

– the MRFC shall include the "extended RTP header for Sent ROI" information element for Arbitrary ROI when seizing resources in the MRFP to indicate the MRFP that it shall allow the RTP header extension for arbitrary ROI to pass; and

– the MRFC shall include the Arbitrary ROI related "a=extmap" attribute in the SDP offer it sends within the SIP signalling.

If the MRFP does not support the Arbitrary ROI feature, the MRFC shall send the SDP offer without any Arbitrary ROI related SDP attributes within the SIP signalling.

If the MRFP has been instructed to pass on the extended RTP header for arbitrary ROI as described above then:

– if the MRFP does not apply video transcoding, it shall pass any received RTP header extension for Arbitrary ROI to succeeding RTP streams; or

– if the MRFP applies video transcoding, it shall keep the arbitrary ROI information unchanged during the transcoding and copy the received RTP header extension for Arbitrary ROI to the succeeding outgoing RTP stream(s) after transcoding the associated group of packets.

5.25 Rate adaptation for media endpoints

If the MRFC and the MRFP support rate adaptation for media endpoints using the enhanced bandwidth negotiation mechanism defined in 3GPP TS 26.114 [23] the requirements and procedures in the present clause apply.

If the MRFC receives an SDP offer containing the SDP "a=bw-info" attribute(s), defined in clause 19 of 3GPP TS 26.114 [23] the MRFC shall:

– select the payload types (codecs and codec configurations) from the received SDP offer;

– if the received SDP offer contained the SDP "a=bw-info" attribute(s) for the selected codec:

a) construct appropriate SDP "a=bw-info" attribute(s) for the selected codec according to the rules in 3GPP TS 26.114 [23]; and

NOTE 1: The MRFP can modify the related SDP "a=bw-info" attribute(s) according to operator policies as specified in 3GPP TS 26.114 [23].

NOTE 2: The offer/answer negotiation is performed for each "a=bw-info" SDP attribute line, payload type, direction and bandwidth property individually.

b) include the "Additional Bandwidth Properties" information element containing "a=bw-info" SDP attribute(s) in the remote descriptor describing bandwidths that will be used for the selected codec in the sending direction towards the preceding node when requesting the MRFP to reserve resources; and

NOTE 3: The included information corresponds to "a=bw-info" SDP attribute(s) in the sent SDP answer for the "send" or "sendrecv" direction.

– include the selected codec with the corresponding SDP "a=bw-info" attribute(s) in the SDP answer.

If the MRFC sends the SDP offer the MRFC shall include, in accordance with local configuration, for the each offered payload type appropriate bandwidth information in "a=bw-info" SDP attribute lines(s).

If the MRFC then receives the SDP answer with the SDP "a=bw-info" attribute(s) the MRFC shall, when requesting the MRFP to configure resources, include for the selected payload type the "Additional Bandwidth Properties" information element containing the "a=bw-info" SDP attribute(s) providing information for the selected codec in the remote descriptor about bandwidths that will be used for the selected codec in the sending direction towards the succeeding node.

NOTE 4: The included information corresponds to "a=bw-info" SDP attribute(s) in the received SDP answer for the "recv" or "sendrecv" direction.

The MRFP may use the "Additional Bandwidth Properties" information element indicating media bandwidth range for rate adaptation (i.e. to select an appropriate encoding and redundancy) when transcoding media streams.

5.26 RTCP Codec Control Commands and Indications

The MRFC and the MRFP may support signalling of "RTCP Codec Control Commands and Indications", as defined in 3GPP TS 26.114 [23] and IETF RFC 5104 [61].

NOTE 1: 3GPP TS 26.114 [23] specifies support of the following RTCP feedback codec control messages (CCM): "Full Intra Request (FIR)", "Temporary Maximum Media Stream Bit Rate Request (TMMBR)" and "Temporary Maximum Media Stream Bit Rate Notification (TMMBN)".

The RTCP FIR feedback message can be used by the MRFP supporting the Multi-stream Multiparty Conferencing Media Handling feature, as specified in clause 5.11.3, to request the media sender to send a decoder refresh point.

The RTCP TMMBR and TMMBN feedback messages can also be used in reaction to the Explicit Congestion Notification, as specified in clause 5.15.

Usage of the RTCP feedback "CCM" messages is negotiated via SDP offer/answer exchange through an extension (defined in IETF RFC 5104 [78]) of the RTCP feedback capability attribute "a=rtcp-fb" (defined in IETF RFC 4585 [60]).

NOTE 2: The SDP offer/answer negotiation is performed with a separate "a=rtcp-fb" attribute line for each CCM message type.

If the MRFC and the MRFP support the "RTCP Codec Control Commands and Indications" signalling, the MRFC and the MRFP shall apply the procedures in the present clause.

If the MRFC receives from a preceding node an SDP offer containing "a=rtcp-fb" line(s) with a "CCM" parameter and with "fir" and/or "tmmbr" CCM parameters (defined in IETF RFC 5104 [61]) under video "m=" line(s), the MRFC shall:

– when requesting the MRFP to configure resources towards the preceding node, include the "CCM BASE" information element with the "fir" and/or "tmmbr" CCM parameters to indicate that the MRFP shall be prepared to receive and is allowed to send the RTCP CCM "FIR" and/or "TMMBR/TMMBN" feedback messages; and

– include in the SDP answer, that will be sent to its preceding node, the "a=rtcp-fb" line(s) with the "fir" and/or "tmmbr" CCM parameters from the received SDP offer.

If the MRFC sends the SDP offer with video "m=" line(s) the MRFC shall include under the each offered video "m=" line the "a=rtcp-fb" attribute lines with the "CCM" parameter and with the "fir" and "tmmbr" CCM parameters.

If the MRFC then receives the SDP answer with the "a=rtcp-fb" line(s) with the "CCM" parameter and with the "fir" and/or "tmmbr" CCM parameters the MRFC shall, when requesting the MRFP to configure resources, include the "CCM BASE" information element with the "fir" and/or "tmmbr" CCM parameters to indicate that the MRFP shall be prepared to receive and is allowed to send the RTCP CCM "FIR" and/or "TMMBR/TMMBN" feedback messages.

The MRFP shall then assign resources for the requested RTCP control flow, and the MRFP:

– may send the RTCP FIR feedback message to request the media sender to send a decoder refresh point;

– may send the RTCP TMMBR feedback message to request the media sender to limit the maximum bit rate for a media stream to, or below, the provided value; and

NOTE 3: Trigger for sending of the RTCP TMMBR feedback message can be reception of RTP packets marked with ECN-CE, as described in clause 5.15.

– upon reception of the RTCP TMMBR feedback message shall adjust the sent media rate to the requested rate or lower and shall respond by sending the RTCP TMMBN feedback message.

5.27 Delay Budget Information (DBI)

The MRFP and the MRFC supporting Audio or Multimedia Conferencing, as specified in clauses 5.10 and 5.11, may support the "DBI" signalling as defined in 3GPP TS 26.114 [21].

The MRFP supporting Audio or Multimedia Conferencing, as specified in clause 5.10 and 5.11 may use RTCP feedback messages for "DBI" signalling (as defined in 3GPP TS 26.114 [23] clause 7.3.8) to exchange audio and video delay budget information with the conference participants as defined in 3GPP TS 26.114 [23].

Usage of the RTCP feedback messages for "DBI" signalling is negotiated via SDP offer/answer exchange through an extension of the RTCP feedback capability attribute "a=rtcp-fb" as defined in 3GPP TS 26.114 [23].

If the MRFC and the MRFP supports RTCP feedback messages for "DBI" signalling as defined in 3GPP TS 26.114 [23], the MRFC and the MRFP shall apply the procedures in the present clause.

If the MRFC receives from a preceding node an SDP offer containing "a=rtcp-fb" line(s) with a "3gpp-delay-budget" parameter (as defined in 3GPP TS 26.114 [23] clause 6.2.8) under audio "m=" line(s) or video "m=" line(s), the MRFC shall:

– when requesting the MRFP to configure resources towards the preceding node, include the "DBI" information element to indicate that the MRFP shall be prepared to receive and is allowed to send RTCP feedback messages for "DBI" signalling; and

– include in the SDP answer, that will be sent to its preceding node, the "a=rtcp-fb" line(s) with the "3gpp-delay-budget" parameter from the received SDP offer.

If the MRFC sends the SDP offer with audio or video "m=" line(s) the MRFC shall include under each offered audio or video "m=" line the "a=rtcp-fb" attribute line with the "3gpp-delay-budget" parameter.

If the MRFC then receives the SDP answer with the "a=rtcp-fb" line(s) with the "3gpp-delay-budget" parameter the MRFC shall, when requesting the MRFP to configure resources, include the "DBI" information element to indicate that the MRFP shall be prepared to receive and is allowed to send RTCP feedback messages for "DBI" signalling.

The MRFP shall then assign resources for the requested RTCP control flow and the MRFP:

– may send RTCP feedback messages for "DBI" signalling to report the available additional delay budget to the media sender by setting the "query parameter q" to ‘0’ in the feedback control information as defined in 3GPP TS 26.114 [23] clause 7.3.8. The additional delay budget might be useful for the media sender to improve the reliability of its uplink transmissions in order to reduce packet loss.

– may send RTCP feedback messages for "DBI" signalling to request additional delay budget from the media receiver by setting the "query parameter q" to ‘1’ in the feedback control information as defined in 3GPP TS 26.114 [23] clause 7.3.8. The message could be triggerd by the the reception of an RTCP Receiver Report indicating high packet loss.

– upon reception of the RTCP feedback message for "DBI" signalling with the "query parameter q" set to ‘0’ in the feedback control information (as defined in 3GPP TS 26.114 [23] clause 7.3.8), may use the additional delay budget to improve the reliability of its outgoing media stream in order to reduce packet loss observed by the media receiver.

– upon reception of the RTCP feedback message for "DBI" signalling with the "query parameter q" set to ‘1’ in the feedback control information (as defined in 3GPP TS 26.114 [23] clause 7.3.8), may adjust the delay of the outgoing media stream, if possible.

NOTE: How the MRFP adapts the reliability of its outgoing media stream based on the available delay budget and observed packet loss is up to the implementation.