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

"Ben Campbell" <ben@nostrum.com> Sun, 19 July 2015 10:34 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306C11AC3FB; Sun, 19 Jul 2015 03:34:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgyzk1fnrveS; Sun, 19 Jul 2015 03:34:32 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F221AC3F9; Sun, 19 Jul 2015 03:34:32 -0700 (PDT)
Received: from [10.10.1.3] ([162.216.46.123]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t6JAYNxV031490 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 19 Jul 2015 05:34:25 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [162.216.46.123] claimed to be [10.10.1.3]
From: "Ben Campbell" <ben@nostrum.com>
To: draft-ietf-payload-rtp-h265@tools.ietf.org
Date: Sun, 19 Jul 2015 12:34:23 +0200
Message-ID: <F4EB3D17-ACE8-4377-B6D3-7208F69BE6D9@nostrum.com>
In-Reply-To: <557B0C55.10302@cisco.com>
References: <557B0C55.10302@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Mailer: MailMate (1.9.2r5107)
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/WojubPgBTqPHwo6yC7Nxg7txiNw>
Cc: Flemming Andreasen <fandreas@cisco.com>, payload-chairs@ietf.org, mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] SDP Directorate Review: draft-ietf-payload-rtp-h265-13.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Jul 2015 10:34:34 -0000

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
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic