S.5 Media configuration

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

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

S.5.1 General

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 [8] 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 [154] 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" [155] 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 [155].

NOTE 1: The only, currently defined "a=rid" constraint applicable to 3GPP audio codecs is bitrate ("max-br").

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.

NOTE 2: An MSMTSI MRF needs to make a trade-off between minimizing transcoding by use of a common codec and maximizing media quality by use of a preferred codec in the conference, which is described in more detail in clauses 6.17 and 6.13.4 in [152]. The common codec being listed with highest priority means that it will be kept, even if some other simulcast streams need to be rejected or dropped (e.g. due to network resource limitations, see clause S.8). The preferred codec being listed with highest priority similarly means that it will be kept, even if common codec simulcast streams need to be rejected or dropped, which can in turn require transcoding to some conference participants. This applies both across different simulcast streams (";" separator) and for alternatives ("," separator) within a single simulcast stream in the "a=simulcast" line. This choice between prioritizing common or preferred codecs does not impact interoperability and is therefore left for individual MSMTSI MRF implementation.

S.5.2 Main video

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 [81] 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 [154] and [155] 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.

S.5.3 Thumbnail video

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.

S.5.4 Screenshare video

When screenshare video is supported, it shall be indicated as a separate SDP video "m="-line, identified by "a=content:slides" [81] 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.

S.5.5 Audio

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.

S.5.6 BFCP

Use of BFCP (see also clause S.7) is defined in TS 24.147 [147]. BFCP is negotiated with a single "m="-line for BFCP in SDP as specified in [150]. 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 [150].

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.

S.5.7 Compact Concurrent Codec Negotiation and Capabilities

S.5.7.1 General

To establish MMCMH sessions that make the most of all the participating terminals’ codec capabilities without exceeding the concurrent codec capabilities of each participating terminal, the MMCMH session intiator needs to know the concurrent codec capabilities of all the other terminals. MSMTSI terminals can use the concurrent codec capabilities exchange procedures specified in this clause to obtain this information in a compact format. Furthermore, the specified procedures can be used to negotiate, in a compact manner, which concurrent codecs to use for the MMCMH session.

S.5.7.2 The Compact CCC SDP Attribute

The Compact CCC SDP attribute enables MSMTSI terminals to communicate the CCC information in a more compact format. The ABNF definition is as follows:

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

codec is the media subtype name of a codec as defined in the RTP payload format for that codec, e.g. "H264" for H.264 as defined in [25] and "H265" for H.265 as defined in [120], respectively.

codeclist is an ordered list of the different codecs that are supported by the terminal. The codecs should be listed in order of decreasing complexity from left to right for the "," rule to indicate the ability to substitute an instance of a more complex codec with a simpler one.

level, which is optional, specifies the level of the codec, converted and expressed in hexadecimal format, i.e., for H.264 and H.265 the value is equal to level_idc as defined in [25] and level-id as defined in [120], respectively.

profile, which is optional, specifies the profile of the codec, e.g. for H.264 and H.265 the value is equal to profile_idc as defined in [25] and profile-id as defined in [120], both expressed in hexadecimal fomat, respectively. If the profile is included then the level is also included. However, it is allowed to have the level to be present without the profile being present.

rule specifies in a particular CCC profile (ccc-prof) whether the resources used for a concurrent instance of the codec may be used instead by a concurrent instance of the codec listed afterwards, e.g., the next listed codec is less computationally complex and runs on the same processor as the previously listed codec. When the value is "," then an instance of the subsequent codec can used in place of an instance of the previously listed codec. When the value is ";"’ an instance of the subsequent codec cannot be used instead.

num specifies the maximum number of supported concurrent encoders (when the combination follows "ENC") or decoders (when the combination follows "DEC") of the specified codec at the specified level and profile (when present). num specifies the maximum number of instances of the particular codec that can operate concurrently when all the other codecs in the same ccc-prof have their corresponding num of instances operating. The number of instances of num that immediately follows "ENC" and the number of instances of num that immediately follows "DEC" are both the same as the number of instances of codec, and an instance of num is mapped to an instance of codec with the same order in the ordered codeclist.

There can be multiple ccc-prof‘s to indicate support of different configurations of concurrent encoders and decoders, e.g., to indicate that supporting less concurrent encoders enables the terminal to support more concurrent decoders. ccc-prof‘s should not be in conflict with each other, i.e., indicate a different maximum number of instances (num) of a particular codec when the maximum number of instances of all the other codecs in the ccc-prof‘s are the same. If a conflict is detected between ccc-prof‘s, the information from the first ccc-prof among the conflicting ccc-prof‘s is used and all the other conflicting ccc-prof‘s are ignored.

If the terminal has the ability to trim the number of received media streams it actually decodes, it can advertise a num value that is larger than it actually has the concurrent decoding capabilities for.

As the "a=ccc_list" attribute is a compact representation of the media capabilities that are expressed in SDP, using it is not expected to introduce any additional security conditions beyond those identified for SDP. Therefore the security considerations for the attribute are covered by the security considerations for SDP as specified in RFC 4566 [8]. There are no identified interoperability concerns for this atttibute as it is a new attribute and the values used for the codec field are well defined to use values managed by IANA.

S.5.7.3 Using the Compact CCC SDP Attribute for CCC Exchange

The SIP OPTIONS method specified in RFC 3261 is used to query the capabilities of another terminal by asking the conference participant to send a copy of the SDP it would offer.

For example, the SIP OPTIONS request may be made in-advance of a conference call and the SIP OPTIONS response be stored for the queried terminal. Alternatively, immediately before setting up a conference, the conference initiator may query the capabilities of all the terminals it plans to invite for which it does not have the information pre-stored.

In single source multi-unicast (SSMU) topology [152], the MRF sends the SIP OPTIONS request to each of the terminals before setting up the conference. The terminals send the SIP OPTIONS response to the MRF. The MRF can then use this response information to pre-configure and send the SDP Offers to the terminals using simulcast and multiple m- lines for the MSMTSI session. Alternatively, for the case where MSMTSI terminals call in and sends SDP Offers to MRF (instead of MRF calling out), the MRF can still use knowledge from SIP OPTIONS response to adjust its SDP Answer.

In multi-unicast topology, the conference initiator sends the SIP OPTIONS request to each of the conference participants well in-advance of the conference call. Upon receiving the SIP OPTIONS response from the participants, the conference initiator may store the encoding/decoding preferences of the conference participants for setting up the MSMTSI session.

A new content type cccex, is used to request the ccc_list attribute (see S.5.7.4). The SIP OPTIONS response shall contain the text that follows "a=ccc_list:" when using the ccc_list attribute.

SIP OPTIONS SDP examples are given in Clause T.3.4.

S.5.7.4 Using the Compact CCC SDP Attribute for Session Initiation

S.5.7.4.1 General

MSMTSI terminals shall be able to interpret and respond to the ccc_list attribute included in an SDP answer. MSMTSI terminals should include the ccc_list attribute in an SDP offer to reduce the size of the offer when multiple media configurations of concurrent codecs are being offered.

S.5.7.4.2 SDP Offer Rules

When an MSMTSI terminal generates an offer that includes the ccc_list attribute, it shall include only a single instance of the ccc_list attribute, and one or more media configurations which together cover all the possible concurrent codec configurations that the offerer can support. If the included media configuration(s) offer more concurrent codec configurations than the offerer can support, the offering MSMTSI terminal shall use the ccc_list attribute to indicate to the answerer additional restrictions to the media configurations included in the offer. This allows the MSMTSI offerer to include a single media configuration without using MediaCapNeg and requiring much fewer lines of SDP.

When an MSMTSI terminal includes the ccc_list attribute in an SDP offer it shall check whether the ccc_list attribute is included in the SDP answer it receives. If the attribute is included, the offering MSMTSI terminal may store this CCC information about the other terminal for use in future sessions. If multiple instances of the attribute are included in the SDP answer, the offering MSMTSI terminal shall ignore all but the first instance. If the attribute is not included, the offering MSMTSI terminal shall check that it can support the media configuration selected in the SDP answer in the MMCMH session. If the offering MSMTSI can not support the selected media configuration, it shall send a re-INVITE to the answering terminal without including the ccc_list attribute in the new SDP offer.

S.5.7.4.3 SDP Answer Rules

When an answering MSMTSI terminal receives an offer that includes the ccc_list attribute, it shall include exactly one instance of the ccc_list attribute in the SDP answer. If multiple instances of the attribute are received in the offer, the answering MSMTSI terminal shall ignore all but the first instance. The answering MSMTSI terminal may store this CCC information about the offering terminal for use in future sessions.

When an answering MSMTSI terminal includes the ccc_list attribute in an SDP answer, it shall set the attribute to describe the complete concurrent codec capabilities of the answering MSMTSI terminal, independent of what was received in the SDP offer.