Re: [AVTCORE] New Possible Errata in RFC2326 (And Draft) regarding Blocksize

Magnus Westerlund <> Tue, 27 January 2015 13:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 370BE1A8749; Tue, 27 Jan 2015 05:51:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HwX16Mo2hxMI; Tue, 27 Jan 2015 05:51:28 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 848FC1A8739; Tue, 27 Jan 2015 05:51:27 -0800 (PST)
X-AuditID: c1b4fb2d-f79fc6d000001087-78-54c797dd4d50
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 8A.A7.04231.DD797C45; Tue, 27 Jan 2015 14:51:25 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id; Tue, 27 Jan 2015 14:51:25 +0100
Message-ID: <>
Date: Tue, 27 Jan 2015 14:51:24 +0100
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Julius Friedman <>, "Dale R. Worley" <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+Jvje7d6cdDDC7NtbB42bOS3eL4iSZm i6nLH7NYvDxR5sDiMXn/V2aPnbPusnssWfKTKYA5issmJTUnsyy1SN8ugStj/7MXzAWrdSpO rP/G2MD4SbGLkZNDQsBE4urC70wQtpjEhXvr2boYuTiEBI4wSpzpOQblLGeUWDvnKgtIFa+A tsTCb/+BEhwcLAKqEi96zEHCbAIWEjd/NLKB2KICwRKLnz9lhSgXlDg58wlYq4hAuMTvQ8fY QWxmoNaZ86aC2cJA8VlPtjJC7NrDKNE1ZSkzSIJTIFBix74/UA0GEkcWzWGFsOUlmrfOBqsR ArqnoamDdQKj4Cwk+2YhaZmFpGUBI/MqRtHi1OLi3HQjY73Uoszk4uL8PL281JJNjMBgPrjl t+4OxtWvHQ8xCnAwKvHwGvw/FiLEmlhWXJl7iFGag0VJnNfO+FCIkEB6YklqdmpqQWpRfFFp TmrxIUYmDk6pBkb/XoUDyjvfy1a9073WeWrmCosZPDbl27k2Bu2czXomoMRZce+ugpLb0rb9 msyd3W6NXzYs/OqUm7Yl36EshK11xgG3w/zTrGqmTrq0/N4GTgMHKTu7PHWv8KpT3/xy1jge qTOa9GNF5KLjugWLSzfYZhSUT/li92K64GK2u4flDlxa8Den66ISS3FGoqEWc1FxIgAX81Xy RwIAAA==
Archived-At: <>
Subject: Re: [AVTCORE] New Possible Errata in RFC2326 (And Draft) regarding Blocksize
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Jan 2015 13:51:35 -0000


I also have some issues to see what your issue are.

The intent of this header is "can you please ensure that the media
payloads are never bigger than X". The server can either except it or
override it and respond with "No, I can only guarantee Y bytes".

And that will be dependent on both the media format and the capabilities
of the server. If the requested blocksize requires repackaging and you
don't support you will have to override the value which comes from the
packaging that do exist.

On 2015-01-10 04:38, Julius Friedman wrote:
> ...
> ", it seems
> to me that it counts only the bytes after the "RTP Fixed Header Fields"
> and any RTP header extensions, and that number legitimately could be
> small (depending on the media encoding in the RTP).
> "
> - There must be 12 octets which are the fixed header, this is where that
> information comes from.
> - If ROHC is used or some other encoding / compression which changes
> this amount it is beyond the scope of RTP and that is why I say that the
> underlying Transport should handle this.

The text says that IP/UDP/RTP are all excluded from this so if you say
Blocksize=1 then you can only include one byte of RTP payload. Which
with the exception of some sample-based codecs are completely useless
and will have to be overridden to the minimal value the media format can

But, the above appears to be irrelevant for this header.

> We are not talking about other RFC's we are talking about the ones which
> state the information (RFC2326 and it's biz draft), they introduce this
> header and thus should concretely define it's functionality such that it
> does not impose upon other requirements.
> I am confused as how can you both say you don't understand and that
> there is no error? It has now been explained further... Please
> re-consider, you omitted to respond to other points within the same
> email chain which relate to the problem so it imposes upon my response
> and would cause me to repeat data here again which I was asked not to
> before.
> If there is a better mechanism for communication of these issues please
> let me know, I would be happy to prepare a summary and present it either
> as a document or over a tele-conference to address this as well as any
> other points which have yet to be addressed.
> If there is no error then what is the process to include this useful
> information in some way so that others may know as well? 
> I sincerely appreciate your time,
> Julius
> On Fri, Jan 9, 2015 at 9:28 PM, Dale R. Worley <
> <>> wrote:
>     Julius Friedman <
>     <>> writes:
>     > 18.10
>     <>.
>     > Blocksize
>     >
>     >    The Blocksize request-header field is sent from the client to the
>     >    media server asking the server for a particular media packet size.
>     >    This packet size does not include lower-layer headers such as IP,
>     >    UDP, or RTP.  The server is free to use a blocksize which is lower
>     >    than the one requested.  The server MAY truncate this packet size to
>     >    the closest multiple of the minimum, media-specific block size, or
>     >    override it with the media-specific size if necessary.  The block
>     >    size MUST be a positive decimal number, measured in octets.  The
>     >    server only returns an error (4xx) if the value is syntactically
>     >    invalid.
>     >
>     > Both paragraphs go to specify that the number MUST be positive but
>     > specify no LOWER bound.
>     >
>     > A Blocksize of 12 or less will cause data loss under UDP and cause
>     > invalid framing under TCP.
>     Could you explain this in more detail?  Since the "Blocksize" number
>     "does not include lower-layer headers such as IP, UDP, or RTP", it seems
>     to me that it counts only the bytes after the "RTP Fixed Header Fields"
>     and any RTP header extensions, and that number legitimately could be
>     small (depending on the media encoding in the RTP).
>     > It should be noted that the Blocksize MUST be a positive decimal
>     > number greater than or equal to that supported by the underlying
>     > transport.
>     In any case, *this* RFC does not *have* to state that, as that is a
>     requirement imposed by other RFCs.
>     > I would like to file this errata as soon as possible if everyone agrees;
>     >
>     > If it's not erratum can we please also address this misnomer I seem to have.
>     As far as I can tell, it's not an erratum, because there is no "error"
>     in the RFC.  What you're suggesting is that there is useful information
>     that the RFC does not include, but that information is not an error in
>     this RFC's text.
>     Dale
> _______________________________________________
> Audio/Video Transport Core Maintenance


Magnus Westerlund

Services, Media and Network features, Ericsson Research EAB/TXM
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: