The IMS messaging service is described in TS 26.141. The description of IMS messaging in clauses 1-6 of TS 26.141 is applicable for MSRP-transported media in MTSI. The MSRP transport itself is described in TS 24.247. All statements in TS 26.141 regarding IMS messaging are valid for MSRP transported media in MTSI including the status of the statement (shall, should, may). Any differences between IMS messaging in TS 26.141 and MSRP transported media in MTSI are described in clause 13a.2.

In this section media layer behaviour is specified for relevant supplementary services. The supplementary services included in MTSI are described in TS 24.173. The requirements on the codec support and the data transport are identical to those listed in clause 5.2 and clause 7. These requirements are listed here due to the fact that there might be other media-influencing nodes in MTSI whose behaviour is not explicitly covered by other parts of the present document. The recommended behaviour described in the following sections is valid for MTSI clients, i.e. all session IP end-points; terminals, MTSI media gateways and other 3GPP network nodes acting as IP endpoints in MTSI sessions.

Any implementation of a supplementary service which affects media or media handling, e.g. such as media creation, media rendering and media manipulation, shall meet the same requirements as a MTSI client in terminal regarding codec support and codec usage. Where applicable,, speech codecs shall be supported according to clause 5.2.1, video according to clause 5.2.2 and text according to clause 5.2.3. Similarly, the configuration and the transport of the media in any implementation of a supplementary service which affects media or media handling shall be done according to clause 7.

Whenever a supplementary service includes a hold procedure according to RFC 3264, e.g. when using the HOLD supplementary service, the media flow is changed in terms of the session flow attribute (e.g. changing the session attribute "sendrecv" into "sendonly" or "recvonly" or "inactive" and then back again). When this occurs, any involved media-originating or media-terminating node should take measures to ensure that the transitions between the different media flow states in the session occur with minimal impact on the media quality. When a full-duplex session has put the media flow on hold (see Section 8.4 in RFC 3264), the media flow has been changed into a unidirectional flow through changing the session attribute into either "sendonly" or "recvonly". When resuming the session, it is restored to full duplex by changing the flow attributes back into "sendrecv" from "sendonly" and "recvonly". In this case, the encoder and decoder states in the MTSI clients may not be aligned and a state mismatch could occur. This would result in media quality degradation. Therefore, the following actions are recommended whenever the media session is not being put on hold anymore and the session is restored to full duplex:

• for speech media, the speech decoders should be reset;
• for video media, the video encoders should start the updated session with a full infra refresh even if the previously allocated encoders are still active and no infra refresh is scheduled to be sent.

The MTSI client in the terminal may use the OMA-DM solution specified in this clause for enhancing the SDP negotiation and resource reservation process. If a MTSI client in the terminal uses this feature, it is mandatory for the MTSI client in the terminal to implement the Management Object (MO) as described in this clause. The 3GPP MTSINP (MTSI Network Preference) MO defined in this clause may be used to manage the QoS profile settings which express the network preference for the MTSI client in the terminal. The MO covers parameters that the MTSI client in the terminal could make use of in SDP negotiation and resource reservation process. If a MTSI client in the terminal supports the feature, the usage of the MO includes:

1. During SDP negotiation process, MTSI client in the terminal should start SDP negotiation based on the MO parameters.
2. During resource reservation process, MTSI client in the terminal should start QoS negotiation based on the MO parameters.

The following parameters in MTSI should be included in the Management Object (MO): Speech Video Real Time text Indication of the priority when there are more than one alternative for a media type is included. Version numbering is included for possible extending of MO. The Management Object Identifier shall be: urn:oma:mo:ext-3gpp-mtsinp:1.0. Protocol compatibility:

The following nodes and leaf objects in Figure 15.1 shall be contained under the 3GPP_MTSINP node if a MTSI client in the terminal support the feature described in this clause (information of DDF for this MO is given in Annex H):

Node: /<X> This interior node specifies the unique object id of a MTSI network preferences management object. The purpose of this interior node is to group together the parameters of a single object.

• Occurrence: ZeroOrOne
• Format: node
• Minimum Access Types: Get

The following interior nodes shall be contained if the MTSI client in the terminal supports the "MTSI network preferences Management Object". /<X>/Speech The Speech node is the starting point of the speech codec definitions (if any speech codec are available)

• Occurrence: ZeroOrOne
• Format: node
• Minimum Access Types: Get

/<X>/Speech/<X> This interior node is used to allow a reference to a list of speech codec objects.

• Occurrence: OneOrMore
• Format: node
• Minimum Access Types: Get

/<X>/Speech/<X>/ID This leaf node represents the identification number of a set of parameters for speech session.

