Content for  TS 26.114  Word version:  18.1.0

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.

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 RFC 6236 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. 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 RFC 6236, 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.

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

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 RFC 4573. 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: 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: 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: 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 [RFC 5234]
  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: 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: The number 7 in the example may be replaced with any number in the range 1-14.

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.

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