Re: [AVTCORE] [Technical Errata Reported] RFC3550 (4192)

Magnus Westerlund <> Mon, 26 January 2015 12:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 340BD1A8968 for <>; Mon, 26 Jan 2015 04:23:03 -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 qUo-F8eMeNAa for <>; Mon, 26 Jan 2015 04:23:01 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1ACB81A89FA for <>; Mon, 26 Jan 2015 04:23:00 -0800 (PST)
X-AuditID: c1b4fb25-f791c6d00000617b-b2-54c631a3247d
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id C6.94.24955.3A136C45; Mon, 26 Jan 2015 13:22:59 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id; Mon, 26 Jan 2015 13:22:58 +0100
Message-ID: <>
Date: Mon, 26 Jan 2015 13:22:54 +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 <>, Roni Even <>,
References: <> <038501d01a0c$93470820$b9d51860$> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHLMWRmVeSWpSXmKPExsUyM+Jvje5iw2MhBh9nSVi87FnJbnH8RBOz xd92Zgdmj52z7rJ7LFnykymAKYrLJiU1J7MstUjfLoEr40LTIeaC+0oVOze/ZW9g/CbdxcjJ ISFgIvHr5WImCFtM4sK99WwgtpDAEUaJ1y8Cuxi5gOzljBJ3Tu9kBknwCmhLzH5xnh3EZhFQ lXj9cyYriM0mYCFx80cjWLOoQLDE4udPWSHqBSVOznzCAmKLCKRILJo9G2yOsICjxOKlLxkh FqxglJjXuhmsmVMgUGLqt3VgDcwCBhJHFs1hhbDlJZq3QjQLAR3R0NTBOoFRYBaSHbOQtMxC 0rKAkXkVo2hxanFSbrqRsV5qUWZycXF+nl5easkmRmCAHtzyW3UH4+U3jocYBTgYlXh4N649 GiLEmlhWXJl7iFGag0VJnNfO+FCIkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkZGxRL23C8z 9/Z3xqceZDGeaDUrkrPSfZJ1allg8KGkj9EXNwsssVQS5H2oW1bxTkdKTjb1rfr+oN+Wigc+ NHb/irxXW9DLGPRiwuvICBuWfFNxUXaNqSvKlq1Y35wgHHGC++rh4LubDU9uf3z6+NPbq0Mk A7JXyT1qklqxbm514pbQJ5u9lymxFGckGmoxFxUnAgCFi7laMQIAAA==
Archived-At: <>
Subject: Re: [AVTCORE] [Technical Errata Reported] RFC3550 (4192)
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: Mon, 26 Jan 2015 12:23:03 -0000

Hi Julius

On 2014-12-17 16:36, Julius Friedman wrote:
> So quite simply how can jitter and transit use the absolute time from
> packet to packet but yet the calculation of payload data rate is using
> the same?
> Wouldn't time spent on non data items be used then?

I don't quite understand you here. But, I guess that you are complaining
about that the measured entity is not the most relevant.

However, this is not at all reason enough to make a change to the RTCP
report block specification in RFC 3550. As noted before, using Errata is
not the appropriate method for technical change. Errata is used to flag
significant issues, or clarify text that might be misinterpret to avoid
incompatibility issue.

> What about the security concerns related to congruence?

If I understand the security concern correctly. This is that in case one
uses padded payloads in the protection operation, this report leaks the
summary over the amount of new payload bytes received between each
report, potentially for a single packet. Thus providing an information
leak that might provide some insight into the protected data. For
example the audio frame lengths from a variable rate codec.

In would agree that this would be worth taking note of as a security
issue. Potentially change the design to avoid it. However, I would first
of all note that this RTCP definition has been in place since 1996. It
is very widely deployed and any change to it would result in

Further it is clearly possible to protected against. Simply encrypt the
RTCP also. Which would be my recommendation anyway if one encrypts the
RTP packets.

> How is that not errata unless these invalid calculations and security
> issues were intentionally mandated and why now would I knowing these
> things continue to do things as usual?

First of all it is a technical change that is non-backwards compatible.
It does not represent clarifying the WG consensus on how it should be done.

> Furthermore can you simply tell me what breaks if I use the octets
> indicated as I indicated (by only not accounting for the 12 octet header)?

Any implementation that tracks these values would flag an inconsistency
and possible cease transmission. Because your receiver will claim to
have received more bytes than the sending party has sent according to
its calculation of this value.

> WITH ALL DUE RESPECT That should be the determining factor not your
> opinions about intentions.

Please understand a few things. There are process that exist. There are
purposes and rules for what is allowed to be done with difference
processed and mechanisms. In addition there are considerations of the
impact of any changes to existing specifications. Which in its turn
leads back to the process question.

Roni, in his role a WG co-chair has the responsibility for driving these
processes. One of these is to determine the WG's recommendation to the
AD for how an errata is to be handled.

> My tests reveal faster synchronization with rtcp with legacy clients as
> well as a correct rate and data rate when then is calculated by removing
> the csrc extension and padding.

Sorry, I don't understand how you get faster synchronization. This
should have no effect on the RTCP packet transmission rules and their

> How about some calculations and tests are also performed to validate
> this as most default profiles don't use any of the items in question
> anyway.

> Additionally why has nothing been said about rfc2326 and errata 4199?

RFC 2326 is an MMUSIC item. Please, keep the topics separated and with
clear subject lines. Please avoid cross posting between the WG mailing

Can you please refrain from creating more erratas until you have
achieved some WG consensus that any issue is requiring an errata and
what the new text should actually be.


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: