An MSMTSI client in the terminal shall be capable of receiving and locally composing at least one main video and one or more video thumbnails. A "thumbnail" video is in this context defined as a receive-only video "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". An MSMTSI client in terminal shall support receiving at least one thumbnail and may also support receiving any number of additional thumbnails, subject to MSMTSI client capability. An MSMTSI MRF shall support sending at least two thumbnails and may support sending any number of additional thumbnails, subject to MSMTSI MRF capability. An MSMTSI client in terminal shall support sending at least one thumbnail-sized simulcast format of the main video, and may support sending also other simulcast formats. An MSMTSI MRF shall support receiving at least one thumbnail-sized simulcast format of the main video, and may support receiving also other simulcast formats.

An MSMTSI client may support sending and receiving screenshare video. The first picture of the screen sharing video an MSMTSI client sends after being granted the screenshare BFCP floor (see clause S.5.6) shall be random accessible, i.e., as if a FIR would have been received.

An MSMTSI client in terminal shall be capable of receiving and may be capable of sending multiple simultaneous audio RTP streams. The number of multiple audio streams received at the MSMTSI client may be different than the number of multiple audio streams sent from the same MSMTSI client. Support for multiple audio streams in the direction from an MSMTSI MRF to an MSMTSI client in the terminal shall be interpreted as originating from different group call participants. An MSMTSI client in terminal shall support local mixing of received audio streams, and may support use of spatial rendering tools, such as local Head-Related Transfer Function (HRTF), to perform audio panning and mixing of the multiple audio streams. Audio panning may enable the rendering device to choose to vary the audio levels of participants by adjusting the mixing gains. Multi-stream audio is not to be confused with multichannel audio where multi-stream audio may include one or more of mono, stereo, or multichannel audio RTP streams originating from different group call participants.

The functional requirements for jitter-buffer management of MSMTSI client in terminal shall meet the same minimum performance requirements per audio stream that are set for MTSI clients (Clause 8).

An MSMTSI client in terminal shall, when connecting to a remote party that included the "isFocus" tag in any of its SIP headers, subscribe to SIP conference events, as described in TS 24.147. The MSMTSI client in terminal shall be able to receive and handle conference event notifications, resulting from the subscription. The MSMTSI client in terminal shall be capable of parsing all conference event information elements, shall be capable of receiving partial conference event information, and shall be capable of presenting conference event information to the user of the MSMTSI client in terminal, either automatically or on explicit user request. The MSMTSI client in terminal shall be capable of presenting at least the values of the conference event information elements indicated in bold below to the user of the MSMTSI client in the terminal, and shall be capable to use the conference event information elements indicated in italics below for endpoint and media identification, as defined by TS 24.147 and RFC 4575 (here also indicating relevant parts of the XML document hierarchy, for information):

• <conference-info>
  • <conference-description>
    • <display-text>
    • <subject>
  • <users>
    • <user>
      • <display-text>
      • <associated-aors>
        • <entry>
          • <uri>
      • <endpoint>
        • <media>
          • <src-id>

Values for other conference event information elements may optionally be made available to the user of the MSMTSI client in the terminal.

An MSMTSI MRF shall include the "isFocus" tag in all of its outgoing SIP headers that support inserting that tag. It shall be capable of handling subscriptions and unsubscriptions for conference event information, as specified in TS 24.147.

An MSMTSI client that receives an SDP offer with "m="-lines that it cannot handle or does not understand shall use regular SDP offer/answer procedures (RFC 4566) to individually reject those unsupported "m="-lines. An MSMTSI client shall not send RTP or RTCP for rejected "m="-lines. An MSMTSI client shall support controlling its maximum sending rate per "m="-line for media related to that "m="-line, as described by clause 6.2.5. A "common codec" is a codec (typically a legacy/older generation codec) that is supported by all the participants in the conference and enables transcoder-free MSMTSI conferencing. If all participants share support for more than a single codec for a certain media type, the codec providing the best media quality for a given bitrate should be chosen by the MSMTSI MRF as the "common codec". A "preferred codec" is a codec (typically a better compression performance, newer generation codec) that is supported by some but not all participants in the conference and enables better media quality. The common codec and preferred codec(s) may be determined by:

1. the codecs that were offered or pre-selected by the conference participant that initiated the conference (ad hoc or pre-scheduled)
2. the codecs supported by other conference participants, e.g., by use of SIP OPTIONS (see clause S.5.7.3).

When setting up individual sessions with the conference participants, the MSMTSI MRF:

1. shall include the common codec in the SDP offer/answer negotiation, and
2. may additionally include the preferred codecs in the SDP offer/answer negotiation to improve conference quality or performance.

To avoid transcoding when multiple codecs of a media type are used in an MSMTSI session,