• Occurrence: ZeroOrOne
• Format: int
• Minimum Access Types: Get

/<X>/Speech/<X>/TAG This leaf node represents the identification tag of a set of parameters for speech session. It is recommended to have at least a node, for example, ID, TAG, or implementation-specific ones, for the identification purpose such that each set of parameters can be distinguished and accessed.

• Occurrence: ZeroOrOne
• Format: chr
• Minimum Access Types: Get

/<X>/Speech/<X>/Priority This leaf represents the priority of a set of parameters for speech session. Lower value means higher priority and the value is used in the terminal for client initiated QoS handling. The priority uses a 16 bit unsigned integer.

• Occurrence: ZeroOrOne
• Format: int
• Minimum Access Types: Get
• Values: Zero or higher

/<X>/Speech/<X>/IPver This leaf represents the version of the Internet Protocol used in the session.

• Occurrence: One
• Format: chr
• Minimum Access Types: Get
• Values: "IPv4", "IPv6"

/<X>/Speech/<X>/Codec This leaf gives the MIME subtype name of speech codec. This leaf is preferably pre-configured by the device.

• Occurrence: One
• Format: chr
• Minimum Access Types: Get
• Values: MIME subtype name of speech codec, e.g., "AMR", "AMR-WB", "EVS".

The value "AMR" refers to the AMR speech codec as defined in 3GPP. The value "AMR-WB" refers to the AMR-WB speech codec as defined in 3GPP. The value "EVS" refers to the EVS speech codec as defined in 3GPP. /<X>/Speech/<X>/Bandwidth This interior node is used to allow a reference to a list of parameters related to speech bandwidth assignment.

• Occurrence: One
• Format: node
• Minimum Access Types: Get
• Values: positive integer

/<X>/Speech/<X>/Bandwidth/AS This leaf gives the preferred speech codec bandwidth by the network for the bearer set-up, including RTP/UDP/IP headers. It provides the value for "b=AS" line for speech part used in the end-to-end SDP negotiation process, which represents the bit rate in kbits/sec.

• Occurrence: ZeroOrOne
• Format: int
• Minimum Access Types: Get

/<X>/Speech/<X>/Bandwidth/RS This leaf provides the value for "b=RS" line for speech part used in the end-to-end SDP negotiation process, which represents the bit rate in bits/sec.

• Occurrence: ZeroOrOne
• Format: int
• Minimum Access Types: Get

/<X>/Speech/<X>/Bandwidth/RR This leaf provides the value for "b=RR" line for speech part used in the end-to-end SDP negotiation process, which represents the bit rate in bits/sec.

• Occurrence: ZeroOrOne
• Format: int
• Minimum Access Types: Get

/<X>/Speech/<X>/RateSet This leaf node represents a list of bit rates used by speech codec. Depending on the codec, each value can be understood as either the highest rate or the average rate. The entries in the list may either be generic, i.e., usable for any codec, but can also be codec-specific. The default usage is the generic list where the bit rates in bits/sec are included, e.g., "5000, 6000, 7500, 12500". A codec-specific list may indicate the desired modes. For example, in the case of AMR, the list could be "0, 2, 4, 7".

• Occurrence: ZeroOrOne
• Format: chr

Minimum Access Types: Get

/<X>/Speech/<X>/EVS

This interior node is used to allow a reference to a list of parameters related to the configuration of EVS speech codec.

• Occurrence: ZeroOrOne
• Format: node
• Minimum Access Types: Get

/<X>/Speech/<X>/EVS/Br

This leaf gives the value of br, a parameter representing the range or value of bit-rate for EVS speech codec defined in TS 26.445.

• Occurrence: ZeroOrOne
• Format: chr
• Minimum Access Types: Get

/<X>/Speech/<X>/EVS/Bw

This leaf gives the value of bw, a parameter representing the range or value of bandwidth for EVS speech codec defined in TS 26.445.

• Occurrence: ZeroOrOne
• Format: chr
• Minimum Access Types: Get

/<X>/Speech/<X>/ConRef

This node specifies a reference to QoS parameters Management Object. The interior node's leaf nodes specify the network preferred QoS parameters as defined in TS 24.008 and they should be used in the bearer request when client initiated QoS happen. Implementation specific MO may be referenced.

• Occurrence: ZeroOrOne
• Format: chr
• Minimum Access Types: Get

/<X>/Speech/<X>/Ext

The Ext is an interior node where the vendor specific information can be placed (vendor meaning application vendor, device vendor etc.). Usually the vendor extension is identified by vendor specific name under the ext node. The tree structure under the vendor identified is not defined and can therefore include one or more un-standardized sub-trees.

