Subject: [MMUSIC] SDP Directorate Review: draft-ietf-payload-rtp-h265-13.txt

From: Flemming Andreasen <[email-masked]>
Date: Fri, 12 Jun 2015 12:44:05 -0400

Hi

I am the assigned SDP directorate reviewer for draft-ietf-payload-rtp-h265 and I have reviewed the -13 version. For background on the SDP directorate, please see the FAQ at

     http://www.ietf.org/iesg/directorate/sdp.html

Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Summary:
---------
The document does not define any new SDP attributes and as such it does not fall within the typical scope of SDP directorate reviews. The document does however define a number of parameters for use in SDP in the form of media format ("a=fmtp") parameters, including support for these as source-specific parameters (per RFC5576). The review of the document was performed to ensure that the "fmtp" parameters defined are indeed reasonably defined as fmtp parameters and that they do not interfere with other SDP related standards and design principles.

Note that this review does not attempt to review the overall specification for technical accuracy above and beyond the SDP-related aspects described above. In particular, this review does not attempt to evaluate the technical accuracy of the fmtp-parameters defined as this requires more detailed H.265 knowledge and falls under the scope of the PAYLOAD WG.

 From an SDP point of view, and as the document notes in Section 4.3, there are interactions between the "multiple RTP streams over a single Media Transport (MRST)" mode defined and the Standards Track Bundle mechanism currently being defined in MMUSIC (seehttp://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/). From a signaling point of view, this overlap manifests itself in the form of the tx-mode fmtp parameter defined for the different transmission modes in Section 7.1. It would be highly desirable to clarify this overlap and provide procedures for how to deal with any inconsistencies between the two.

Another general comment is the lack of an overall grammer for the set of parameters. There is only a grammar for one of the parameters (namely dec-parallel-cap); an overall grammer covering all the parameters would be highly desirable.

Other than that (and a few more detailed comments below), there are no significant SDP-related issues with the document.

Detailed comments:
-------------------
1) Section 7.2.2:
<quote>
    o  The capability parameters max-lsr, max-lps, max-cpb, max-dpb,
       max-br, max-tr, and max-tc MAY be used to declare further
       capabilities of the offerer or answerer for receiving.  These
       parameters MUST NOT be present when the direction attribute is
       "sendonly".

    o  The capability parameter max-fps MAY be used to declare lower
       capabilities of the offerer or answerer for receiving.  The
       parameters MUST NOT be present when the direction attribute is
       "sendonly".
</quote>

It is unclear why these parameters are not allowed in either the offer or the answer as the "sendonly direction attribute would seem to make them relevant in at least one direction (unless the direction attribute specifically applies to the SDP being sent and not the overall media stream, which is not entirely clear based on the wording).

2) Section 7.2.2 also describes how the same payload type number needs to be used in the offer and the answer. To be clear, this restriction can only be applied to payload type numbers used for H265 and hence does not affect offer/answer procedures for any other media formats. The text should be updated to clarify this point (e.g. in the bullet that begins with "The same RTP payload type number used in the offer MUST be used in the answer when the answer includes recv-sub-layer-id")

Thanks

-- Flemming