1. simulcast RFC 8853 shall be negotiated;
2. usage of both preferred and common codecs in the SDP shall be supported;
3. the MSMTSI MRF shall include the preferred codecs in the SDP as being simulcast with a corresponding common codec stream for the same media type; and
4. a participant sending media using a preferred codec shall also simulcast a representation of the same media using the common codec for that media type.

When constructing "a=rid" (RFC 8851) line identification of simulcast formats, MSMTSI clients in terminal and MSMTSI MRF shall use a 1:1 mapping per direction between each rid-id and the corresponding RTP payload type number in the "pt=" parameter on the "a=rid" line. It is optional for MSMTSI clients in terminal and MSMTSI MRF to support constraints parameters for the "a=rid" lines. An MSMTSI client in terminal and MSMTSI MRF shall be capable to ignore any "a=rid" constraints parameters it does not understand and shall correctly negotiate them away in the SDP answer, as specified in RFC 8851. The recommended approach by which the common and preferred codec information is exchanged between the MSMTSI MRF and the MSMTSI terminals is to use the order in which the codecs are listed in the SDP a=simulcast line, which lists simulcast streams in order of decreasing priority. The common codec should be listed first, assuming that the common codec simulcast stream is to be used as far as possible, to avoid transcoding. The preferred codec may instead be listed first if a limited amount of transcoding is considered an acceptable cost for keeping good media quality.

The main video SDP "m="-line shall be the first video "m="-line in an SDP offer from an MSMTSI client, to increase the probability that it is accepted by a non-MSMTSI client. The main video SDP "m="-line shall be identified by an "a=content:main" SDP attribute (RFC 4796) under that "m="-line. The MSMTSI client shall be capable of identifying the main video when the video "m="-line contains "a=content:main", even if this is not the first video "m="-line in the SDP. An MSMTSI client shall be capable of receiving an SDP without any "a=content:main" SDP video attribute, and should then choose main video to be the first suitable video "m="-line that cannot be clearly identified for another purpose (such as for example "a=content:slides", see below). In case of video, where the main video and thumbnail video are being sent from the MSMTSI client to the MSMTSI MRF, use of simulcast shall be indicated in SDP according to RFC 8853 and RFC 8851 in an SDP offer. SDP simulcast negotiation decides which simulcast formats, if any, that are sent between the MSMTSI clients in terminal and the MSMTSI MRF. An MSMTSI client in terminal shall use send direction simulcast in the SDP when negotiating use of simulcast to send main video thumbnail. An MSMTSI MRF shall use receive direction simulcast in the SDP when negotiating use of simulcast towards an MSMTSI client in terminal to receive main video thumbnail. An MSMTSI client in terminal that receives an SDP offer using simulcast from a remote party that is not a conference focus (indicated by the SIP isFocus tag not being present in SIP headers), should disable use of simulcast in the corresponding SDP answer.

Each thumbnail video that the MSMTSI client supports shall be negotiated as a separate SDP video "m="-line, different from the main video "m="-line ("a=content:main") and any screenshare video "m="-line ("a=content:slides"). An MSMTSI client in the terminal shall use receive-only direction for all thumbnail videos in the SDP. An MSMTSI MRF shall use send-only direction for all thumbnail videos in the SDP that are sent towards an MSMTSI client in the terminal. As a specific case of the general SDP "m="-line handling specified by S.5, an MSMTSI client that receives an SDP offer with more thumbnail video "m="-lines than it can support, shall disable the "m="-lines it cannot support (by setting port to 0) in the SDP answer. Which thumbnail "m="-lines to keep and which to reject, in case all cannot be supported, is left for MSMTSI client implementation preference. A thumbnail "m="-line is generally not dedicated to a certain conference participant and the number of "m="-lines for thumbnails therefore need not match the number of conference participants. If RTP stream selective forwarding (see clause S.6) is used for thumbnails by the MSMTSI MRF, though the forwarded participant may change at any point in time, a single thumbnail "m="-line can map to an RTP stream from any one of the participants. The number of thumbnail "m="-lines actually used between an individual MSMTSI client in terminal and an MSMTSI MRF is thus decided by the minimum number of thumbnail "m="-lines in any of their SDPs, irrespective of the MSMTSI client in terminal or the MSMTSI MRF being the entity supporting the fewest thumbnail "m="-lines. Therefore, the number of thumbnail "m="-lines supported by an individual MSMTSI client in terminal does not limit the number of thumbnail "m="-lines used between the MSMTSI MRF and other MSMTSI clients in terminals participating in the same conference. An MSMTSI client in terminal that receives an SDP offer using thumbnails from a remote party that is not a conference focus (indicated by the SIP isFocus tag not being present in SIP headers), should disable thumbnail "m="-lines in the corresponding SDP answer.

When screenshare video is supported, it shall be indicated as a separate SDP video "m="-line, identified by "a=content:slides" (RFC 4796) under that "m="-line. There is no restriction in how the screenshare video "m="-line is ordered in relation to other "m="-lines in the SDP, except that it shall be listed after the main video "m="-line.

The main audio SDP "m="-line shall be the first "m="-line in an SDP offer from an MSMTSI client, to increase the probability that it is accepted by a non-MSMTSI client. Support for multiple, simultaneous audio streams shall be indicated in SDP as separate audio "m="-lines. The number of supported channels in multi-channel audio shall be indicated per audio stream through the SDP "m="-line <encoding parameters>, with the default being a single channel when <encoding parameters> is omitted. There is no restriction in how additional audio "m="-lines are ordered in relation to other "m="-lines in the SDP, except that they shall be listed after the main audio "m="-line.

Use of BFCP (see also clause S.7) is defined in TS 24.147. BFCP is negotiated with a single "m="-line for BFCP in SDP as specified in RFC 4583. If both screenshare video and main video are negotiated, they shall be negotiated to use separate BFCP floor identifications. An MSMTSI client shall be capable of correctly associating SDP "m="-lines with BFCP floors through the SDP answer, as described in RFC 4583. An MSMTSI MRF shall support at least the BFCP floor control server role in SDP offer/answer. An MSMTSI client in terminal shall support the BFCP floor control client role in SDP offer/answer, but may in addition support also the BFCP floor control server role. Which role is taken by which part is decided by BFCP SDP offer/answer.

ccc-list = "a=ccc_list:" codeclist 1*63( "|" ccc-prof )
codeclist = codec [SP config] *63( ";" codec [SP config] )
ccc-prof = "ENC:" num *63( rule num ) ":DEC:" num *63( rule num )
codec = byte-string
  ; byte-string defined in RFC 4566
level = 1*3DIGIT
profile = 1*3DIGIT
config = ( profile SP level ) / level
rule = ";" / ","
num = 1*2DIGIT

An MSMTSI client shall be capable of receiving multiple, separate RTP streams (RFC 3550) related to a single SIP dialog and route them to the correct decoder based on RTP SSRC, RTP Payload Type, and any "a=content" information in the SDP. The number of RTP streams used in each direction and for each media type is limited to what is negotiated by SDP offer/answer for that SIP dialog, allowing the involved MSMTSI clients to express a limit to the number of streams they can handle simultaneously. An MSMTSI client in terminal shall be capable of relating received RTP SSRC and CSRC with information from the conference event information (clause S.4), to enable indicating the identity of the RTP stream source. If a received RTP SSRC has no match in the conference event information, and if RTP CSRC is present, CSRC shall also be matched against conference event information. It is left up to MSMTSI client implementation what RTP stream source identification to use if neither SSRC nor CSRC can be matched against conference event information.

An MSMTSI client in the terminal shall, as an MTSI client in the terminal, be capable to receive RTCP feedback (FIR, PLI, TMMBR, etc) (RFC 4585) (RFC 5104) and respond accordingly, but shall also be capable to identify which sent RTP stream (SSRC) the RTCP feedback targets and direct it to the appropriate encoder. An MSMTSI client shall support RTP-level pause and resume functionality according to RFC 7728 for all of its RTP streams, with the exception of the main audio stream from an MSMTSI client in terminal towards an MSMTSI MRF, which is not required to (but may) support RTP-level pause and resume functionality. An MSMTSI client shall be capable of restricting its use of RTP-level pause and resume functionality according to received pause/resume config parameter information in SDP, including not using it at all if that is the negotiation outcome. An MSMTSI client in terminal shall support RTP-level pause and resume functionality at least corresponding to config=3, and should support full RTP-level pause and resume functionality corresponding to config=1. An MSMTSI MRF shall support RTP-level pause and resume functionality at least corresponding to config=2, and should support full RTP-level pause and resume functionality corresponding to config=1.