• Occurrence: ZeroOrOne
• Format: node
• Minimum Access Types: Get

/<X>/Video

The Video node is the starting point of the video codec definitions (if any video codec are available)

• Occurrence: ZeroOrOne
• Format: node
• Minimum Access Types: Get

/<X>/Video/<X>

This interior node is used to allow a reference to a list of video codec objects.

• Occurrence: OneOrMore
• Format: node
• Minimum Access Types: Get

/<X>/Video/<X>/ID

This leaf node represents the identification number of a set of parameters for video session.

• Occurrence: ZeroOrOne
• Format: int
• Minimum Access Types: Get

/<X>/Video/<X>/TAG

This leaf node represents the identification tag of a set of parameters for video session. It is recommended to have at least a node, for example, ID, TAG, or implementation-specific ones, for the identification purpose such that each set of parameters can be distinguished and accessed.

• Occurrence: ZeroOrOne
• Format: chr
• Minimum Access Types: Get

/<X>/Video/<X>/Priority

This leaf represents the priority of a set of parameters for speech session. Lower value means higher priority and the value is used in the terminal for client initiated QoS handling. The priority uses a 16 bit unsigned integer.

• Occurrence: ZeroOrOne
• Format: int
• Minimum Access Types: Get
• Values: Zero or higher

/<X>/Video/<X>/IPver

This leaf represents the version of the Internet Protocol used in the session.

• Occurrence: One
• Format: chr
• Minimum Access Types: Get
• Values: "IPv4", "IPv6"

/<X>/Video/<X>/Codec

This leaf gives the MIME subtype name of video codec. This leaf is preferably pre-configured by the device.

• Occurrence: One
• Format: chr
• Minimum Access Types: Get
• Values: MIME subtype name of video codec, e.g., "H264", "H265".

The values "H264" and "H265" refer to the H.264 (AVC) and H.265 (HEVC) codecs as defined by MPEG and ITU respectively. The usage of H.264 (AVC) and H.265 (HEVC) codecs (profiles, levels etc) is described in the document TS 26.114 Chapter 5.5.2.

/<X>/Video/<X>/Bandwidth

This interior node is used to allow a reference to a list of parameters related to video bandwidth assignment.

• Occurrence: One
• Format: node
• Minimum Access Types: Get

/<X>/Video/<X>/Bandwidth/AS

This leaf gives the preferred video codec bandwidth by the network for the bearer set-up, including RTP/UDP/IP headers. It provides the value for "b=AS" line for video part used in the end-to-end SDP negotiation process, which represents the bit rate in kbits/sec.

• Occurrence: ZeroOrOne
• Format: int
• Minimum Access Types: Get

/<X>/Video/<X>/Bandwidth/RS

This leaf provides the value for "b=RS" line for video part used in the end-to-end SDP negotiation process, which represents the bit rate in bits/sec.

• Occurrence: ZeroOrOne
• Format: int
• Minimum Access Types: Get

/<X>/Video/<X>/Bandwidth/RR

This leaf provides the value for "b=RR" line for video part used in the end-to-end SDP negotiation process, which represents the bit rate in bits/sec.

• Occurrence: ZeroOrOne
• Format: int
• Minimum Access Types: Get

/<X>/Video/<X>/Bandwidth/Source

This leaf gives the preferred video encoding bandwidth in kbits/sec.

• Occurrence: ZeroOrOne
• Format: float
• Minimum Access Types: Get

/<X>/Video/<X>/Bandwidth/PayloadSize

This leaf gives the preferred payload size for video, excluding payload header, which represents the amount of encoded video data in bytes transported over a RTP packet.

• Occurrence: ZeroOrOne
• Format: int
• Minimum Access Types: Get

/<X>/Video/<X>/ProfileLevel

This interior node is used to allow a reference to a list of parameters related to the profile and level of video codec.

• Occurrence: One
• Format: node
• Minimum Access Types: Get

/<X>/Video/<X>/ProfileLevel/H264

This leaf gives the profile-level-id of H.264 (AVC) video codec, which indicates the profile that the codec supports and the highest level supported for the signaled profile [24], RFC 6184.

• Occurrence: ZeroOrOne
• Format: chr
• Minimum Access Types: Get

/<X>/Video/<X>/ProfileLevel/H265

This interior node is used to allow a reference to a list of parameters related to the profile and level of H.265 (HEVC) video codec.

• Occurrence: ZeroOrOne
• Format: node
• Minimum Access Types: Get

/<X>/Video/<X>/ProfileLevel/H265/Profile

This leaf gives the value of profile-id, a parameter representing the profile of H.265 (HEVC) video codec defined in [119], RFC 7798.

