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

["Ben Campbell" <[e-mail]>]

Hi,

Have I missed a response to Flemming's SDP review? Assuming that I 
haven't, can you comment on when you might be able to respond? If this 
requires a revision, it would be helpful to see the updates discussed 
via mail first.

Thanks!

Ben.

On 12 Jun 2015, at 18:44, Flemming Andreasen wrote:

> 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
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic