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

Flemming Andreasen <fandreas@cisco.com> Fri, 12 June 2015 16:44 UTC

Return-Path: <fandreas@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id E63E81A1A0B; Fri, 12 Jun 2015 09:44:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 3SL4-AGTrk8Y; Fri, 12 Jun 2015 09:44:09 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48D2E1A0406; Fri, 12 Jun 2015 09:44:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29095; q=dns/txt; s=iport; t=1434127449; x=1435337049; h=message-id:date:from:mime-version:to:cc:subject; bh=EvbHfiFjlcnIEDw8W5KCeUUH2MBtYwcNYnVn7ZqiP0o=; b=kRa7d8H0RY0bAZgTMc/OD5VXcJqHgcbnllW0nQ0PkeuB8S7vs+1rBGfX eA4hjmCnX4wvRlmiVzbEVCzu2f4Jmm7dihfeLteEFH/mlsrLGp9Skch92 8xDT30ICByRNPJwyVuEoIN/+03jbpLAu4KEURBCzFniyzcFbpypvwOimb Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.13,602,1427760000"; d="scan'208,217";a="3040745"
Received: from rcdn-core-8.cisco.com ([]) by rcdn-iport-4.cisco.com with ESMTP; 12 Jun 2015 16:44:08 +0000
Received: from [] (bxb-fandreas-8816.cisco.com []) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t5CGi7E7009189; Fri, 12 Jun 2015 16:44:07 GMT
Message-ID: <557B0C55.10302@cisco.com>
Date: Fri, 12 Jun 2015 12:44:05 -0400
From: Flemming Andreasen <fandreas@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: draft-ietf-payload-rtp-h265@tools.ietf.org
Content-Type: multipart/alternative; boundary="------------060801010400060908090409"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/iNeYPGvRkfsru6jrUqOwfbdiR8Q>
Cc: Ben Campbell <ben@nostrum.com>, payload-chairs@ietf.org, mmusic <mmusic@ietf.org>
Subject: [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: <http://www.ietf.org/mail-archive/web/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: Fri, 12 Jun 2015 16:44:12 -0000


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


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

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

    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

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")


-- Flemming