• Occurrence: One
• Format: int
• Minimum Access Types: Get

/<X>/Video/<X>/ProfileLevel/H265/Level

This leaf gives the value of level-id, a parameter representing the level of H.265 (HEVC) video codec defined in [119], RFC 7798. Level indicates the maximum computational complexity supported by the offerer in performing decoding for the given profile.

• Occurrence: One
• Format: int
• Minimum Access Types: Get

/<X>/Video/<X>/ImageAttr

This interior node is used to allow a reference to a list of parameters related to the image sizes supported or preferred, specified with the "imageattr" attribute. (see clause A.4)

• Occurrence: ZeroOrOne
• Format: node
• Minimum Access Types: Get

/<X>/Video/<X>/ImageAttr/Send

This leaf gives the supported image sizes for the send direction. The value is a string such as "176, 144, 224, 176, 272, 224, 320, 240" which means four image sizes, 176x144, 224x176, 272x224, and 320x240 are supported for the send direction. The maximum image size in this leaf shall not exceed the maximum size limited by the offered codec level.

• Occurrence: One
• Format: chr
• Minimum Access Types: Get

/<X>/Video/<X>/ImageAttr/Recv

This leaf gives the supported image sizes and their preferences for the receive direction. The value is a string such as "176, 144, 0.5, 224, 176, 0.5, 272, 224, 0.6, 320, 240, 0.5" which means four image sizes, 176x144, 224x176, 272x224, and 320x240 are supported for the receive direction but 272x224 is preferred since it might fit the available space on the display of the receiver better than the other image sizes. The maximum image size in this leaf shall not exceed the maximum size limited by the offered codec level. The value representing the level of preference by the offerer, defined in RFC 6236, is between 0 and 1 inclusive and 0.5 by default.

• Occurrence: One
• Format: chr
• Minimum Access Types: Get

/<X>/Video/<X>/ConRef

This node specifies a reference to QoS parameters Management Object. The interior node's leaf nodes specify the network preferred QoS parameters as defined in TS 24.008 and they should be used in the bearer request when client initiated QoS happen. Implementation specific MO may be referenced.

• Occurrence: ZeroOrOne
• Format: chr
• Minimum Access Types: Get

/<X>/Video/<X>/Ext

The Ext is an interior node where the vendor specific information can be placed (vendor meaning application vendor, device vendor etc.). Usually the vendor extension is identified by vendor specific name under the ext node. The tree structure under the vendor identified is not defined and can therefore include one or more un-standardized sub-trees.

• Occurrence: ZeroOrOne
• Format: node
• Minimum Access Types: Get

/<X>/Text

The Text node is the starting point of the real time text codec definitions (if the real time text codec is available).

• Occurrence: ZeroOrOne
• Format: node
• Minimum Access Types: Get

/<X>/Text/<X>

This interior node is used to allow a reference to the real time text codec objects.

• Occurrence: OneOrMore
• Format: node
• Minimum Access Types: Get

/<X>/Text/<X>/ID

This leaf node represents the identification number of a set of parameters for text session.

• Occurrence: ZeroOrOne
• Format: int
• Minimum Access Types: Get

/<X>/Text/<X>/TAG

This leaf node represents the identification tag of a set of parameters for text session. It is recommended to have at least a node, for example, ID, TAG, or implementation-specific ones, for the identification purpose such that each set of parameters can be distinguished and accessed.

• Occurrence: ZeroOrOne
• Format: chr
• Minimum Access Types: Get

/<X>/Text/<X>/Priority

This leaf represents the priority of a set of parameters for text session. Lower value means higher priority and the value is used in the terminal for client initiated QoS handling. The priority uses a 16 bit unsigned integer.

• Occurrence: ZeroOrOne
• Format: int
• Minimum Access Types: Get
• Values: Zero or higher

/<X>/Text/<X>/IPver

This leaf represents the version of the Internet Protocol used in the session.

• Occurrence: One
• Format: chr
• Minimum Access Types: Get
• Values: "IPv4", "IPv6"

/<X>/Text/<X>/TextFormat

This leaf node represents the MIME subtype name of text conversation protocol. The value "t140" refers to T.140 defined in ITU-T [26], [27].

• Occurrence: ZeroOrOne
• Format: chr
• Minimum Access Types: Get
• Values: MIME subtype name of the text conversation protocol, e.g., "t140"

/<X>/Text/<X>/Bandwidth

This interior node is used to allow a reference to a list of parameters related to text bandwidth assignment.

• Occurrence: One
• Format: node
• Minimum Access Types: Get

/<X>/Text/<X>/Bandwidth/AS

This leaf provides the value for "b=AS" line for text part used in the end-to-end SDP negotiation process, which represents the bit rate in kbits/sec.

• Occurrence: ZeroOrOne
• Format: int
• Minimum Access Types: Get

/<X>/Speech/<X>/Bandwidth/RS

This leaf provides the value for "b=RS" line for text part used in the end-to-end SDP negotiation process, which represents the bit rate in bits/sec.

• Occurrence: ZeroOrOne
• Format: int
• Minimum Access Types: Get

/<X>/Speech/<X>/Bandwidth/RR

This leaf provides the value for "b=RR" line for text part used in the end-to-end SDP negotiation process, which represents the bit rate in bits/sec.

• Occurrence: ZeroOrOne
• Format: int
• Minimum Access Types: Get

/<X>/Text/<X>/RedundancyLevel

This leaf node represents the level of redundancy when redundancy is used with T.140 text.

• Occurrence: ZeroOrOne
• Format: int
• Minimum Access Types: Get
• Values: 0, 100, 200, 300

/<X>/Text/<X>/SamplingTime

This leaf node, defined in clause 9.4, represents the period for which text may be buffered before transmission. Buffering time, defined in RFC 4103, has an identical meaning as this node, i.e., the shortest period between text transmissions. Default value is 300 ms.

• Occurrence: ZeroOrOne
• Format: int
• Minimum Access Types: Get

/<X>/Text/<X>/ConRef

This node specifies a reference to QoS parameters Management Object. The interior node's leaf nodes specify the network preferred QoS parameters as defined in TS 24.008 and they should be used in the bearer request when client initiated QoS happen. Implementation specific MO may be referenced.

• Occurrence: ZeroOrOne
• Format: chr
• Minimum Access Types: Get

/<X>/Text/<X>/Ext

The Ext is an interior node where the vendor specific information can be placed (vendor meaning application vendor, device vendor etc.). Usually the vendor extension is identified by vendor specific name under the ext node. The tree structure under the vendor identified is not defined and can therefore include one or more un-standardized sub-trees.

• Occurrence: ZeroOrOne
• Format: node
• Minimum Access Types: Get

/<X>/Ext

The Ext is an interior node where the vendor specific information can be placed (vendor meaning application vendor, device vendor etc.). Usually the vendor extension is identified by vendor specific name under the ext node. The tree structure under the vendor identified is not defined and can therefore include one or more un-standardized sub-trees.

• Occurrence: ZeroOrOne
• Format: node
• Minimum Access Types: Get

The examples below are configurations of 3GPP MTSINP MO for selected speech, text, and video sessions in Annex A. An example of SDP offer for speech session is shown in Table A.6.1, which includes two RTP payload types for AMR-NB. Parameter values in Table 15.1 may apply to both payload types and additional SDP parameters such as max-red may be included under the Ext node as vendor extensions. Depending on the implementation, two sets of session parameters may be defined for the two payload types respectively.

An example configuration of MTSINP for video session is shown in Table 15.3, which includes the RTP payload types for H.264. Although the "b=AS" value can also be computed with the Source and PayloadSize nodes, a different value with appropriate implementation margin can be directly assigned to the AS node. If the AS, Source, and PayloadSize nodes are defined together, the AS node value should be used for setting "b=AS". In Table 15.3, the "b=AS" values of 315, for H.264, are computed assuming IPv4 addressing. Note that the Priority node of H.264 is assigned values of 5, which shows that depending on service policy, parameters sets of lower priority may be preferred in the construction of SDP offer. If the ImageAttr node is to be defined, the maximum image size in either the Send or Recv node shall not exceed the maximum size limited by the offered codec level, which is 352x288 for Baseline profile at level 1.1.

An example of SDP offer for video session is shown in Table A.4.4b, which includes a RTP payload type for H.264. Although the "b=AS" value can also be computed with the Source and PayloadSize nodes, a different value with appropriate implementation margin can be directly assigned to the AS node. If the AS, Source, and PayloadSize nodes are defined together, the AS node value should be used for setting "b=AS". In Table 15.3, the "b=AS" values of 315 and 57 kbps, for H.264 and H.263 respectively, are computed assuming IPv4 addressing. Note that the Priority nodes of H.264 and H.263 are assigned values of 5 and 3 respectively, which shows that depending on service policy, parameters sets of lower priority may be preferred in the construction of SDP offer. If the ImageAttr node is to be defined, as for H.264 in Table A.4.10a, the maximum image size in either the Send or Recv node shall not exceed the maximum size limited by the offered codec level, which is 352x288 for Baseline profile at level 1.1.