6 Media configuration

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

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

6.1 General

MTSI uses SIP, SDP and SDPCapNeg for media negotiation and configuration. General SIP signalling and session setup for IMS are defined in TS 24.229 [7], whereas this clause specifies SDP and SDPCapNeg usage and media handling specifically for MTSI, including offer/answer considerations in the capability negotiation. The MTSI client in the terminal may use the OMA-DM solution specified in Clause 15 for enhancing SDP negotiation and resource reservation process.

The support for ECN [83] in E-UTRAN is specified in [85]. The support for ECN in UTRA/HSPA is specified in [89]. The support of ECN in NR is specified in [164]. MTSI may use Explicit Congestion Notification (ECN) to perform rate adaptation for speech and video. When the MTSI client in terminal supports, and the session allows, adapting the media encoding at multiple bit rates and the radio access bearer technology is known to the MTSI client to be E-UTRAN or UTRA/HSPA, the MTSI client may negotiate the use of ECN [83] to perform ECN triggered media bit-rate adaptation. An MTSI MGW supporting ECN supports ECN in the same way as the MTSI client in terminal as described in clauses 12.3.3 and 12.7.3.

The support of ECN is optional for both MTSI client in terminal and MTSI MGW.

It is assumed that the network properly handles ECN-marked packets as described in [84] end-to-end between the MTSI clients in terminals.

An MTSI MGW can be used for inter-working with:

– a client that does not use ECN;

– a client that supports ECN in different way than what is specified for MTSI clients;

– a CS network;

– a network which does not handle ECN-marked packets properly.

In such cases, the ECN protocol, as specified for MTSI clients, is terminated in the MTSI MGW.

6.2 Session setup procedures

6.2.1 General

The session setup for RTP transported media shall determine for each media: IP address(es), RTP profile, UDP port number(s); codec(s); RTP Payload Type number(s), RTP Payload Format(s). The session setup may also determine: ECN usage and any additional session parameters.

The session setup for UDP transported media without RTP shall determine: IP address(es), UDP port number(s) and additional session parameters.

The session setup for data channel (SCTP over DTLS over UDP transported) media shall determine for each media: IP address(es), UDP port number(s), SCTP port number(s), DTLS server/client role(s), DTLS ID(s), DTLS certificate fingerprint(s), and ICE-related information for data channel media as described in clause 6.2.10. The session setup may also determine use of ICE Lite for data channel media and may determine additional session parameters.

The session setup for RTP and data channel transported media shall, when the port number is not set to zero, determine the maximum bandwidth that is allowed in the session, see also clause 6.2.5. The maximum bandwidth for the receiving direction is specified with the "b=AS" bandwidth modifier. Additional requirements and/or recommendations on the bandwidth negotiation are found in clause 6.2.2.1 for speech, in clause 6.2.3.2 for video, and in clause 6.2.10 for data channel.

An MTSI client shall offer at least one RTP profile for each RTP media stream. Multiple RTP profiles may be offered using SDPCapNeg as described in Clause 6.2.1a. For voice and real-time text, the first SDP offer shall include at least the AVP profile. For video, the first SDP offer for a media type shall include at least the AVPF profile. Subsequent SDP offers may include only other RTP profiles if it is known from a preceding offer that this RTP profile is supported by the answerer. The MTSI client shall be capable of receiving an SDP offer containing both AVP and AVPF offers in order to support interworking.

The configuration of ECN for media transported with RTP is described in clause 6.2.2 for speech and in clause 6.2.3.2 for video. The negotiation of ECN at session setup is described in [84]. The adaptation response to congestion events is described in clause 10.

6.2.1a RTP profile negotiation

6.2.1a.1 General

MTSI clients should support SDPCapNeg to be able to negotiate RTP profiles for all media types where AVPF is supported. MTSI clients supporting SDPCapNeg shall support the complete SDPCapNeg framework.

SDPCapNeg is described in [69]. This clause only describes the SDPCapNeg attributes that are directly applicable for the RTP profile negotiation, i.e. the tcap, pcfg and acfg attributes. TS 24.229 [7] may outline further requirements needed for supporting SDPCapNeg in SDP messages.

NOTE: This clause describes only how to use the SDPCapNeg framework for RTP profile negotiation using the tcap, pcfg and acfg attributes. Implementers may therefore (incorrectly) assume that it is sufficient to implement only those specific parts of the framework that are needed for RTP profile negotiation. Doing so would however not be future proof since future versions may use other parts of the framework and there are currently no mechanisms for declaring that only a subset of the framework is supported. Hence, MTSI clients are required to support the complete framework.

6.2.1a.2 Using SDPCapNeg in SDP offer

For voice and real-time text, SDPCapNeg shall be used when offering AVPF the first time for a new media type in the session since the support for AVPF in the answering client is not known at this stage. For video, an MTSI client shall either offer AVPF and AVP together using SDPCapNeg, or the MTSI client shall offer only AVPF without using SDPCapNeg. If an MTSI client has offered only AVPF for video, and then receives as response either an SDP answer where the video media component has been rejected, or an SIP 488 or 606 failure response with an SDP body indicating that only AVP is supported for video media, the MTSI client should send a new SDP offer with AVP as transport for video. Subsequent SDP offers, in a re-INVITE or UPDATE, may offer AVPF without SDPCapNeg if it is known from an earlier re-INVITE or UPDATE that the answering client supports this RTP profile. If the offer includes only AVP then SDPCapNeg does not need to be used, which can occur for: text; speech if RTCP is not used; and in re-INVITEs or UPDATEs where the RTP profile has already been negotiated for the session in a preceding INVITE or UPDATE.

When offering AVP and AVPF using SDPCapNeg, the MTSI client shall offer AVP on the media (m=) line and shall offer AVPF using SDPCapNeg mechanisms. The SDPCapNeg mechanisms are used as follows:

– The support for AVPF is indicated in an attribute (a=) line using the transport capability attribute ‘tcap’. AVPF shall be preferred over AVP.

– At least one configuration using AVPF shall be listed using the attribute for potential configurations ‘pcfg’.

6.2.1a.3 Answering to an SDP offer using SDPCapNeg

An invited MTSI client should accept using AVPF whenever supported. If AVPF is to be used in the session then the MTSI client:

– Shall select one configuration out of the potential configurations defined in the SDP offer for using AVPF.

– Indicate in the media (m=) line of the SDP answer that the profile to use is AVPF.

– Indicate the selected configuration for using AVPF in the attribute for actual configurations ‘acfg’.

If AVP is to be used then the MTSI shall not indicate any SDPCapNeg attributes for using AVPF in the SDP answer.

6.2.2 Speech

6.2.2.1 General

For AMR or AMR-WB encoded media, the session setup shall determine the applicable bandwidth(s) as defined in clause 6.2.5, what RTP profile to use; if all codec modes can be used or if the operation needs to be restricted to a subset; if the bandwidth-efficient payload format can be used or if the octet-aligned payload format must be used; if codec mode changes shall be restricted to be aligned to only every other frame border or if codec mode changes can occur at any frame border; if codec mode changes must be restricted to only neighbouring modes within the negotiated codec mode set or if codec mode changes can be performed to any mode within the codec mode set; the number of speech frames that should be encapsulated in each RTP packet and the maximum number of speech frames that may be encapsulated in each RTP packet. For EVS encoded media, the session setup shall determine the RTP profile to use in the session.

If the session setup negotiation concludes that multiple configuration variants are possible in the session then the default operation should be used as far as the agreed parameters allow, see clause 7.5.2.1. It should be noted that the default configurations are slightly different for different access types.

An MTSI client offering a speech media session for narrow-band speech and/or wide-band speech should generate an SDP offer according to the examples in Annexes A.1 to A.3. An MTSI client offering EVS should generate an SDP offer according to the examples in Annex A.14.

An MTSI client in terminal supporting EVS should support the RTCP-APP signalling for speech adaptation defined clause 10.2.1, and shall support the RTCP-APP signalling when the MTSI client in terminal supports adaptation for call cases where the RTP-based CMR cannot be used.

NOTE 1: Examples of call cases where the RTP-based CMR cannot be used are: when the RTP-based CMR is disabled; or for uni-directional media (sendonly or recvonly).

Some of the request messages are generic for all speech codecs while other request messages are codec-specific. Request messages that can be used in a session are negotiated in SDP, see clause 10.2.3.

An MTSI client shall at least offer AVP for speech media streams. An MTSI client should also offer AVPF for speech media streams. An MTSI client shall offer AVPF for speech media streams when offering to use RTCP-APP signalling. RTP profile negotiation shall be done as described in clause 6.2.1a. When AVPF is offered then the RTCP bandwidth shall be greater than zero.

If an MTSI client in terminal offers to use ECN for speech in RTP streams then the MTSI client in terminal shall offer ECN Capable Transport as defined below. If an MTSI client in terminal accepts an offer for ECN for speech then the MTSI client in terminal shall declare ECN Capable Transport in the SDP answer as defined below. The SDP negotiation of ECN Capable Transport is described in [84].

ECN shall not be used when the codec negotiation concludes that only fixed-rate operation is used.

An MTSI client may support multiple codecs where ECN-triggered adaptation is supported only for some of the codecs. An SDP offer for ECN may therefore include multiple codecs where ECN-triggered adaptation is supported only for some of the codecs. An MTSI client receiving an SDP offer including multiple codecs and an offer for ECN should first select which codec to accept and then accept or reject the offer for ECN depending on whether ECN-triggered adaptation is supported for that codec or not. An MTSI client receiving an SDP answer accepting ECN for a codec where ECN-triggered adaptation is not supported should re-negotiate the session to disable ECN.

NOTE 2: ECN-triggered adaptation is currently undefined for EVS. This does not prevent ECN-triggered adaptation from being negotiated and used for AMR or AMR-WB.

The use of ECN for a speech stream in RTP is negotiated with the ‘ecn-capable-rtp’ SDP attribute, [84]. ECN is enabled when both clients agree to use ECN as configured below. An MTSI client in terminal using ECN shall therefore also include the following parameters and parameter values for the ECN attribute:

– ‘leap’, to indicate that the leap-of-faith initiation method shall be used;

– ‘ect=0’, to indicate that ECT(0) shall be set for every packet.

An MTSI client offering ECN for speech may indicate support of the RTCP AVPF ECN feedback messages [84] using "rtcp-fb" attributes with the "nack" feedback parameter and the "ecn" feedback parameter value. An MTSI client offering ECN for speech may indicate support for RTCP XR ECN summary reports [84] using the "rtcp-xr" SDP attribute [88] and the "ecn-sum" parameter.

An MTSI client receiving an offer for ECN for speech without an indication of support of RTCP AVPF ECN feedback messages [84] within an "rtcp-fb" attribute should accept the offer if it supports ECN.

An MTSI client receiving an offer for ECN for speech with an indication of support of the RTCP AVPF ECN feedback message [84] should also accept the offer and may indicate support of the RTCP AVPF ECN feedback messages [84] in the answer.

An MTSI client accepting ECN for speech in an answer may indicate support for RTCP XR ECN summary reports in the answer using the "rtcp-xr" SDP attribute [88] and the "ecn-sum" parameter.

The use of ECN is disabled when a client sends an SDP without the ‘ecn-capable-rtp’ SDP attribute.

An MTSI client may initiate a session re-negotiation to disable ECN to resolve ECN-related error cases. An ECN-related error case may, for example, be detecting non-ECT in the received packets when ECT(0) was expected or detecting a very high packet loss rate when ECN is used.

SDP examples for offering and accepting ECT are shown in Annex A.12.

Session setup for sessions including speech and DTMF events is described in Annex G.

6.2.2.2 Generating SDP offers

When speech is offered, an MTSI client in terminal sending a first SDP offer in the initial offer-answer negotiation shall include at least one RTP payload type for AMR-NB according to RFC4867 [28] and the MTSI client in terminal shall support and offer a configuration, where the MTSI client in terminal includes the parameter settings as defined in Table 6.1. When EVS-NB is also offered, the MTSI client in terminal shall support and offer a configuration, where the MTSI client in terminal includes the parameter settings for EVS (both EVS Primary and AMR-WB IO modes) as defined in Table 6.2a.

If wideband speech is also offered, then the SDP offer shall also include at least one RTP payload type for AMR-WB according to RFC4867 [28] and the MTSI client in terminal shall support and offer a configuration, where the MTSI client in terminal includes the parameter settings as defined in Table 6.1. When EVS-WB is also offered, the MTSI client in terminal shall support and offer a configuration, where the MTSI client in terminal includes the parameter settings for EVS (both Primary and AMR-WB IO modes) as defined in Table 6.2a. AMR-WB and EVS (including the EVS AMR-WB IO mode) are thus offered using different RTP payload types.

If super-wideband speech is also offered, the SDP offer shall include at least one RTP payload type for EVS and the MTSI client in terminal shall support a configuration where the MTSI client in terminal includes the parameter settings as defined in Table 6.2a.

If fullband speech is also offered, the SDP offer shall include at least one RTP payload type for EVS and the MTSI client in terminal shall support a configuration where the MTSI client in terminal includes the parameter settings as defined in Table 6.2a.

When EVS is offered, the RTP payload type for EVS shall also use parameters for EVS AMR-WB IO mode as defined in Table 6.2a, except for the ‘ecn-capable-rtp’ and ‘leap ect’ parameters. AMR-WB and EVS (including the EVS AMR-WB IO mode) are thus offered using different RTP payload types.

NOTE 1: RFC4867 can also be used for EVS AMR-WB IO when EVS is supported. This may happen after SRVCC when the EVS payload format is used between the ATGW and the MTSI client in terminal while RFC4867 is used between the CS-MGW and the ATGW.

NOTE 2: ECN-triggered adaptation is currently undefined for EVS. This does not prevent ECN-triggered adaptation from being negotiated and used for AMR or AMR-WB.

NOTE 3: When EVS is offered, the audio bandwidths may be different for different directions for the EVS Primary mode, even for ‘sendrecv’ media.

Clause 5.2.1.6 describes the preference order for how different configurations should be ordered in the list of payload type numbers that is given on the m= line.

Table 6.1: SDP parameters for AMR-NB or AMR-WB, when the MTSI client in terminal offers the bandwidth-efficient payload format

Parameter	Usage
octet-align	Shall not be included
mode-set	Shall not be included
mode-change-period	Shall not be included
mode-change-capability	Shall be set to 2
mode-change-neighbor	Shall not be included
maxptime	Shall be set to 240, see also Table 7.1
crc	Shall not be included
robust-sorting	Shall not be included
interleaving	Shall not be included
ptime	Shall be set according to Table 7.1
channels	Shall either be set to 1 or be omitted
max-red	Shall be included and shall be set to 220 or less
ecn-capable-rtp: leap ect=0	Shall be included if offering to use ECN and if the session setup allows for bit-rate adaptation

Table 6.2: SDP parameters for AMR-NB or AMR-WB, when the MTSI client in terminal offers the octet-aligned payload format

Parameter	Usage
octet-align	Shall be set to 1
mode-set	Shall not be included
mode-change-period	Shall not be included
mode-change-capability	Shall be set to 2
mode-change-neighbor	Shall not be included
maxptime	Shall be set to 240, see also Table 7.1
crc	Shall not be included
robust-sorting	Shall not be included
interleaving	Shall not be included
ptime	Shall be set according to Table 7.1
channels	Shall either be set to 1 or be omitted
max-red	Shall be included and shall be set to 220 or less
ecn-capable-rtp: leap ect=0	Shall be included if offering to use ECN and if the session setup allows for bit-rate adaptation