When a conference includes a large number of terminals or participants, the size of the SDP Offer listing the concurrent codec capabilities (CCC) using multiple m= lines can increase considerably. To reduce the size of the SDP offer when a conference includes a large number of participants, RTP-level selective forwarding by the MSMTSI MRF shall support RTP pause/suspend, reuse, replace, and resume actions. This RTP-level "suspend, resuse, replace, and resume" action is described using an example in clause 6.13.4.2 of TR 26.980. In the SDP Offer the MSMTSI MRF may use fewer downlink m= lines, corresponding to dynamically selected streams even though there are large number of participants or terminals in the MSMTSI session. To support RTP stream selective forwarding when some participants in a conference supports both the "common" and one or more "preferred" codecs while other participants support only the "common" codec, certain conditions need to be fulfilled for MSMTSI clients both in the terminal and in MSMTSI MRF. This is described below. The MSMTSI MRF should construct the SDP Offer such that the downlink RTP stream from one participant fits sufficiently well with the capabilities of another participant such that the same downlink m= line can be used for RTP stream selective forwarding. For this, the MSMTSI MRF should pre-anlayze the CCCEx (e.g., based on SIP OPTIONS) and construct sub-groups of participants that can share a given m= line with a given set of "preferred" and "common" codecs in the simulcast. An MSMTSI client in terminal that supports both "common" and "preferred" codecs for a media type shall support concurrent encoding, sending simulcast (RFC 8851), and concurrent decoding, with more than a single one codec for every sending media source ("m=" line) of that media type. An MSMTSI MRF that supports both "common" and "preferred" codecs for a media type shall support receving simulcast with more than a single codec for every received media source ("m=" line) of that media type. An MSMTSI client in terminal that supports both "common" and "preferred" codecs for a media type shall be capable to receive media using any one of those codecs, even if the used codec (RTP payload type) is changing from one RTP packet to the next, for all received media sources ("m=" lines) of that media type. This capability to receive RTP payload type changing from one RTP packet to the next is indicated by accepting payload types with both "common" and "preferred" codecs from the SDP offer in the SDP answer. This way, no SDP re-negotiation is needed to change codec between the ones included in the answer. This ability to support RTP payload type changes every RTP packet is an essential part of the receiving end of a codec simulcast scenario, and shall be explicitly indicated in SDP by including "a=simulcast" with the supported codecs as simulcast format alternatives, even if it means that only a single simulcast stream with alternatives is listed in simulcast receive direction. An MSMTSI client in the terminal that negotiated receiving simulcast with different codecs and that receives a set of such simulcast streams, can dynamically choose which simulcast stream to decode and should use the best quality simulcast stream that is available. An MSMTSI MRF that negotiated sending simulcast with a set of different codecs and that needs to forward streams using those codecs, may change RTP payload type within that set in its sent stream at any point in time, as needed to support the communication scenario and forwarding strategy used by the MSMTSI MRF. The MSMTSI MRF should take action to allow decoder memories to clear when replacing one RTP stream with another RTP stream during switching, to avoid media distortion in the receiving MSMTSI client in the terminal. To enable this, it is currently necessary for the MSMTSI MRF to know the RTP payload format of the used codecs, even if no transcoding is needed. The MSMTSI MRF should therefore, before suspending forwarding of RTP stream A and replacing it by instead forwarding RTP stream B:

• For speech
  • Replace the content of a few RTP packet payloads from RTP stream A with a few silence indication (SID) or discontinuous transmission (DTX) frames for the used codec
• For video
  • Take assistance from the sender of RTP stream B, asking for a decoder refresh point by sending RTCP FIR to that RTP stream B sender
  • Continue forwarding RTP stream A while monitoring RTP stream B for decoder refresh points
  • From the point where a decoder refresh point is received in RTP stream A, suspend forwarding of RTP stream A and replace it by forwarding RTP stream B

BFCP with TCP transport according to RFC 4582 RFC 4583 shall be supported. An MSMTSI client in terminal shall be capable of indicating to the user when it is granted a floor, when a floor request is rejected, and when a floor grant is revoked. The details of such indication are left for MSMTSI client implementation. If the MSMTSI client in terminal supports floor control of more than a single video, it shall be able to make such indications separately for each supported floor. An MSMTSI client may support functionality for moderated BFCP floor handling, involving a floor chair. An MSMTSI MRF should silently ignore and discard any received video that is currently under active floor control, but where another MSMTSI or MTSI client than the one sending such received stream currently owns the floor.

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

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

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

If MTSI clients participate in the group video call, not supporting BFCP for the main video but having successfully negotiated use of DTMF with the MSMTSI MRF according to Annex G, the MSMTSI MRF may act as a signalling gateway between DTMF and BFCP main video floor control. It is then assumed that the MSMTSI MRF is configured with a DTMF sequence that can be used to request and release that BFCP floor, and that this DTMF sequence is somehow communicated to the MTSI client, but the details of that are out of scope for this specification. If such MTSI client uses the designated DTMF sequence to request the main video floor, it shall be treated in the MSMTSI MRF as equivalent to receiving a BFCP request for the main video floor. Lacking other possibilities to indicate main video floor grant status back to such DTMF-requesting MTSI client, the MSMTSI MRF should send its main video back to it as long as it owns the main video floor. When the MTSI client owning the main video floor uses the DTMF sequence to release the main video floor, it shall be treated in the MSMTSI MRF as equivalent to receiving a BFCP release for the main video floor.