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

"Ben Campbell" <> Sun, 19 July 2015 10:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 306C11AC3FB; Sun, 19 Jul 2015 03:34:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fgyzk1fnrveS; Sun, 19 Jul 2015 03:34:32 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 14F221AC3F9; Sun, 19 Jul 2015 03:34:32 -0700 (PDT)
Received: from [] ([]) (authenticated bits=0) by (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
X-Authentication-Warning: Host [] claimed to be []
From: "Ben Campbell" <>
Date: Sun, 19 Jul 2015 12:34:23 +0200
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Mailer: MailMate (1.9.2r5107)
Archived-At: <>
Cc: Flemming Andreasen <>,, mmusic <>
Subject: Re: [MMUSIC] SDP Directorate Review: draft-ietf-payload-rtp-h265-13.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 19 Jul 2015 10:34:34 -0000


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.



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
> 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 
> (see 
> 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