Table 6.2a: SDP parameters for EVS (both Primary and AMR-WB IO modes, when the MTSI client in terminal offers EVS

Parameter	Usage
ptime	Shall be set according to Table 7.1
maxptime	Shall be set to 240, see also Table 7.1
evs-mode-switch	MTSI client in terminal shall not include evs-mode-switch in the initial SDP offer.
hf-only	The SDP offer-answer considerations in TS 26.445 [125] apply.
dtx	MTSI client in terminal shall not include dtx in the initial SDP offer.
dtx-recv	MTSI client in terminal shall not include dtx-recv.
max-red	Shall be included and shall be set to 220 or less.
channels	The SDP offer-answer considerations in TS 26.445 [125] apply.
cmr	The SDP offer-answer considerations in TS 26.445 [125] apply.
br	An MTSI client in terminal supporting the EVS codec is required to support the entire bit-rate range but may offer a smaller bit-rate range or even a single bit-rate.
br-send	The SDP offer-answer considerations in TS 26.445 [125] apply.
br-recv	The SDP offer-answer considerations in TS 26.445 [125] apply.
bw	The SDP offer-answer considerations in TS 26.445 [125] apply.
bw-send	The SDP offer-answer considerations in TS 26.445 [125] apply.
bw-recv	The SDP offer-answer considerations in TS 26.445 [125] apply.
ch-send	The SDP offer-answer considerations in TS 26.445 [125] apply.
ch-recv	The SDP offer-answer considerations in TS 26.445 [125] apply.

ch-aw-recv	The SDP offer-answer considerations in TS 26.445 [125] apply.
mode-set	Shall not be included
mode-change-period	Shall not be included
mode-change-capability	The SDP offer-answer considerations in TS 26.445 [125] apply.
mode-change-neighbor	Shall not be included

When the channels parameter is omitted then this means that one channel is being offered.

The mode-set parameter is omitted, allowing maximum freedom for the visited network.

The mode-change-capability parameter is included and set to 2 for AMR-NB and AMR-WB, to support potential interworking with 2G radio access (GERAN). For EVS AMR-WB IO it is not required to include the mode-change-capability parameter.

An example of an SDP offer for AMR-NB is shown in Table A.1.1. An example of an SDP offer for both AMR-NB and AMR-WB is shown in Table A.1.2. An example of SDP offer for AMR-NB, AMR-WB, and EVS is shown in Table A.14.1.

An SDP example for offering and accepting a dual-mono session for EVS is shown in Annex A.14.1 and A.14.3.

An MTSI client in terminal may divide the offer-answer negotiation into several phases and offer different configurations in different SDP offers. If this is done then the first SDP offer in the initial offer-answer negotiation shall include the most preferable configurations. For AMR-NB, this means that the first SDP offer in the initial offer-answer negotiation shall include at least one RTP payload type for AMR-NB with the parameters as defined in Table 6.1. If wideband speech is offered then the first SDP offer in the initial offer-answer negotiation shall include also at least one RTP payload type for AMR-WB with the parameters as defined in Table 6.1. This also means that offers for octet-aligned payload format do not need to be included in the first SDP offer. If super-wideband or fullband speech is offered, the first SDP offer in the initial offer-answer negotiation shall include at least one RTP payload type for EVS with the parameters as defined in [125]. One example of dividing the offer-answer negotiation into two phases, and the corresponding SDP offers, is shown in clause A.1.1.2.2.

NOTE 4: Dividing the offer-answer negotiation into several phases may lead to never offering the less preferred configurations, if the other end-point accepts to use at least one of the configurations offered in the initial SDP offer.

If the speech media is re-negotiated during the session then the knowledge from earlier offer-answer negotiations should be used in order to shorten the session re-negotiation time. I.e., failed offer-answer transactions shall not be repeated.

6.2.2.3 Generating SDP answer

An MTSI client in terminal must understand all the payload format options that are defined in RFC 4867 [28], and in [125]. It does not have to support operating according to all these options but must be capable to properly accepting or rejecting all options.

The SDP answer depends on many factors, for example:

– what is included in the SDP offer and in what preference order that is defined. The SDP offer will probably be different if it is generated by another MTSI client in terminal, by an MTSI MGW, a TISPAN client or some other VoIP client that does not follow this specification;

– if terminal and/or network resources are available; and:

– if there are other configurations, for example defined with OMA-DM, that mandate, recommend or prevent some configurations.

Table 6.3 describes requirements and recommendations for handling of the AMR payload format parameters and for how to generate the SDP answer.

NOTE 1: An MTSI client in terminal may support more features than what is required by this specification, e.g. crc, robust sorting and interleaving. Table 6.3 describes the handling of the AMR payload format parameters when the MTSI client implementation supports only those features that are required by this specification. Tables 6.3a-6.3c describe the handling of the EVS payload format parameters.

Table 6.3: Handling of the AMR-NB and AMR-WB SDP parameters in the received SDP offer and in the SDP answer

Parameter in the received SDP offer	Comments	Handling
Codec	Wide-band speech is preferable over narrow-band speech	If both AMR-WB and AMR-NB are offered and if AMR-WB is supported by the answering MTSI client in terminal then it shall select to use the AMR-WB codec and include this codec in the SDP answer, unless another preference order is indicated in the SDP offer. If the MTSI client in terminal only supports AMR-NB then this codec shall be selected to be used and shall be included in the SDP answer. The SDP answer shall only include one RTP Payload Type for speech, see NOTE 1.
octet-align	Both the bandwidth-efficient and the octet-aligned payload formats are supported by the MTSI client in terminal. MTSI MGWs for GERAN or UTRAN are likely to either not include the octet-align parameter or to offer octet-align=0. The bandwidth-efficient payload format is preferable over the octet-aligned payload format.	The offer shall not be rejected purely based on the offered payload format variant. If both bandwidth-efficient and octet-aligned are included in the received SDP offer then the MTSI client in terminal shall select the bandwidth-efficient payload format and include it in the configuration in the SDP answer.
mode-set	The MTSI client in terminal can interoperate properly with whatever mode-set the other end-point offers or if no mode-set is offered. The possibilities to use the higher bit rate codec modes also depend on the offered bandwidth. MTSI MGWs for GERAN or UTRAN inter-working are likely to include the mode-set in the offer if in case the intention is to use TFO or TrFO. Mode sets that give more adaptation possibilities are preferable over mode-sets with fewer or no adaptation possibilities. An MTSI client in terminal may be configured with a preferred mode set. Otherwise, the preferred mode-set for AMR-NB is {12.2, 7.4, 5.9, 4.75} and for AMR-WB it is {12.65, 8.85 and 6.60}.	The offer shall not be rejected purely based on the offered mode-set. If only one mode-set is offered then the MTSI client in terminal shall select to use this and include the same mode-set in the SDP answer. If several different payload types for the same codec with different mode-sets (possibly including one or more payload type without mode set) are included in the received SDP offer, then the MTSI client in terminal should select in the first hand the mode-set that provides the largest degrees of freedom for codec mode adaptation and in the second hand the mode-set that is closest to the preferred mode sets. If only a payload type without mode-set has been offered, or if an MTSI client in terminal selects a payload type without mode-set from among the offered ones, and the MTSI client in terminal intends to use only some modes (e.g. one of the preferred mode sets defined at left), then the MTSI client in terminal should include these modes as the mode-set. There are also dependencies between the mode-set and the SDP b=AS bandwidth parameter; see Clause 6.2.5.2.
mode-change-period	The MTSI client in terminal can interoperate properly with whatever mode-change-period the other end-point offers. MTSI MGWs for GERAN or UTRAN inter-working are likely to include mode-change-period=2 in the offer if in case the intention is to use TFO or TrFO.	The offer shall not be rejected purely based on the offered mode-change-period. If the received SDP offer defines mode-change-period=2 then this information shall be used to determine the mode changes for AMR-NB or AMR-WB encoded media that the MTSI client in terminal sends. The MTSI client in terminal should not include the mode-change-period parameter in the SDP answer since it has no corresponding limitations.
mode-change-capability	The MTSI client in terminal can interoperate with whatever capabilities the other end-point declares.	The offer shall not be rejected purely based on the offered mode-change-capability. The mode-change-capability information should be used to determine a proper value, or prevent using an improper value, for mode-change-period in the SDP answer, see above. If the offer includes mode-change-capability=1, then the MTSI client in terminal shall not offer mode-change-period=2 in the answer. The MTSI client in terminal shall include mode-change-capability=2 in the SDP answer since it is required to support restricting mode changes to every other frame.
mode-change-neighbor	The MTSI client in terminal can interoperate with whatever limitations the other end-point offers.	The offer shall not be rejected purely based on the offered mode-change-neighbor. The MTSI client in terminal shall use this information to determine how mode changes can be performed for AMR-NB or AMR-WB encoded media that the MTSI client in terminal sends. The MTSI client in terminal shall not include the mode-change-neighbor parameter in the SDP answer since it has no corresponding limitations.
maxptime	The MTSI client in terminal can interoperate with whatever value that is offered. The MTSI client in terminal may also use this information to determine a suitable value for max-red in the SDP answer.	The offer shall not be rejected purely based on the offered maxptime. The MTSI client in terminal shall use this information to control the packetization when sending RTP packets to the other end-point, see also clause 7.4.2. The maxptime parameter shall be included in the SDP answer and shall be an integer multiple of 20. If the received SDP offer includes both the max-red and ptime parameter then the MTSI client in terminal may choose to use this information to define a suitable value for maxptime in the SDP answer, see NOTE 2. The MTSI client in terminal may also choose to set the maxptime value to 240, regardless of the ptime and/or max-red parameters in the SDP offer. The maxptime value in the SDP answer shall not be smaller than ptime value in the SDP answer. The maxptime value should be selected to give at least some room for adaptation.
crc	The MTSI client in terminal is not required to support this option.	The MTSI client in terminal may have to reject offered RTP payload types including this option.
robust-sorting	The MTSI client in terminal is not required to support this option.	The MTSI client in terminal may have to reject offered RTP payload types including this option.
interleaving	The MTSI client in terminal is not required to support this option.	The MTSI client in terminal may have to reject offered RTP payload types including this option.
ptime	The MTSI client in terminal can interoperate with whatever value that is offered.	The offer shall not be rejected purely based on the offered ptime. The MTSI client in terminal should use this information and should use the requested packetization when sending RTP packets to the other end-point. The MTSI client should use the ptime value to determine how many non-redundant speech frames that can be packed into the RTP packets. The requirements in clause 7.4.2 shall be followed even if ptime in the SDP offer is larger than 80. The ptime parameter shall be included in the SDP answer and shall be an integer multiple of 20. If the received SDP offer includes the ptime parameters then the MTSI client in terminal may choose to use this information to define a suitable value for ptime in the SDP answer, see NOTE 3. The MTSI client in terminal may also choose to set the ptime value in the SDP answer according to Table 7.1, regardless of the ptime parameter in the SDP offer. The ptime value in the SDP answer shall not be larger than the maxptime value in the SDP answer.
channels	The number of channels may either be explicitly indicated in the SDP by including ‘/1’, ‘/2’, etc. on the a=rtpmap line, but the number of channels may also be omitted. When the number of channels is omitted then the default rule is that one channel is being offered. The MTSI client in terminal is only required to support audio media using one channel. Offered RTP payload types with more than one channel may therefore have to be rejected.	When the MTSI client in terminal accepts an offer for single-channel audio then the SDP answer shall either explicitly indicate ‘/1’ or omit the channels parameter. When the MTSI client in terminal accepts an offer for multi-channel audio then the number of channels shall be included in the SDP answer.
max-red	The MTSI client in terminal may use this information to bound the delay for receiving redundant frames. The MTSI client in terminal may also use this information to determine a suitable value for maxptime in the SDP answer.	The max-red parameter shall be included in the SDP answer and shall be an integer multiple of 20. If the received SDP offer includes both the ptime and maxptime parameters then the MTSI client in terminal may choose to use this information to define a suitable value for max-red in the SDP answer, see NOTE 2. The MTSI client in terminal may also choose to set the max-red value to 220. The max-red value in the SDP answer should be selected to give at least some room for adaptation.
ecn-capable-rtp: leap ect=0	An MTSI client in terminal uses this SDP attribute to offer ECN for RTP-transported media	Shall be included in the SDP answer if accepting an offer to use ECN and if the session setup allows for bit-rate adaptation
NOTE 1: An MTSI client may include both a speech coded, e.g. AMR-NB or AMR-WB, and ‘telephone-events’ for DTMF in the SDP answer, see TS 24.229 Clause 6.1, [7]. NOTE 2: It is possible to use the following relationship between maxptime, ptime and max-red: maxptime = ptime + max-red. There is however no mandatory requirement that these parameters must be aligned in this way. NOTE 3: It may be wise to use the same ptime value in the SDP answer as was given in the SDP offer, especially if the ptime in the SDP offer is larger than 20, since a value larger than the frame length indicates that the other end-point is somehow packet rate limited.

If an SDP offer is received from another MTSI client in terminal using the AMR-NB or AMR-WB codec, then the SDP offer will include configurations as described in Table 6.1 and Table 6.2. If the MTSI client in terminal chooses to accept the offer for using the AMR-NB or AMR-WB codec, as configured in Table 6.1 or Table 6.2 then the MTSI client in terminal shall support a configuration where the MTSI client in terminal creates an SDP answer containing an RTP payload type for the AMR-NB and AMR-WB codec as shown in Table 6.4.

Table 6.3a: Handling of SDP parameters common to EVS Primary and EVS AMR-WB IO in the received SDP offer and in the SDP answer

Parameter	Comments	Handling
ptime
maxptime
evs-mode-switch	This parameter indicates the initial operational mode. This parameter is used by MTSI MGW either when starting in EVS AMR-WB IO mode instead of EVS Primary mode or when switching between EVS Primary mode and EVS AMR-WB IO mode, e.g., for SRVCC.	MTSI client in terminal shall not include evs-mode-switch in the initial SDP offer. When including evs-mode-switch in the SDP offer during a session, the offerer shall use the requested mode when sending EVS packets at the start of the session. However, if a media stream is already being received, the offerer needs to be prepared to receive packets in both EVS primary and EVS AMR-WB IO modes until receiving the answer. When including evs-mode-switch in the SDP answer during a session, the answerer shall use the requested mode when sending EVS packets at the start of the session. When receiving SDP answer including evs-mode-switch during a session, the offerer shall use the requested mode when sending EVS packets. Note: the operational mode may be changed by adaptation during the session, irrespective of the value of the evs-mode-switch negotiated for the session.
hf-only		–
dtx		MTSI client in terminal shall not include dtx in the initial SDP offer. MTSI MGW may modify SDP offer to include dtx in order to disable DTX in the session.
dtx-recv		MTSI client in terminal shall not include dtx-recv. MTSI MGW may modify SDP offer or answer in order to disable DTX for the send direction of the receiver of dtx-recv.
cmr	In EVS AMR-WB IO mode, CMR to the bit-rates of EVS AMR-WB IO mode and NO_REQ is always enabled.	If cmr=-1 and the session is in the EVS Primary mode, MTSI client in terminal shall not transmit CMR. If cmr=-1 and the session is in the EVS AMR-WB IO, MTSI client in terminal shall restrict CMR to values of EVS AMR-WB-IO bit-rates and NO_REQ in the session. MTSI client in terminal is required to accept CMR even when cmr=-1. MTSI client in terminal is required to accept RTP payload without CMR even when cmr=1.
max-red	See Table 6.3
channels	See Table 6.3

Table 6.3b: Handling of the EVS Primary SDP parameters in the received SDP offer and in the SDP answer

Parameter	Comments	Handling
br		An MTSI client in terminal supporting the EVS codec is required to support the entire bit-rate range but may offer a smaller bit-rate range or even a single bit-rate.
br-send
br-recv
bw	The session should start with the maximum bandwidth supported by the initial bit-rate up to the maximum negotiated bandwidth. If a range of bandwidth is negotiated, the codec can operate in any bandwidth in the session but the maximum bandwidth in the range should be used after the start of or update of the session. If a single audio bandwidth higher than narrowband is negotiated, the codec operates in the negotiated bandwidth but can use lower bandwidth(s) in the session, depending on the input signal.	Both the offerer and the answerer shall send according to the bandwidth parameter in the answer.
bw-send
bw-recv
ch-send
ch-recv
ch-aw-recv		If a positive (2, 3, 5, or 7) value of ch-aw-recv is declared for a payload type and the payload type is accepted, the receiver of the parameter shall send partial redundancy (channel-aware mode) at the start of the session using the value as the offset. If ch-aw-recv=0 is declared or not present for a payload type and the payload type is accepted, the receiver of the parameter shall not send partial redundancy (channel-aware mode) at the start of the session. If ch-aw-recv=-1 is declared for a payload type and the payload type is accepted, the receiver of the parameter shall not send partial redundancy (channel-aware mode) in the session. If not present or a non-negative (0, 2, 3, 5, or 7) value of ch-aw-recv is declared for a payload type and the payload type is accepted, partial redundancy (channel-aware mode) can be activated or deactivated during the session based on the expected or estimated channel condition through adaptation signaling, such as CMR (see Annex A.2 of [125]) or RTCP based signalling (see clause 10.2). If not present or a non-negative (0, 2, 3, 5, or 7) value of ch-aw-recv is declared for a payload type and the payload type is accepted, the partial redundancy offset value can also be adjusted during the session based on the expected or estimated channel condition through adaptation signaling.

Table 6.3c: SDP parameters for the EVS AMR-WB IO parameters in the received SDP offer and in the SDP answer

Parameter	Comments	Handling
mode-set	See Table 6.3
mode-change-period
mode-change-neighbor
mode-change-capability	The default value is re-defined in comparison to that in [28].	As the default and the only allowed value of mode-change-capability is 2 in EVS AMR-WB IO, it is not required to include this parameter in the SDP offer or answer.

NOTE 2: ECN-triggered adaptation is currently undefined for EVS. This does not prevent ECN-triggered adaptation from being negotiated and used for AMR or AMR-WB.

Table 6.4: SDP parameters for AMR-NB or AMR-WB for SDP answer when the SDP offer is received from another MTSI client in terminal

Parameter	Usage
octet-align	Shall not be included
mode-set	See Table 6.3
mode-change-period	Shall not be included
mode-change-capability	May be included. If it is included then it shall be set to 2
mode-change-neighbor	Shall not be included
maxptime	Shall be set to 240, see also Table 7.1
crc	Shall not be included
robust-sorting	Shall not be included
interleaving	Shall not be included
ptime	Shall be set according to Table 7.1
channels	Shall either be set to 1 or be omitted
max-red	Shall be included and shall be set to 220 or less
ecn-capable-rtp: leap ect=0	Shall be included in the SDP answer if accepting an offer to use ECN and if the session setup allows for bit-rate adaptation

If an SDP offer is received from a MTSI MGW inter-working with CS GERAN/UTRAN, and when the MTSI MGW supports ECN (see also clause 12.3.3), then it is likely to be configured as shown in Table 6.5 if the MTSI MGW does not support redundancy.

Table 6.5: Expected configuration of SDP parameters for AMR-NB or AMR-WB in an SDP offer from an MTSI MGW inter-working with CS GERAN/UTRAN

Parameter	Usage
octet-align	Either not included or set to 0
mode-set	Included and indicates the codec modes that are allowed in the CS network
mode-change-period	Set to 2
mode-change-capability	Set to 2
mode-change-neighbor	Set to 1 if the CS network is GERAN
maxptime	Set to 80, see also Table 12.1
crc	Not included
robust-sorting	Not included
interleaving	Not included
ptime	Set according to Table 12.1
channels	Set to 1 or parameter is omitted
max-red	Set to 0
ecn-capable-rtp: leap ect=0	Shall be included in the SDP answer if accepting an offer to use ECN and if the session setup allows for bit-rate adaptation

If the MTSI client in terminal accepts the offer included in Table 6.5 then the MTSI client in terminal shall support a configuration where the MTSI client in terminal creates an SDP answer containing an RTP payload type for the AMR-NB and AMR-WB codecs as shown in Table 6.6.

Table 6.6: SDP parameters for AMR-NB or AMR-WB for SDP answer when the SDP offer is received from another MTSI MGW

Parameter	Usage
octet-align	Shall be set according to the offer
mode-set	See Table 6.3
mode-change-period	Shall not be included
mode-change-capability	May be included. If it is included then it shall be set to 2
mode-change-neighbor	Shall not be included
maxptime	Shall be set to 240, see also Table 7.1
crc	Shall not be included
robust-sorting	Shall not be included
interleaving	Shall not be included
ptime	Shall be set according to Table 7.1
channels	Shall be set according to the offer
max-red	Shall be included and shall be set to 220 or less
ecn-capable-rtp: leap ect=0	Shall be included in the SDP answer if accepting an offer to use ECN and if the session setup allows for bit-rate adaptation

6.2.3 Video

6.2.3.1 Introduction

The common session setup procedures for video are described in clause 6.2.3.2. Session setup procedures for Coordination of Video Orientation (CVO) and Video Region of Interest (ROI) are described in clauses 6.2.3.3 and 6.2.3.4, respectively. Session setup procedures for RTP Retransmission and Forward Error Correction (FEC) are described in clauses 6.2.3.5 and 6.2.3.6, respectively.

6.2.3.2 Common Session Setup Procedures

If video is used in a session, the session setup shall determine the applicable bandwidth(s) as defined in clause 6.2.5, RTP profile, video codec, profile and level. The "imageattr" attribute as specified in IETF RFC 6236 [76] should be supported. The "framesize" attribute as specified in [60] shall not be used in the session setup.

An MTSI client shall offer AVPF for all media streams containing video. RTP profile negotiation shall be done as described in clause 6.2.1a.

An MTSI client is required to support the AVPF feedback messages trr-int, NACK and PLI [40] and the CCM feedback messages FIR, TMMBR and TMMBN [43], see Clauses 7.3.3 and 10.3. These feedback messages can only be used together with AVPF and shall be negotiated in SDP offer/answer before they can be used in the session [40]. An MTSI client sending an SDP offer for AVPF shall also include these AVPF and CCM feedback messages in the offer. An MTSI client accepting an SDP offer for AVPF for video shall also accept these AVPF and CCM feedback messages if they are offered.

If an MTSI client offers to use ECN for video in RTP streams then the MTSI client shall offer ECN Capable Transport as defined below. If an MTSI client accepts an offer for ECN for video then the MTSI client shall declare ECN Capable Transport in the SDP answer as defined below. The SDP negotiation of ECN Capable Transport is described in [84].

The use of ECN for a video stream in RTP is negotiated with the "ecn-capable-rtp" SDP attribute, [84]. ECN is enabled when both clients agree to use ECN as configured below. An MTSI client using ECN shall therefore also include the following parameters and parameter values for the ECN attribute:

– ‘leap’, to indicate that the leap-of-faith initiation method shall be used;

– ‘ect=0’, to indicate that ECT(0) shall be set for every packet.

An MTSI client offering ECN for video shall indicate support of TMMBR [43] by including the "ccm tmmbr" value within an "rtcp-fb" SDP attribute [40]. An MTSI client offering ECN for video may indicate support for RTCP AVPF ECN feedback messages [84] using the "rtcp-fb" SDP attribute with the "nack" feedback parameter and the "ecn" feedback parameter value. An MTSI client offering ECN for video may indicate support for RTCP XR ECN summary reports [84] using the "rtcp-xr" SDP attribute and the "ecn-sum" parameter.

An MTSI client receiving an offer for ECN for video with an indication of support of TMMBR [43] within an "rtcp-fb" attribute should accept the offer if it supports ECN. It shall then indicate support for TMMBR using an "rtcp-fb" attribute in the SDP answer.

An MTSI client receiving an offer for ECN for video with an indication of support of RTCP AVPF ECN feedback message but without support for TMMBR should accept the offer if it supports ECN and also the RTCP AVPF ECN feedback message. It shall then indicate support of the RTCP AVPF ECN feedback message using the "rtcp-fb" attribute in the SDP answer.

An MTSI client receiving an offer for ECN for video with an indication of support of RTCP XR ECN summary reports [84] without support for TMMBR should accept the offer if it supports ECN and also the RTCP XR ECN summary reports. It shall then indicate support of RTCP XR ECN summary reports in the SDP answer.

The use of ECN is disabled when a client sends an SDP without the "ecn-capable-rtp" SDP attribute.

An MTSI client may initiate a session re-negotiation to disable ECN to resolve ECN-related error cases. An ECN-related error case may be, for example, detecting non-ECT in the received packets when ECT(0) was expected or detecting a very high packet loss rate when ECN is used.

Examples of SDP offers and answers for video can be found in clause A.4. SDP examples for offering and accepting ECT are shown in Annex A.12.2.

NOTE: For H.264 / MPEG-4 (Part 10) AVC, the optional max-rcmd-nalu-size receiver-capability parameter of RFC 6184 [25] should be set to the smaller of the MTU size (if known) minus header size or 1 400 bytes (otherwise).

The "framerate" attribute as specified in [8] indicates the maximum frame rate the offerer wishes to receive. If the "framerate" attribute is present in the SDP offer, its value may be modified in the SDP answer when the answerer wishes to receive video with a different maximum frame rate than what was indicated in the offer.

An MTSI client in terminal setting up asymmetric video streams with H.264 (AVC) should use both the ‘level-asymmetry-allowed’ parameter and the ‘max-recv-level’ parameter that are defined in the H.264 payload format, [25]. When the ‘max-recv-level’ parameter is used then the level offered for the receiving direction using the ‘max-recv-level’ parameter must be higher than the default level that is offered with the ‘profile-level-id’ parameter.

An SDP offer-answer example showing the usage of the ‘level-asymmetry-allowed’ and ‘max-recv-level’ parameters is included in Annex A.4.5.

An MTSI client in terminal setting up asymmetric video streams with H.265 (HEVC) should use the ‘max-recv-level-id’ parameter that is defined in the H.265 payload format, [120]. The level offered for the receiving direction using the ‘max-recv-level-id’ parameter must be higher than the default level that is offered with the ‘level-id’ parameter.

An SDP offer-answer example showing the usage of the ‘max-recv-level-id’ parameter is included in Annex A.4.8.

The resolutions in the "imageattr" attribute correspond to the image size information in the encoded video bitstream such that the x-component corresponds to the image width, and the y-component corresponds to the height component. When the bit-rate is being adapted, values of image width or image height smaller than the x- or y-component(s) in the negotiated "imageattr" attribute may be temporarily used.

MTSI clients should indicate all their preferred resolutions in the SDP offer and answer exchanges using the "imageattr" attribute. MTSI clients should not renegotiate SDP in case of no agreement on resolution, i.e., no new SDP offer-answer exchanges are expected in case of a mismatch of resolutions as indicated by the "imageattr" attribute. This is an MTSI-specific relaxation of the requirement in IETF RFC 6236 [76], according to which SDP renegotiation is expected in case of no agreed resolution. Related SDP offer-answer examples based on this expected behavior for MTSI clients can be found in Annex A.4.4a.

6.2.3.3 Coordination of Video Orientation (CVO)

An MTSI client should support Coordination of Video Orientation (CVO) as specified in clause 7.4.5.

An MTSI client supporting CVO shall offer Coordination of Video Orientation (CVO) in SDP for all media streams containing video. CVO is offered by including the a=extmap attribute [95] indicating the CVO URN under the relevant media line scope. The CVO URN is: urn:3gpp:video-orientation. Here is an example usage of this URN to signal CVO relative to a media line:

a=extmap:7 urn:3gpp:video-orientation

The number 7 in the example may be replaced with any number in the range 1-14. The above SDP line indicates 2 bits of granularity for rotation and shall be present when offering CVO.

Higher granularity CVO supports up to 6 bits of precision and may additionally be offered for the rotation value by also including the following line of SDP in the offer:

a=extmap:5 urn:3gpp:video-orientation:6

For terminals with asymmetric capability (e.g. the ability to process video orientation information but not detect orientation), the sendonly and recvonly attributes [95] may be used. Terminals should express their capability in each direction sufficiently clearly such that signals are only sent in each direction to the extent that they both express useful information and can be processed by the recipient; for example, 6-bit signals would not be sent when the sending terminal can only detect orientation to a precision of 2 bits, and terminals incapable of detecting orientation would not send the header.

An MTSI client supporting CVO shall respond to receive CVO when CVO is offered to be sent in SDP, by including exactly one of the offered extmap attributes. An MTSI client supporting CVO shall respond to send CVO when CVO is offered to be received in SDP, by including exactly one of the offered extmap attributes. An MTSI client shall not answer with CVO in a direction when not offered CVO in that direction in SDP.

6.2.3.4 Video Region-of-Interest (ROI)

An MTSI client should support Video Region-of-Interest (ROI) signaling as specified in clause 7.3.7.

An MTSI client supporting ROI shall support at least one of the following modes to request a desired region of interest (signalled from an MTSI receiver to an MTSI sender):

– Far End Camera Control’ (FECC), as specified in [135]-[139] and clause 7.3.7

– ‘Arbitrary ROI’, as specified in clause 7.3.7

– ‘Pre-defined ROI’, as specified in clause 7.3.7

An MTSI client supporting FECC using H.224 shall offer FECC in SDP for all media streams containing video, where FECC capabilities are desired. FECC shall be offered via the syntax and semantics defined in IETF RFC 4573 [139]. The MIME type ‘application/h224’ corresponding to the RTP payload format for H.224 shall be used as in [139], which also defines the SDP parameters needed to indicate support for FECC using H.224.

An MTSI client supporting ‘Arbitrary ROI’ mode shall offer ‘Arbitary ROI’ in SDP for all media streams containing video, where ‘Arbitrary ROI’ capabilities are desired. ‘Arbitrary ROI’ shall be offered by including the a=rtcp-fb attribute [40] with the ‘Arbitrary ROI’ type under the relevant media line scope. The ‘Arbitrary ROI’ type in conjunction with the RTCP feedback method shall be expressed with the following parameter: 3gpp-roi-arbitrary. A wildcard payload type ("*") may be used to indicate that the RTCP feedback attribute for ‘Arbitrary ROI’ signaling applies to all payload types. If several types of ROI signaling are supported and/or the same ‘Arbitary ROI’ shall be specified for a subset of the payload types, several "a=rtcp-fb" lines can be used. Here is an example usage of this attribute to signal ‘Arbitrary ROI’ relative to a media line based on the RTCP feedback method:

a=rtcp-fb:* 3gpp-roi-arbitrary

An MTSI client supporting ‘Pre-defined ROI’ mode shall offer ‘Pre-defined ROI’ in SDP for all media streams containing video, where ‘Pre-defined ROI’ capabilities are desired. ‘Pre-defined ROI’ shall be offered by including the a=rtcp-fb attribute [40] with the ‘Pre-defined ROI’ type under the relevant media line scope. The ‘Pre-defined ROI’ type in conjunction with the RTCP feedback method shall be expressed with the following parameter: 3gpp-roi-predefined. A wildcard payload type ("*") may be used to indicate that the RTCP feedback attribute for ‘Pre-defined ROI’ signaling applies to all payload types. If several types of ROI signaling are supported and/or the same ‘Pre-defined ROI’ shall be specified for a subset of the payload types, several "a=rtcp-fb" lines can be used. Here is an example usage of this attribute to signal ‘Pre-defined ROI’ relative to a media line based on the RTCP feedback method:

a=rtcp-fb:* 3gpp-roi-predefined

The IANA registration information on the new RTCP feedback types for ‘Arbitrary ROI’ and ‘Pre-defined ROI’ are provided in Annex R.1.

The ABNF for rtcp-fb-val corresponding to the feedback types "3gpp-roi-arbitrary"and "3gpp-roi-predefined" is given as follows:

rtcp-fb-val =/ "3gpp-roi-arbitrary"

rtcp-fb-val =/ "3gpp-roi-predefined"

An MTSI sender supporting the ‘Pre-defined ROI’ feature shall offer detailed pre-defined ROI information in the initial offer-answer negotiation by carrying it in SDP. Pre-defined ROIs shall be offered by including the "a=predefined_ROI" attribute under the relevant media line. The following parameters shall be provided in the attribute for each pre-defined ROI:

– ROI_ID – identifies the pre-defined ROI

– Position_X – specifies the x-coordinate for the upper left corner of the ROI area covered in the original content (i.e., uncompressed captured content) in units of pixels

– Position_Y – specifies the y-coordinate for the upper left corner of the ROI area covered in the original content in units of pixels

– Size_X – specifies the horizontal size of the ROI area covered in the original content in units of pixels

– Size_Y – specifies the vertical size of the ROI area covered in the original content in units of pixels

– Name- specifies the name of the pre-defined ROI.

The syntax for the "a=predefined_ROI" attribute shall conform to the following ABNF:

predefined_ROI = "predefined_ROI:" PT 1*WSP attr-list

PT = 1*DIGIT / "*"

attr-list = ( set *(1*WSP set) ) / "*"

; WSP and DIGIT defined in [RFC5234]

set= "[" "ROI_ID=" idvalue "," "Position_X=" posvalue "," "Position_Y=" posvalue "," "Size_X=" sizevalue "," "Size_Y=" sizevalue "," "Name=" namevalue "]"

idvalue= onetonine*2DIGIT

; Digit between 1 and 9 that is

; followed by 0 to 2 other digits

posvalue = sizevalue / "0"

; position may be "0"

sizevalue = onetonine *5DIGIT

; Digit between 1 and 9 that is

; followed by 0 to 5 other digits

onetonine = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"

; Digit between 1 and 9

namevalue = byte-string

; byte-string defined in RFC 4566

The SDP offer with a=predefined_ROI parameter shall contain the full-size view of the video indicated via ROI_ID=0.

Here is an example use of the "a=predefined_ROI" attribute relative to a media line:

a=predefined_ROI:99

[ROI_ID=0,Position_X=1,Position_Y=1,Size_X=1080,Size_Y=720,Name=fullview] [ROI_ID=1,Position_X=1,Position_Y=1,Size_X=540,Size_Y=360,Name=museum] [ROI_ID=2,Position_X=541,Position_Y=1,Size_X=540,Size_Y=360,Name=cinema] [ROI_ID=3,Position_X=1,Position_Y=361,Size_X=540,Size_Y=360,Name=park] [ROI_ID=4,Position_X=541,Position_Y=361,Size_X=540,Size_Y=360,Name= zoo]

The IANA registration information for the "a=predefined_ROI" SDP attribute is provided in Annex M.5.

In response to the SDP offer with the set of offered pre-defined ROIs provided using the "a=predefined_ROI" line(s), an MTSI client accepting ‘Pre-defined ROI’ shall provide an SDP answer using the "a=predefined_ROI" line(s) containing the accepted set of pre-defined ROIs. Such an SDP answer shall also contain the "a=rtcp-fb:* 3gpp-roi-predefined" line. The accepted set of pre-defined ROIs shall be a subset of the offered set of pre-defined ROIs. If the SDP answer contains the a=rtcp-fb:* 3gpp-roi-predefined" line, but does not contain a "a=predefined_ROI" line, this indicates that the MTSI client supports the ‘Pre-defined ROI’ mode, but none of the ROIs in the offered set of pre-defined ROIs is acceptable for this MTSI client. Following the successful negotiation of ‘Pre-defined ROI’, the MTSI receiver uses the RTCP feedback method to request from the accepted set of pre-defined ROIs and MTSI sender encodes the sent video accordingly to provide the requested pre-defined ROI.

If the SDP offer just provides the "a=predefined_ROI" but not "a=rtcp-fb:* 3gpp-roi-predefined ", then the "a=predefined_ROI" lines should be ignored.

A new SDP offer-answer negotiation can be performed to modify the set of pre-defined ROIs. The MTSI sender may update all the content of pre-defined ROIs, including the total number of pre-defined ROIs, and the position, size and name of each of the pre-defined ROIs.

The ROI information parameters exchanged via the a=predefined_ROI parameter in the SDP signalling defined above are independent of the negotiated video resolution for the encoded content. Instead, the ROI information parameters defined above take as reference the original video content, i.e., uncompressed captured video content. Therefore, no modifications or remappings of ROI parameters are necessary during any transcoding that results in changes in video resolution or during potential dynamic adaptations of encoded video resolution at the sender.

An MTSI client supporting ‘Arbitrary ROI’ or ‘Pre-defined ROI’ should also offer ‘Sent ROI’ in SDP for all media streams containing video. An MTSI sender accepting "Arbitrary ROI’ or ‘Pre-defined ROI’ shall also accept an accompanying ‘Sent ROI’ offer. An MTSI sender accepting ‘FECC’ should also accept an accompanying ‘Sent ROI’ offer. ‘Sent ROI’ is specified in clause 7.3.7 and is offered by including the a=extmap attribute [95] indicating the ‘Sent ROI’ URN under the relevant media line scope. The ‘Sent ROI’ URN corresponding to an arbitrary ROI is: urn:3gpp:roi-sent, on which the IANA registration information is provided in Annex O.4. The ‘Sent ROI’ URN corresponding to a pre-defined ROI is: urn:3gpp:predefined-roi-sent, on which the IANA registration information is provided in Annex O.5. Here is an example usage of this URN to signal ‘Sent ROI’ relative to a media line:

a=extmap:7 urn:3gpp:roi-sent

The number 7 in the example may be replaced with any number in the range 1-14.

6.2.3.5 RTP Retransmission

An MTSI client should support RTP Retransmission as specified in clause 7.4.6.

An MTSI client supporting RTP Retransmission shall offer retransmission for all media streams containing video. The binding used for retransmission stream to the payload type number is indicated by an rtpmap attribute. The MIME subtype name used in the binding is "rtx". The "apt" (associated payload type) parameter shall be used to map the retransmission payload type to the associated original payload type. The "rtx-time" payload-format-specific parameter indicates the maximum time a sender will keep an original RTP packet in its buffers available for retransmission [140]. An MTSI client offering RTP retransmission shall specify "rtx-time" parameter.

An SDP offer/answer example showing the usage of the "apt" and "rtx-time" is included in Annex A.4.2c.

Bandwidth allocation for video with RTP Retransmission is discussed in clause 6.2.5.3.

6.2.3.6 Forward Error Correction (FEC)

An MTSI client should support Forward Error Correction (FEC) as specified in clause 7.4.7.

An MTSI client supporting FEC shall offer FEC for all media streams containing video. The MIME subtype name used for FEC stream is "flexfec". The "ssrc-group" attribute is used to designate FEC grouping association according to "ssrc" identifiers along with the "FEC-FR" grouping semantics for FEC Framework. The "repair-window" parameter indicates the time span of the source and repair packets [141] [143]. An example for FEC grouping relative to a media line is:

a=ssrc:1234

a=ssrc:2345

a=ssrc-group:FEC-FR 1234 2345

An SDP offer/answer example showing the usage of the "flexfec","repair-window" and "ssrc-group" is included in Annex A.4.2d.

Bandwidth allocation for video with FEC is discussed in clause 6.2.5.3.

6.2.4 Text

An MTSI client should offer AVP for all media streams containing text. Only in cases where there is an explicit demand for the AVPF RTCP reporting timing or feedback messages AVPF shall be used. If AVPF is offered then RTP profile negotiation shall be done as described in clause 6.2.1a.

Examples of SDP offers for text can be found in clause A.5.

An MTSI client configured to automatically enable global text telephony (GTT), e.g. because the MTSI client is used by a deaf or hearing-impaired person or a person wanting to communicate with such an impaired person, shall accept an initial INVITE request for a SIP dialogue if the SDP offer does not include real time text media. It shall then send a new SDP offer (e.g. in a SIP UPDATE request during call establishment) adding text media for real time text conversation.

NOTE: As one example, incoming calls from a PSTN interworked by an MGCF will not contain media for real time text conversation in the initial SDP offer. The new offer adding media for real time text conversation enables the transport of real time text towards the MTSI client.

6.2.5 Bandwidth negotiation

6.2.5.1 General

The SDP shall include bandwidth information for each media stream and also for the session in total. The bandwidth information for each media stream and for the session is defined by the Application Specific (AS) bandwidth modifier as defined in RFC 4566 [8].

An MTSI client in terminal should include the ‘a=bw-info’ attribute in the SDP offer. When accepting a media type where the ‘a=bw-info’ attribute is included the MTSI client in terminal shall include the ‘a=bw-info’ attribute in the SDP answer if it supports the attribute. The ‘a=bw-info’ attribute and the below used bandwidth properties are defined in clause 19.

When the ‘a=bw-info’ attribute is supported, the following bandwidth properties shall be included for each RTP payload type in the SDP:

– Maximum Supported Bandwidth for sending direction.

– Maximum Desired Bandwidth for sending direction.

– Minimum Desired Bandwidth for sending direction.

– Minimum Supported Bandwidth for sending direction.

– Maximum Supported Bandwidth for receiving direction with the following exception:

– The b=AS bandwidth modifier indicates the bandwidth needed for the RTP payload type that requires the highest bandwidth. The Maximum Supported Bandwidth for this RTP payload type is therefore indicated with the b=AS bandwidth modifier and does not need to be indicated with the ‘a=bw-info’ attribute for this RTP payload type. It is still allowed to include the ‘a=bw-info’ attribute for this RTP payload type but the value shall then be aligned with the b=AS value when sending the SDP. When receiving the SDP,the b=AS bandwidth modifier and the Maximum Supported Bandwidth for the receiving direction may not be aligned. In this case, the maximum sending rate is determined as defined below.

– Maximum Desired Bandwidth for receiving direction.

– Minimum Desired Bandwidth for receiving direction.

– Minimum Supported Bandwidth for receiving direction.

Recommended bandwidths for several codec configurations are provided in the media-specific sections.

For a media stream that has been removed by either the offerer or answerer, the inclusion of bandwidth information is optional. This is in accordance with clause 8.2 of RFC 3264 [58].

SDP examples incorporating bandwidth modifiers are shown in annex A. SDP examples using the ‘a=bw-info’ attribute are shown in annex A.6.3.

When an MTSI client in terminal receives an SDP offer or answer it shall determine the maximum sending rate for the selected codec by selecting the smallest of the following:

– the bandwidth value, if the b=AS parameter was included in the received SDP offer or answer

– the Maximum Supported Bandwidth for the receiving direction, if included in the received SDP

– the preconfigured data rate for the selected codec, if the MTSI client has been preconfigured by the operator to use a particular data rate for the selected codec

– the maximum data rate for the selected codec as determined by examining the codec information (e.g., codec, mode, profile, level) and any other media information (e.g., ptime and maxptime) included in the received SDP offer or answer. This maximum data rate is determined assuming no extra bandwidth is allowed for redundancy.

The maximum sending rate may be further updated by the MTSI client in terminal based on receiving an indication of the granted QoS (see clause 6.2.7).

The MTSI client in terminal shall not transmit at a rate above the maximum sending rate. For speech, the MTSI client should transmit using the codec mode with the highest data rate allowed by the maximum sending rate, except if limited to a lower codec mode by the initial codec mode procedures (see clause 7.5.2.1.6) or by the adaptation procedures (see clause 10.2).

The MTSI client in terminal should support access network bitrate recommendation (ANBR, see clause 10.7). SDP offer/answer re-negotiation shall not be used as a replacement for dynamic media bitrate adaptation. ANBR contains information on short-term bandwidth and SDP offer/answer re-negotiations should be avoided or minimized since they consume network resources. Therefore, SDP offer/answer re-negotiation (e.g. in SIP UPDATE) shall not be initiated based on ANBR information other than in the following cases:

If;

1. The received ANBR from the access network is below the established GBR; and

2. The received ANBR cannot be supported by any of the negotiated codec configurations; and

3. Potentially increased loss and/or delay due to not lowering the bitrate are not acceptable; and

4. The MTSI client in terminal supports one or more codec configurations that supports the received ANBR; and

5. ANBR messages with values meeting all conditions in 1-4 above are received consistently for an extensive period of time (e.g. 5 seconds or more, see also clause 10.7.2)

then the MTSI client in terminal:

– may re-negotiate the session

– To switch to a codec or codec configuration that can support the lower bitrate in the ANBR (if any); and/or

– To reduce the number of used RTP streams (e.g. turning off the affected media); and

– If the session re-negotiation fails, shall not initiate further re-negotiation based on ANBR for that bearer in the session.

For video, if:

– TMMBR/TMMBN are not supported in the session; and

– For an extensive period of time (e.g. 5 seconds), the MTSI client in terminal consistently receives ANBR messages with values significantly below the video bitrate sent (as estimated by the receiving MTSI client in terminal) from the remote peer

Then the MTSI client in terminal may re-negotiate the session:

– To set the session bitrate for video (see clause 6.2.5) to a value corresponding to the minimum of the received ANBR and GBR (if > 0); or

– To turn video off

NOTE 1: An ANBR below GBR does not change the GBR semantics in any way. GBR is defined as a guarantee that for a packet stream not exceeding the GBR, 98 percent of the packets do not experience a delay exceeding the QCI’s Packet Delay Budget (see clause 6.1.7.2 of TS 23.303 [90]). Temporarily reducing bitrate below GBR to comply with an ANBR can increase the probability that loss and/or delay can be kept within the bounds set by the used QCI.

NOTE 2: For GBR=MBR bearers, an ANBR below the GBR can frequently be supported by the negotiated codec configuration.

NOTE 3: For GBR<MBR bearers, an ANBR below the GBR can typically not be supported by the negotiated codec configuration.

NOTE 4: If the above conditions are not met, the MTSI client in terminal will ignore ANBR values below the GBR (see also clause 10.7.2).

6.2.5.2 Speech

If an MTSI client includes an AMR or AMR-WB mode-set, or EVS Primary mode br or br-recv parameter in the SDP offer or answer, the MTSI client shall set the b=AS parameter to a value matching the maximum codec mode in the mode-set or the highest bit-rate in the br or br-recv, the packetization time (ptime), and the intended redundancy level. For example, b=AS for AMR-WB at IPv6 should be set to 38 if mode-set includes {6.60, 8.85, 12.65}, the packetization time is 20, and if no extra bandwidth is allocated for redundancy. Likewise, b=AS for EVS Primary mode at IPv4 should be set to 42 if br=7.2-24.4, the packetization is header-full payload format, ptime=20, and no extra bandwidth is allocated for redundancy.

If an MTSI client does not include an AMR or AMR-WB mode-set, or EVS Primary mode br or br-recv parameter in the SDP offer or answer, the MTSI client shall set the b=AS parameter in the SDP to a value matching the highest AMR/AMR-WB mode, i.e., AMR 12.2 and AMR-WB 23.85, or the highest bit-rate of EVS Primary mode depending on negotiated bandwidth(s), i.e., EVS 24.4 for NB and EVS 128 for WB, SWB and FB, respectively.

NOTE 1: When no mode-set is defined, then this should be understood as that the offerer or answerer is capable of sending and receiving all codec modes of AMR or AMR-WB. An MTSI client in terminal will not include the mode-set parameter in SDP offer in the initial offer-answer negotiation. See Clause 6.2.2.2, Tables 6.1 and 6.2. It is however expected that the mode-set is defined when an SDP offer is received from an MTSI MGW inter-working with CS GERAN/UTRAN, see Clause 6.2.2.3, Table 6.5.

The bandwidth to use for b=AS for AMR and AMR-WB, and EVS Primary mode should be computed as shown in Annexes K and Q respectively. Tables 6.7 and 6.8 shows the bandwidth for the respective AMR and AMR-WB codec when the packetization time is 20 and no extra bandwidth is allocated for redundancy. The b=AS value is computed without taking statistical variations, e.g., the effects of DTX, into account. Such variations can be considered in the scheduling and call admission control. Detailed procedures to compute b=AS of AMR and AMR-WB, and EVS Primary mode can be found in Annexes K and Q.

NOTE 2: For any payload format, b=AS of EVS Primary mode at 5.9 kbps source controlled variable bit-rate (SC-VBR) coding is computed as the b=AS of its highest component bit-rate, 8 kbps.

NOTE 3: b=AS of EVS AMR-WB IO mode can be computed as in the octet-aligned payload format of AMR-WB as shown in Annex K.

b=AS of EVS shall be equal to the maximum of b=AS of the highest included EVS primary mode and b=AS of the highest included EVS AMR-WB IO mode, regardless of the presence and configuration of evs-mode-switch.

Table 6.7: b=AS for each codec mode of AMR when ptime is 20

Payload format		Codec mode
Payload format		4.75	5.15	5.9	6.7	7.4	7.95	10.2	12.2
Bandwidth-efficient	IPv4	22	22	23	24	24	25	27	29
Bandwidth-efficient	IPv6	30	30	31	32	32	33	35	37
Octet-aligned	IPv4	22	22	23	24	25	25	28	30
Octet-aligned	IPv6	30	30	31	32	33	33	36	38

Table 6.8: b=AS for each codec mode of AMR-WB when ptime is 20

Payload format		Codec Mode
Payload format		6.6	8.85	12.65	14.25	15.85	18.25	19.85	23.05	23.85
Bandwidth-efficient	IPv4	24	26	30	31	33	35	37	40	41
Bandwidth-efficient	IPv6	32	34	38	39	41	43	45	48	49
Octet-aligned	IPv4	24	26	30	32	33	36	37	40	41
Octet-aligned	IPv6	32	34	38	40	41	44	45	48	49

Table 6.9: b=AS for each bit-rate of EVS Primary mode when ptime is 20

Payload format		Bit-rate
Payload format		7.2	8	9.6	13.2	16.4	24.4	32	48	64	96	128
Header-full	IPv4	24	25	27	30	34	42	49	65	81	113	145
Header-full	IPv6	32	33	35	38	42	50	57	73	89	121	153

Tables 6.10-1 to 6.10-3 describe the setting of the bandwidth properties that should be used for the ‘a=bw-info’ attribute for a few possible combinations of codec, codec rate, packetization schemes and redundancy levels. The Minimum Supported Bandwidth does not prevent encoding the speech with an even lower bitrate, for example when EVS is used in the 5.9 kbps VBR mode or during DTX periods when SID frames are encoded with a very low bit rate and are generated with a reduced frame rate. Bit rates lower than the Minimum Supported Bandwidth may also be used when sending DTMF. Additional combinations and corresponding bandwidth properties are found in Annex K for AMR, AMR-WB and EVS AMR-WB IO mode and in Annex Q for EVS primary mode.

Table 6.10-1: Recommended bandwidth properties for AMR to be used with the ‘a=bw-info’ attribute when codec modes up to 12.2 are negotiated

Parameter	Assumed setting
Negotiated codec modes	4.75, 5.9, 7.4, 12.2
Codec mode used without redundancy	12.2
Codec mode used with redundancy	5.9
Payload format	AMR/AMR-WB bandwidth-efficient
Minimum frame aggregation	1 frame per packet
Maximum frame aggregation	4 frames per packet
Maximum redundancy level	100%
Redundancy offset	0
IP version	6
Bandwidth property	Value
Maximum Supported Bandwidth	37 (see NOTE 1)
Maximum Desired Bandwidth	37
Minimum Desired Bandwidth	31
Minimum Supported Bandwidth	13 (see NOTE 2)
NOTE 1: If redundancy is needed for higher codec modes, if additional redundancy is needed, or if redundancy offset is needed then the Maximum Supported Bandwidth needs to be set to a higher value. NOTE 2: The Minimum Supported Bandwidth is calculated based on the lowest codec rate when maximum frame aggregation is used.

Table 6.10-2: Recommended bandwidth properties for AMR-WB to be used with the ‘a=bw-info’ attribute when codec modes up to 12.65 are negotiated

Parameter	Assumed setting
Negotiated codec modes	6.6, 8.85, 12.65
Codec mode used without redundancy	12.65
Codec mode used with redundancy	6.6
Payload format	AMR/AMR-WB bandwidth-efficient
Minimum frame aggregation	1 frame per packet
Maximum frame aggregation	4 frames per packet
Maximum redundancy level	100%
Redundancy offset	0
IP version	6
Bandwidth property	Value
Maximum Supported Bandwidth	38 (see NOTE 1)
Maximum Desired Bandwidth	38
Minimum Desired Bandwidth	32
Minimum Supported Bandwidth	13 (see NOTE 2)
NOTE 1: If redundancy is needed for higher codec modes, if additional redundancy is needed, or if redundancy offset is needed then the Maximum Supported Bandwidth needs to be set to a higher value. NOTE 2: The Minimum Supported Bandwidth is calculated based on the lowest codec rate when maximum frame aggregation is used.

Table 6.10-3: Recommended bandwidth properties for EVS to be used with the ‘a=bw-info’ attribute when codec modes up to 13.2 are negotiated

Parameter	Assumed setting
Negotiated codec modes	5.9 – 13.2
Codec mode used without redundancy	13.2
Codec mode used with redundancy	7.2
Payload format	EVS
Minimum frame aggregation	1 frame per packet
Maximum frame aggregation	4 frames per packet
Maximum redundancy level	100%
Redundancy offset	0
IP version	6
Bandwidth property	Value
Maximum Supported Bandwidth	40 (see NOTE 1 and NOTE 2)
Maximum Desired Bandwidth	38
Minimum Desired Bandwidth	32 (see NOTE 2)
Minimum Supported Bandwidth	14 (see NOTE 2)
NOTE 1: If redundancy is needed for higher codec modes, if additional redundancy is needed, or if redundancy offset is needed then the Maximum Supported Bandwidth needs to be set to a higher value. NOTE 2: The bandwidth is calculated assuming EVS 7.2 kbps when maximum frame aggregation is used.

SDP examples using the ‘a=bw-info’ attribute for speech are shown in annex A.6.3.

6.2.5.3 Video

The b=AS parameter is set to match the maximum bit rate desired for the media in the receiving direction.

Video codecs are usually capable of adapting the bit rate over a large bit rate range. This allows for dynamic addition of redundancy (see clauses 6.2.3.5 and 6.2.3.6) without explicitly allocating any additional bandwidth for the redundancy information. Therefore, when the ‘a=bw-info’ attribute is used, the Maximum Supported Bandwidth and the Maximum Desired Bandwidth properties should be set to the same value.

SDP examples using the ‘a=bw-info’ attribute for video are shown in annex A.6.3.

6.2.6 The Synchronization Info attribute "3gpp_sync_info"

Synchronization jitter (also known as synchronization or inter-media skew) is defined as the amount of synchronization delay between media streams that needs to be maintained during the synchronization process (at the receiver side), which is acceptable to a session (or the sender of the multimedia streams) for a good user experience.

Tight synchronization between the constituent streams is not necessary for all types of MTSI sessions. For instance, during a VoIP call, one of the call participants may wish to share a video clip or share his/her camera view. In this situation, the sender may want to relax the requirement on the receiver to synchronize the audio and the video streams in order to maintain a good video quality without stressing on tight audio/video synchronization. The Synchronization Info attribute defined in the present document is not just limited to lip-sync between audio/video streams, but is also applicable to any two media streams that need to be synchronized during an MTSI session. This attribute allows an MTSI client to specify whether or not media streams should be synchronized. In case the choice is to have synchronization between different streams, it is up to the implementation, use case and application to decide the exact amount of synchronization jitter allowed between the streams to synchronize.

The ABNF for the synchronization info attribute is described as follows:

Synchronization-Info = "a" "=" "3gpp_sync_info" ":" sync-value

sync-value = "Sync" / "No Sync"

The value "Sync" indicates that synchronization between media shall be maintained. The value "No Sync" indicates that No Synchronization is required between the media.

The parameter "3gpp_sync_info" should be included in the SDP at the session level and/or at the media level. Its usage is governed by the following rules:

1. At the session level, the "3gpp_sync_info" attribute shall be used with the group attribute defined in RFC 3388 [48]. The group attribute indicates to the receiver which streams (identified by their mid attributes) that are to be synchronized. The "3gpp_sync_info" attribute shall follow the "group: LS" line in the SDP.

2. At the media level, the "3gpp_sync_info" attribute shall assume a value of "No Sync" only. It indicates to the receiver that this particular media stream is not required to be synchronized with any other media stream in the session. The use of the "mid" attribute of RFC 3388 [48] is optional in this case. If the "mid" attribute is used for any other media in the session, then "mid" with this media line shall be used also according to RFC 3388 [48]. Otherwise, it is not necessary to tie the "3gpp_sync_info" attribute with the "mid" attribute.

3. When the "3gpp_sync_info" attribute is defined at both session level (with the "group" attribute) and media level, then the media level attribute shall override the session level attribute. Thus if the "3gpp_sync_info" attribute is defined at the media level, then that particular media stream is not to be synchronized with any other media stream in the session (even if the "3gpp_sync_info" is defined at the session level for this media stream).

The calling party (or the initiator or offerer of the multimedia stream) should include the "3gpp_sync_info" attribute in the SDP which is carried in the initial INVITE message. Upon reception of the INVITE message that includes the "3gpp_sync_info" attribute, the other party in the session should include its own "3gpp_sync_info" attribute (with its own wish for synchronization or no synchronization) in the 200/OK response message.

There are no offer/answer implications on the "3gpp_sync_info" attribute; it provides synchronization requirement between the specified media streams to the receiver. The "3gpp_sync_info" attribute in the calling party SDP is only an indication to the called party of the synchronization requirement that should be maintained between the specified media streams that it receives. Similarly the "3gpp_sync_info" attribute value from the called party is an indication to the calling party of the synchronization requirements between specified media streams. The "3gpp_sync_info" attribute value can be different for the calling and the called parties.

SDP examples using the "3gpp_sync_info" attribute are given in clause A.7.

NOTE: Default operation in the absence of the "3gpp_sync_info" attribute in SDP is to maintain synchronization between media streams.

6.2.7 Negotiated QoS parameters

6.2.7.1 General

The MTSI client in the terminal may support the negotiation of the QoS. The term "negotiated" in the present document describes the end result of a QoS negotiation between an MTSI client in terminal and the network (or the end result of what the network grants to the MTSI client in terminal even if no negotiation takes place).

An MTSI client in terminal supporting the transport level QoS negotiation should verify that the QoS parameters, e.g. MBR and GBR, are aligned with the media configurations negotiated in SDP. While checking whether the different bandwidth parameters are aligned or not, the MTSI client in terminal should take into account the following areas where differences are likely to occur: parameter encoding; units used; packetization schemes related to the IP/UDP/RTP overhead; the amount of RTCP bandwidth. The MTSI client in terminal needs to compensate for the differences if found.

NOTE: The transport level QoS negotiation applies only to 3GPP accesses.

In the following sections it is assumed that the MTSI client in terminal supports the QoS negotiation and is made aware of the negotiated bandwidth properties and other QoS hints (if supported and used, see clause 6.2.7.4).

6.2.7.2 Alignment of negotiated QoS parameters and b=AS bandwidth modifier

In SDP offer-answer, the b=AS bandwidth modifier is used to describe the maximum bandwidth for the receiving direction. The IP/UDP/RTP overhead is included in the bandwidth value for RTP-based media but the RTCP bandwidth is not included. The IP/UDP/DTLS/SCTP overhead is included in the bandwidth value for SCTP-based media such as the data channel (see clause 6.2.10). The bandwidth value is an integer and the unit is kbps.

If, at session setup or at session re-negotiation, the MTSI client in terminal detects that the negotiated downlink QoS Maximum Bit Rate (MBR) is not aligned with the b=AS bandwidth modifier in the sent SDP then it should try to align the bandwidth properties in a subsequent SDP offer-answer.

If, during the session, the negotiated downlink Maximum Bit Rate(s) (MBR) for the bearer(s) has been updated from the network then the MTSI client in terminal should check if the bandwidth(s) it sent within b=AS bandwidth modifiers in previous SDP (e.g. during the initial session setup or earlier session re-negotiation, if any) are aligned with the downlink MBR(s) allocated for the bearer(s) and its receiving capabilities.

The rules for alignment are different depending on how many media streams that are handled by the bearer, as follows:

– When a bearer carries a single media stream, then it is the media-level b=AS bandwidth for that media stream that should be aligned with the MBR of the bearer.

– When a bearer carries several media streams, then it is the sum of the media-level b=AS bandwidths for those media streams that should be aligned with the MBR of the bearer.

The rules for alignment are also different depending on whether the media stream(s) are bi-directional (sendrecv) or uni-direction (sendonly or recvonly), as follows:

– If the MTSI terminal receives (and possibly sends) a media stream, it should consider the sent b=AS bandwidth(s) in SDP for that media stream in comparison with the downlink MBR.

– If the MTSI terminal only sends a media stream, it should not consider the sent b=AS bandwidth(s) in SDP for that media stream in comparison with the downlink MBR.

NOTE 1: The b=AS bandwidth and the MBR bandwidth are not directly comparable since the b=AS bandwidth does not include the RTCP bandwidth while the MBR bandwidth allocation for RTP media must include some headroom for RTCP. The bandwidths will therefore almost always be different. The MBR bandwidth may also differ from the b=AS bandwidth because of other reasons, for example: bearer allocation and header compression. It is an implementation consideration to handle such impacts and how to judge whether the bandwidth values differ and what bandwidth value to send in the UPDATE message.

If the MTSI client in terminal determines that the b=AS bandwidth(s) are not aligned with the MBR and the receiving capabilities of the MTSI client, then it should align the media-level b=AS bandwidth(s) to the MBR and its receiving capabilities by sending to the other party an SDP offer with the new b=AS bandwidth value(s). In the process of this alignment it is also likely that the session-level b=AS bandwidth needs to be updated. In addition, the MTSI client in terminal may modify other parts of the SDP, e.g., to replace the codecs or adjust codec parameters (such as the AMR or AMR-WB mode-set).

NOTE 2: It could be necessary to reconfigure the codec(s), or even to drop some media streams, to be able to operate within the bandwidth constraints defined with the MBR of the bearer.

NOTE 3: A situation when the MTSI client in terminal could not align the b=AS bandwidth(s) with the MBR, due to its receiving capabilities, is when it does not support rate adaptation.

This alignment may require re-negotiation, which should preferably be performed when there is session re-negotiation for other reasons. When additional re-negotiation is required, which adds load to the SIP bearer and the SIP servers, it is not desirable to repeat the re-negotiation multiple times. Therefore, if re-negotiation fails to align the b=AS bandwidth modifier and the QoS parameters then it should not be repeated unless new re-negotiation is needed for other reasons, e.g. to add or remove media components.

If an MTSI client in a terminal receives a new SDP offer with new b=AS bandwidth value(s) (e.g., in a SIP UPDATE or in a SIP re-INVITE) and it accepts the session update then it shall generate an SDP answer as described in clause 6.2.

Any subsequent QoS changes indicated to the MTSI client in terminal during an MTSI session (including the cases described in Clause 10.3) shall be signalled by the MTSI client in terminal (subject to the QoS update procedure) to the other party using the same signalling described above.

Examples of SDP using negotiated QoS are given in clause A.8.

When the MTSI client in terminal receives an indication that the negotiated uplink Maximum Bit Rate (MBR) is less than the current maximum sending rate of its sender, the MTSI client in terminal should configure the maximum sending rate of its sender to align with the negotiated uplink Maximum Bit Rate (MBR).

When the MTSI client in terminal receives an indication that the negotiated uplink Maximum Bit Rate (MBR) is greater than the current maximum sending rate of its sender and rate adaptation is possible for the session, the MTSI client in terminal should configure the maximum sending rate of its sender to align with the smallest of the following:

– the negotiated uplink Maximum Bit Rate (MBR)

– the bandwidth value, if the b=AS parameter was included in the last SDP offer or answer received by the client

– the preconfigured data rate for the selected codec, if the MTSI client has been preconfigured by the operator to use a particular data rate for the selected codec

6.2.7.3 Alignment of negotiated QoS parameters and a=bw-info attribute

The Maximum Supported Bandwidth for the sending direction should be aligned with the uplink MBR.

The Minimum Desired Bandwidth for the sending direction should be aligned with the uplink GBR.

The Maximum Supported Bandwidth for the receiving direction should be aligned with the downlink MBR.

The Minimum Desired Bandwidth for the receiving direction should be aligned with the downlink GBR.

The procedures for aliging the above listed bandwidth properties with the above listed QoS parameters are the same as given above in clauses 6.2.7.1 and 6.2.7.2 for other bandwidth-related information.

6.2.7.4 The a=3gpp-qos-hint SDP attribute

6.2.7.4.1 General

In some cases, it is not possible to uniquely map a media type in SDP to an appropriate QoS without additional information on the intended usage of that media from the application or the end-user of that application.

The MTSI client in terminal may include a non-authoritative QoS hint in one or more SDP media description(s), for use by local and remote policy control functions, by adding an "a=3gpp-qos-hint" media-level SDP attribute with a value that is set based on the intended media usage. The QoS hints included on the "a=3gpp-qos-hint" line applies jointly to the aggregate of all packets (e.g. if more than one media stream is part of the same media description), and equally in both directions (uplink and downlink) unless restricted by the inclusion of "a=sendonly" or "a=recvonly" in the same media description.

If this attribute is included in an SDP media description, policy control can choose to take this additional information into account for the affected media.

An "a=3gpp-qos-hint" attribute shall not occur more than once for an SDP media description.

SDP examples are provided in Annex A.16.

NOTE: If a media GBR bearer that was set up assisted by 3gpp-qos-hint information is dropped by the network due to insufficient resources, an attempt to re-establish the bearer can be made through a re-offer in an UPDATE or re-INVITE with less demanding QoS values included in the 3gpp-qos-hint and/or bandwidth attributes (e.g. "b=AS" and "a=bw-info"; see clause 19) for that media. How to get information on what values that will be acceptable to include in such re-offer is not specified.

6.2.7.4.2 3gpp-qos-hint ABNF syntax and semantics

3gpp-qos-hint-value = qos-hint *(";" qos-hint)

qos-hint = qos-hint-property ["=" qos-hint-end-to-end-value *(qos-hint-split)]

qos-hint-property = "loss" / "latency" / token

qos-hint-end-to-end-value = qos-hint-value

qos-hint-split = "/" qos-hint-split-method ":" qos-hint-split-value

qos-hint-split-method = "local" / token

qos-hint-split-value = qos-hint-value

qos-hint-value = zero-based-integer / non-zero-real / token

; token as defined by IETF RFC 4566

; zero-based-integer and non-zero-real as defined by IETF RFC 8866The IANA registration information for this attribute is provided in Annex M.11.

A qos-hint-property value shall only occur once on the "a=3gpp-qos-hint" line. If a qos-hint-property value is not included on the "a=3gpp-qos-hint" line, it should be interpreted as the UE and application have no preference of any qos-hint-value for that qos-hint-property but anything the network can provide is equally acceptable.

If a qos-hint-property has no qos-hint-end-to-end-value, it is of boolean (on/off) type.

If the qos-hint-propery has a qos-hint-end-to-end-value but doesn’t include any explicit qos-hint-split, the qos-hint-end-to-end-value is split equally between the SDP offerer and the SDP answerer. If an explicit qos-hint-split is included, it specifies how the split of the qos-hint-end-to-end-value between SDP offerer and SDP answerer is made. The following qos-hint-split-method values are currently defined:

"local": The qos-hint-split-value specifies the SDP sender’s part of the qos-hint-end-to-end-value that is applied across its local link, in the same format and units used by the associated qos-hint-end-to-end-value, the value being the same in both send and receive directions. The SDP sender of the SDP offer is the SDP offerer and the SDP sender of the SDP answer is the SDP answerer.

The following qos-hint-property values are currently defined:

"loss": This qos-hint-property qos-hint-end-to-end-value describes the maximum desirable end-to-end transport level packet loss rate in percent (without "%" sign) as a zero-based-integer or as a non-zero-real value.

"latency": This qos-hint-property qos-hint-end-to-end-value describes the maximum desirable end-to-end transport level packet latency in milliseconds as a zero-based-integer or as a non-zero-real value. The value excludes any application-level processing in the sender and receiver, such as e.g. application-level retransmission or encoding/decoding.

6.2.7.4.3 Creating an SDP offer

An "a=3gpp-qos-hint" line may be included in any media description in an SDP offer.

6.2.7.4.4 Creating an SDP answer

If there is no "a=3gpp-qos-hint" line included in a media description in the SDP offer, it shall not be included in the corresponding media description in the SDP answer.

If a qos-hint with an unknown or malformed qos-hint-property or qos-hint-value is received in an SDP offer, that qos-hint shall be ignored, shall be omitted from the SDP answer, and shall neither cause the "a=3gpp-qos-hint" line nor the entire media description to be rejected in the SDP answer.

An SDP answerer shall not add any qos-hint-property values on the "a=3gpp-qos-hint" line that are not present in the received SDP offer.

A "loss" qos-hint-end-to-end-value received in the SDP offer that is accepted by the SDP answerer shall be kept unmodified in the SDP answer. A "loss" qos-hint-end-to-end-value received in the SDP offer that cannot be supported by the SDP answerer even when making use of an allowable qos-hint-split-value (see below) may be increased in the SDP answer to a value that can be supported by the SDP answerer. A "loss" qos-hint-end-to-end-value received in the SDP offer that is higher than required by the SDP answerer may be decreased in the SDP answer to a value that is required by the SDP answerer. Figures 6.2.7.4.4-1 and 6.2.4.4.4-2 provide illustrated examples of these principles. If the "loss" qos-hint-property is known by the SDP answerer but if there are no known, supported qos-hint-values for it, the entire qos-hint shall be omitted from the SDP answer.

A "latency" qos-hint-value received in the SDP offer that cannot be supported by the SDP answerer as the desirable maximum end-to-end packet latency should be increased in the SDP answer to a value that can be supported by the SDP answerer. A "latency" qos-hint-end-to-end-value received in the SDP offer that is higher than required by the SDP answerer may be decreased in the SDP answer to a value that is required by the SDP answerer. Figures 6.2.7.4.4-1 and 6.2.7.4.4-2 provide illustrated examples of the principles for "loss" that is also applicable for "latency". If the "latency" qos-hint-property is known by the SDP answerer but if there are no known, supported qos-hint-values for it, the entire qos-hint shall be omitted from the SDP answer.

If, as a result of the above procedures, there are no qos-hints to be included in the SDP answer, the entire "a=3gpp-qos-hint" line shall be omitted from the SDP answer.

NOTE: If the qos-hint-end-to-end-value is changed from what was included in the offer, or if the implicit or explicit qos-hint-split-value applicable to the SDP offerer is decreased between the SDP offer and the SDP answer, there’s a risk that the resulting QoS will not be acceptable to the SDP offerer or, if anyway accepted, at least cause sub-optimal user experience.

Figure 6.2.7.4.4-1 Illustration of 3gpp-qos-hint "loss" UE-to-UE offer/answer

Figure 6.2.7.4.4-2 Illustration of 3gpp-qos-hint "loss" UE-to-Network offer/answer

If a qos-hint with an unknown or malformed qos-hint-split-method or qos-hint-split-value is received in an SDP offer, the entire qos-hint-split shall be ignored, shall be omitted from the SDP answer, and shall neither cause the "a=3gpp-qos-hint" line nor the entire media description to be rejected in the SDP answer.

The qos-hint-split provides the SDP offerer’s opinion on how that qos-hint-end-to-end-value should be split between the SDP offerer’s and the SDP answerer’s local links. As stated above, if no qos-hint-split is provided the qos-hint-end-to-end-value is split equally between SDP offerer and SDP answerer local links and is equivalent to a qos-hint-split being provided with a value that is half of the qos-hint-end-to-end-value.

If the SDP answerer accepts a default split (without explicit qos-hint-split in the SDP offer) it shall not include any qos-hint-split in the SDP answer.

If the SDP answerer accepts an explicitly provided qos-hint-split proposed by the SDP offer, it shall include a qos-hint-split in the SDP answer with a qos-split-hint-value being equal to qos-hint-end-to-end-value in the SDP answer minus the corresponding qos-hint-split-value from the SDP offer.

If the SDP answerer does not accept the qos-hint-split-value proposed in the SDP offer, regardless if that qos-hint-split-value is explicit or not, it can make one of the following choices for the SDP answer:

– If the SDP offerer qos-hint-split-value is smaller than what the SDP answerer requires (i.e., qos-hint-end-to-end-value in the SDP offer minus the corresponding qos-hint-split-value from the SDP offer is larger than required across the SDP answerer’s local link), the SDP answerer may include a qos-hint-split-value in the SDP answer that is less than the qos-hint-end-to-end-value in the SDP answer minus the corresponding qos-hint-split-value from the SDP offer. The SDP answerer may use the value 0 if the actual (non-zero) qos-hint-split-value can be considered insignificant compared to the qos-hint-split-value in the SDP offer.

– If the SDP offerer qos-hint-split-value is larger than what the SDP answerer considers feasible (i.e., qos-hint-end-to-end-value in the SDP offer minus the corresponding qos-hint-split-value from the SDP offer is smaller than feasible across the SDP answerer’s local link), the SDP answerer may include a qos-hint-split-value in the SDP answer that is larger than the qos-hint-end-to-end-value included in the SDP offer minus the corresponding qos-hint-split-value from the SDP offer, but the included value shall then also be less than or equal to half of the qos-hint-end-to-end-value included in the SDP answer. The exception to that rule is when the qos-hint-end-to-end-value included in the SDP answer is less than the qos-hint-end-to-end-value included in the SDP offer (see also above), in which case the qos-hint-split-value should instead be the qos-hint-end-to-end-value included in the SDP answer minus the corresponding qos-hint-split-value from the SDP offer, unless the SDP answerer cannot support such qos-hint-split-value. In that case the included value shall be less than or equal to half of the qos-hint-end-to-end-value included in the SDP answer.

6.2.7.4.5 Offerer receiving an SDP answer

If there is no "a=3gpp-qos-hint" line included in a media description in the SDP answer, it shall be interpreted as the answerer either does not support the attribute at all or cannot accept any of the qos-hint-property values from the offer, and QoS hints will therefore not be used for that media description.

If a qos-hint with an unknown or malformed qos-hint-property or qos-hint-value is received in an SDP answer, that qos-hint shall be ignored, and shall neither cause the "a=3gpp-qos-hint" line nor the entire media description to be rejected (e.g. by issuing a new SDP offer with that "m=" line disabled).

A "loss" property value received in the SDP answer that is identical to the SDP offer shall be taken as the SDP answerer accepting to share end-to-end packet loss budget equally. A "loss" property value received in the SDP answer that is larger than in the SDP offer shall be taken as the SDP answerer being incapable of sharing end-to-end packet loss budget with the proposed split from the SDP offer while keeping the end-to-end packet loss value that was included in the SDP offer (see illustrative examples in Figures 6.2.7.4.4-1 and 6.2.7.4.4-2). A "loss" property value received in the SDP answer that is smaller than in the SDP offer shall be taken as the SDP answerer requiring a lower end-to-end packet loss for the media.

A "latency" property value received in the SDP answer that is identical to the SDP offer shall be taken as the SDP answerer accepting to share end-to-end packet latency budget equally. A "latency" property value received in the SDP answer that is larger than in the SDP offer shall be taken as the SDP answerer being incapable of sharing end-to-end packet latency budget with the proposed split from the SDP offer while keeping the end-to-end packet latency value that was included in the SDP offer (the principles in the illustrative examples for "loss" in Figures 6.2.7.4.4-1 and 6.2.7.4.4-2 apply also for "latency"). A "latency" property value received in the SDP answer that is smaller than in the SDP offer shall be taken as the SDP answerer requiring a lower end-to-end latency for the media.

If a qos-hint with an unknown or malformed qos-hint-split-method or qos-hint-split value is received in an SDP answer, the entire qos-hint-split shall be ignored, and shall neither cause the "a=3gpp-qos-hint" line nor the entire media description to be rejected (e.g. by issuing a new SDP offer with that "m=" line disabled).

If no qos-hint-split is included in the received SDP answer and if no qos-hint-split was included in the SDP offer, the SDP answerer has accepted the offered default, equal split.

If a qos-hint-split is included in the received SDP answer with a qos-split-hint-value equal to the qos-hint-end-to-end-value in the SDP answer minus the corresponding qos-hint-split-value from the SDP offer, the SDP answerer has accepted the qos-hint-split proposed by the SDP offer.

If a qos-hint-split is included in the received SDP answer with a qos-split-hint-value different than the above, the SDP answerer has modified the qos-hint-split-value allocation from the SDP offer, regardless if that qos-hint-split-value was explicit or not in the SDP offer, and the resulting split is described by the SDP answer.

Table 6.2.7.4.5-1 below shows what resulting QoS hint values from the SDP answer that can be used during resource reservation at the SDP offerer and SDP answerer sides, respectively, for each of the defined qos-hint-property-values.

Table 6.2.7.4.5-1: Resulting summary of QoS hint values from SDP answer

QoS hint condition	SDP offerer side part	SDP answerer side part
No qos-hint-split included	0.5 * qos-hint-end-to-end-value	0.5 * qos-hint-end-to-end-value
qos-hint-split included	qos-hint-end-to-end-value – qos-hint-split-value	qos-hint-split-value

NOTE: The following non-authoritative mapping of the qos-hint-end-to-end-values (no explicit split applied, for simplicity) to, for example, the 5 defined FLUS-related 5QI/QCI would then be possible for the PCF/PCRF (other mappings are possible, left for the originating and terminating policy control to decide, and need not even be exactly the same for originating and terminating network for a UE-to-UE session):

loss=0.0002;latency=300 => QCI 71 (150 ms, 10^-6)
loss=0.02;latency=600 => QCI 72 (300 ms, 10^-4)
loss=0.000002;latency=600 => QCI 73 (300 ms, 10^-8)
loss=0.000002;latency=1000 => QCI 74 (500 ms, 10^-8)
loss=0.02;latency=1000 => QCI 76 (500 ms, 10^-4)

6.2.8 Delay Budget Information (DBI) Signaling

An MTSI client may support Delay Budget Information (DBI) signaling as specified in sub-clause 7.3.8.

An MTSI client supporting DBI shall offer ‘Delay Budget Information’ (DBI) signaling in SDP for all media streams containing speech. An MTSI client supporting DBI may also offer ‘Delay Budget Information’ (DBI) signaling in SDP for all media streams containing video. DBI shall be offered by including the a=rtcp-fb attribute [40] with the DBI type under the relevant media line scope. The DBI type in conjunction with the RTCP feedback method shall be expressed with the following parameter: 3gpp-delay-budget. A wildcard payload type ("*") shall be used to indicate that the RTCP feedback attribute for DBI signaling applies to all payload types. Here is an example usage of this attribute to signal DBI relative to a media line based on the RTCP feedback method:

a=rtcp-fb:* 3gpp-delay-budget

The IANA registration information on the new RTCP feedback type for DBI signaling is provided in Annex R.2.

The ABNF for rtcp-fb-val corresponding to the feedback type "3gpp-delay-budget" is given as follows:

rtcp-fb-val =/ "3gpp-delay-budget"

As described in sub-clause 7.3.8, DBI signalling involves RTCP feedback signalling to carry both (i) available additional delay budget from the MTSI receiver to the MTSI sender, and (ii) requested additional delay budget from the MTSI sender to the MTSI receiver.

Annex V.3 presents SDP examples on DBI signalling capability.

6.2.9 ANBR Support attribute "anbr"

Access network bitrate recommendation (ANBR) is described in clause 10.7. Use of ANBR with dynamic bitrate adaptation is described in clause 10.7.3 and related adaptation of sent and received media is described in clauses 10.7.3.2 and 10.7.3.3, respectively. At the radio signalling level, ANBR signaling capability, also known as RAN-assisted codec adaptation, is specified in TS 36.321 [157] for LTE access and TS 38.321 [166] for NR access respectively.

The media-level SDP attribute "anbr" is specified in this clause to indicate ANBR support. The MTSI client in terminal supporting "anbr" shall only signal this attribute in the SDP offer and answer if all of the following are true:

– MTSI client in terminal supports ANBR as described in clause 10.7, including the use of ANBR with dynamic bitrate adaptation as described in clause 10.7.3.

– The UE of the MTSI client in terminal is capable of RAN-assisted codec adaptation specified in TS 36.321 for LTE access and/or TS 38.321 for NR access. For LTE access, inclusion of "anbr" in the SDP indicates that the UE is able to query and receive ANBR information (for both downlink and uplink ANBR) from its eNB. Likewise, for NR access inclusion of this attribute indicates that the UE is able to query and receive ANBR information (for both downlink and uplink ANBR) from its gNB.

– The P-CSCF has indicated to the UE of the MTSI client in terminal its ability to handle this SDP attribute, as described in clause E.10 of TS 23.228 [167], and specified in TS 24.229 [7] through the respective SIP registration procedures via the corresponding feature capability indicator g.3gpp.anbr.

Signalling of ANBR capabilities in the SDP via "a=anbr" enables end-to-end coordination of ANBR capabilities across the UEs, access networks, and PCF/PCRF. In particular, such ANBR capability signalling can be useful for the PCF/PCRF when setting GBR<MBR bearers.

Here is an example use of the "a=anbr" attribute relative to a media line:

a=anbr

The IANA registration information for the "a=anbr" SDP attribute is provided in Annex M.8.

SDP examples on ANBR capability signalling are provided in Annex A.15.

6.2.10 Data channel

6.2.10.1 General

Support of data channel media is optional for an MTSI client and an MTSI client in terminal. For brevity, an MTSI client supporting data channel is henceforth denoted as a DCMTSI client or DCMTSI client in terminal, respectively.

To indicate support for the procedures in this clause, a DCMTSI client shall when including media feature tags as specified in TS 24.229 [7] include a +sip.app-subtype media feature tag, as specified by RFC 5688 [177], with a value of "webrtc-datachannel" (the application media format used by [172]), regardless of data channel media being part of the SDP or not.

One or more data channel SDP media descriptions formatted according to [172] may be added to the SDP, alongside other SDP media descriptions such as e.g. speech, video, and text. A data channel SDP media description must not be placed before the first SDP speech media description. SDP examples are provided in Annex A.17.

If data channels are used in a session, the session setup shall determine the applicable bandwidth limit(s) as defined in clause 6.2.5.

Multiple data channels may be mapped to a single data channel SDP media description, each with a corresponding "a=dcmap" SDP attribute and stream IDs that are unique within that media description. There is no limit to the number of data channels in an SDP media description, but the aggregate of all defined data channels must keep within the set bandwidth limit and care should be taken to avoid excessive SDP size. If the session is re-negotiated to include a changed number of data channels in an SDP media description, the bandwith limit may either be kept constant, changing the share of bandwidth available to each individual data channel, or the bandwidth limit may be changed to accommodate the changed number of data channels, keeping individual data channel bandwidth shares. Regardless of what approach is used when changing number of used data channels in a media description, the aggregate of all defined data channels must keep within the re-negotiated bandwidth limit.

If there is a need to use data channels with either different transport IP addresses, different UDP ports, or different SCTP ports, separate data channel SDP media descriptions must be used, as IP address, UDP port and SCTP port are all constant per SDP media description. Multiple SCTP associations for a single channel, commonly denoted as "multi-homing", defined in IETF RFC 4960 [173] for reasons of redundancy and basically using one destination transport address at a time, is not described for use with WebRTC data channel and must therefore not be used in this specification.

NOTE 1: The main reasons to not specify multi-homing are because it cannot use the needed separation of signalling paths for redundancy purposes in the applicable usage scenarios, and it is also not considered feasible when using SCTP on top of DTLS.

To ease data channel media implementation and ease interworking with WebRTC data channels, DCMTSI clients must support ICE Lite and may support full ICE [184], for data channel media. DCMTSI clients supporting full ICE must only use host candidate addresses. SDP "a=candidate" line host address information must match corresponding SDP "c=" and "m=" line information.

NOTE 2: In typical IMS deployments, it is expected that DCMTSI clients have no need to use STUN or TURN servers with ICE. This is in line with what constitutes an ICE Lite agent.

Data channel stream IDs below 1000 must be reserved for using the HTTP [73] protocol, henceforth denoted as "bootstrap data channels", to retrieve an HTML web page including JavaScript(s), and optionally image(s) and style sheet(s), henceforth denoted as a "data channel application". The data channel application accessible at the HTTP root ("/") URL through a bootstrap data channel describes the graphical user interface and the logic needed to handle any further data channel usage beyond the bootstrap data channel itself. The meaning of the "authority" (host) part of the URL and consequently the "Host" HTTP header are not defined, shall be ignored on reception, and shall be set to the empty value by a DCMTSI client in terminal.

The data channel application is created prior to the DCMTSI call where it is intended to be used, by means left out of scope for this specification. The data channel application workflow is depicted by Figure 6.2.10.1-1 below.

Figure 6.2.10.1-1: Data Channel Workflow

The data channel application is, referring to the numbered arrows in Figure 6.2.10.1-1:

1. Uploaded to the network, by the UE user or some other authorized party.

2. Stored in a data channel application repository in the network.

3. During the DCMTSI call where it should be used, retrieved from the repository.

4. Sent through a bootstrap data channel to the local UE A.

5. Sent through a bootstrap data channel to the remote UE B. This may happen in parallel with and rather independent of step 4.

6. Any additional data channels created and used by the data channel application itself are established (logically) between UE A and UE B. Data transmission on data channels shall not start until there is confirmation that both peers have instantiated the data channel, using the same procedures as described for WebRTC in section 6.5 of [172]. The traffic may effectively go through the Data Channel Server, e.g., when the bootstrap and end-to-end data channels have the same anchoring point. This traffic may pass across an inter-operator border if UE A and UE B belong to different operators’ networks.

The bootstrap data channel is not intended for use directly between DCMTSI clients in terminal. DCMTSI clients in terminal that receive HTTP requests on a bootstrap data channel shall ignore such request and shall update the session by removing the SDP "a=dcmap" line with the stream ID where such HTTP request was received, and closing that stream ID.

The data channel application sent in a bootstrap data channel may be updated at any time, automatically or interactively, using normal HTTP procedures.

A bootstrap data channel must be configured as ordered, reliable, with normal SCTP multiplexing priority. The bootstrap data channel shall use a well-defined sub-protocol. The sub-protocol should be HTTP (not encapsulating HTTP in TCP), represented by the following, example SDP "a=dcmap" line, which therefore must be present in each data channel media description in an SDP offer from a DCMTSI client in terminal:

a=dcmap:0 subprotocol="http"

When the HTTP subprotocol is used, any other data channels used by the data channel application JavaScript(s) sent in the bootstrap data channel must be represented in an updated SDP as additional "a=dcmap" lines with stream ID values starting from 1000, using stream ID numbers from the JavaScript(s).

There are multiple, possible providers of data channel applications. In Figure 6.2.10.1-1, assume that UE A is local to the operator hosting the data channel server. Further assume that UE B belongs to a different operator (remote). The user of UE A can create and use data channel applications (steps 1-4), which can also be sent to UE B (step 5). Similarly, some other authorized part associated with UE A’s operator can create data channel applications for use by UE A (steps 1-4), which can also be sent to UE B (step 5). For simplicity, there’s no data channel server and data channel application repository depicted for UE B in Figure 6.2.10.1-1, but those could be present in a more general case. Seen from the perspective of a single UE, there are then at least four possible data channel application providers:

1. The local UE user.

2. Other authorized parties associated with the local network (e.g. the local operator).

3. The remote UE user.

4. Other authorized parties associated with the remote network (e.g. the remote operator).

The HTML web content making up a data channel application in each bootstrap data channel represents a different context of user interaction and should open in a separate tab, or some corresponding user interface construct, but the details are out of scope for this specification and left open for individual implementations. It must be possible to use and navigate between different data channel applications from different bootstrap data channels with different stream IDs that are open simultaneously.

Table 6.2.10.1-2 describes a mandatory mapping between stream ID and bootstrap channel data channel application content sources, as seen from a single (local) DCMTSI client in terminal, each of which shall be listed as separate "a=dcmap" lines with "http" subprotocol in SDP when the DCMTSI client in terminal supports receiving data channel application content from that source.

Table 6.2.10.1-2: Bootstrap Data Channel Content Sources

Stream ID	Content Source
0	Local network provider
10	Local user
100	Remote network provider
110	Remote user

NOTE 3: When the local user has defined and stored multiple, different data channel applications in the local data channel application repository, the local network provider may provide functionality in the stream ID 0 data channel application that enables a dynamic choice of which user-defined data channel application to use with stream ID 10 in the DCMTSI call.

Figure 6.2.10.1-3, referring to Figure 6.2.10.1-1 and Table 6.2.10.1-2, is depicting the stream IDs used for distribution of a data channel application owned by UE A from its local data channel repository to both UE A (stream ID 10) and its remote UE B (stream ID 110).

Figure 6.2.10.1-3: Distribution of local data channel application to both UE

6.2.10.2 Generating SDP offer

A DCMTSI client in terminal may include a data channel media description for the "bootstrap" data channels in the initial SDP offer, as described above and according to [172] [184]. A DCMTSI client in terminal may add or disable (by setting port 0, as for RTP media) additional data channel media descriptions as needed in subsequent SDP offers.

A DCMTSI client in terminal that desires to use data channels with stream IDs from a data channel application retrieved from its local "bootstrap" data channel stream ID 0 or 10, shall initiate a subsequent SDP offer after the initial SDP offer, opening those data channels by adding corresponding "a=dcmap" and (optionally) "a=dcsa" lines. A DCMTSI client in terminal that retrieves a data channel application from a stream ID different than 0 or 10 (e.g. a data channel application from the peer), shall not initiate any subsequent offer to open data channels used by that data channel application.

A data channel media description with specific loss or latency requirements should use "a=3gpp-qos-hint" in the SDP offer, as detailed in section 6.2.7.4. If subsequent SDP offers or answers adds data channels with more strict loss or latency requirements that cannot be met by keeping current "a=3gpp-qos-hint" and providing suitable SCTP "a=dcmap" parameters, the existing "a=3gpp-qos-hint" should be modified accordingly. Similarly, if subsequent SDP offers or answers closes (removes) data channels that are known to be the limiting factor for choosing the existing "a=3gpp-qos-hint", a more relaxed "a=3gpp-qos-hint" should be chosen to better fit the remaining data channels.

6.2.10.3 Generating SDP answer

An answering DCMTSI client in terminal may accept an SDP offer with data channel as described by [172] [184].

An answering DCMTSI client in terminal that desires to reject the entire SCTP association for all offered data channels shall set the port to 0 (zero) on the corresponding "m=application" line in SDP, as described in [172]. An SCTP association that initially, or as a result of session modification, has no open data channels ("a=dcmap" lines) should be rejected or closed by modifying the session, setting port number to 0 (zero).

An answering DCMTSI client in terminal that desires to accept some offered data channels and reject others shall indicate this by removing the non-desired data channel "a=dcmap" and "a=dcsa" lines from the SDP answer, as described in [172]. The DCMTSI client in terminal accepting a data channel must also accept the corresponding, supported "bootstrap" data channels with stream ID <1000 (e.g. a=dcmap:0 …).

6.2.10.4 Receiving SDP answer

An offering DCMTSI client in terminal receiving an SDP answer where the data channel SCTP association is accepted (port is not 0) may use any offered stream ID that has a corresponding "a=dcmap" line in the SDP answer, as described by section 6.5 in [172]. Data channels with "a=dcmap" lines in the SDP offer that are not included in the SDP answer must be considered as rejected and shall not be used, as described by section 6.5 in [172].

6.2.11 Still Images

If still images are used in a session, then the imageseq SDP attribute shall be present in the offer of the corresponding video media session. The syntax is defined below

imageseq = "a=imageseq:" PT [SP item_count]

PT is the payload type number to which the attribute applies to as indicated by the "m=video" line. Optional parameters can be ignored by an MTSI client if not understood. The parameters have the following semantics:

item_count: provides the number of images in the corresponding image collection or image sequence. For ITT4RT, the parameter is informational from the ITT4RT-Tx client to the ITT4RT-Rx client. An ITT4RT-Rx client shall not include item_count in the SDP offer. If an ITT4RT-Rx client receives item_count in the SDP offer, it should include the same value in the response.

An MTSI client that supports still images shall support long and varying time distances between RTP time stamps. An MTSI client that supports still images should support the HEVC display orientation SEI message as defined in clause D.3.17 and HEVC VUI parameters. An MTSI client that supports and desires to use still images shall in the SDP offer media description of such a bitstream include the "a=imageseq" attribute. An MTSI client that supports still images and that receives the "a=imageseq" attribute in the SDP offer shall keep the "a=imageseq" attribute in the corresponding media description in the SDP answer.

An MTSI client that doesn’t support still images shall remove the image attribute in the answer. An MTSI client that sent the "imageseq" attribute in the SDP offer but does not receive it in the corresponding SDP answer, shall not use still images. In such case, the sender should transmit the still image as a regular continuous video stream that conforms to the requirements in 7.4.3 for an HEVC compressed video stream. If that is not possible, the sender shall initiate a session re-negotiation to remove the still image media line.

The "imageattr" attribute as specified in IETF RFC 6236 [76] shall be supported and shall indicate the image size.

6.3 Session control procedures

Addition and removal of media components shall be performed based on the SDP-based offer-answer model as specified in RFC 3264 [58].

During session renegotiation for adding or removing media components, the SDP offerer should continue to use the same media (m=) line(s) from the previously negotiated SDP for the media components that are not being added or removed.

An MTSI client in terminal may support multiple media components including media components of the same media type. An MTSI client in terminal may support adding one or more media components to an on-going session which already contains a media component of the same media type. If an MTSI client in terminal needs to have multiple media components of the same media type in a single MTSI session, then the MTSI client in terminal should use the SDP content attributes as defined in [81] for identifying different media components.

SDP examples for adding a second video stream to an ongoing video telephony session and removing a video stream from an ongoing video telephony session are given in Annex A.11.

The content attribute can be used in combination with the group attributes defined in RFC 3388 [48] and also in combination with the synchronization attributes defined in Clause 6.2.6, for example to identify two (or more) media components are related to each other and if synchronization is needed.