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

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?

What about the security concerns related to congruence?

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?

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

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

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.

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?

Thanks!
 On Dec 17, 2014 10:17 AM, "Roni Even" <ron.even.tlv@gmail.com> wrote:

> Hi,
> This is not an errata and if there is a requirement for a different metrics
> it can be specified as a new metrics (maybe using XR reports) and not by
> changing existing metrics.
>
> Thanks
> Roni Even
> AVTCore co-chair
>
> > -----Original Message-----
> > From: avt [mailto:avt-bounces@ietf.org] On Behalf Of RFC Errata System
> > Sent: 04 December, 2014 3:48 AM
> > To: schulzrinne@cs.columbia.edu; casner@acm.org; ronf@bluecoat.com;
> > van@packetdesign.com; rlb@ipv.sx; alissa@cooperw.in;
> keith.drage@alcatel-
> > lucent.com; roni.even@mail01.huawei.com
> > Cc: juliusfriedman@gmail.com; avt@ietf.org; rfc-editor@rfc-editor.org
> > Subject: [AVTCORE] [Technical Errata Reported] RFC3550 (4192)
> >
> > The following errata report has been submitted for RFC3550,
> > "RTP: A Transport Protocol for Real-Time Applications".
> >
> > --------------------------------------
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata_search.php?rfc=3550&eid=4192
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: Julius Friedman <juliusfriedman@gmail.com>
> >
> > Section: 6.4.1
> >
> > Original Text
> > -------------
> > sender's octet count: 32 bits
> >       The total number of payload octets (i.e., not including header or
> >       padding) transmitted in RTP data packets by the sender since
> >       starting transmission up until the time this SR packet was
> >       generated.  The count SHOULD be reset if the sender changes its
> >       SSRC identifier.  This field can be used to estimate the average
> >       payload data rate.
> >
> > Corrected Text
> > --------------
> > sender's octet count: 32 bits
> >       The total number of payload octets
> >       transmitted in RTP data packets by the sender since
> >       starting transmission up until the time this SR packet was
> >       generated.  The count SHOULD be reset if the sender changes its
> >       SSRC identifier.  This field can be used to estimate the average
> >       payload data rate.
> >
> > Notes
> > -----
> > Where as payload octets is defined as the total number of data octets
> > contained in a Rtp Packet minus the 12 Header octets for Rtp Packets.
> >
> > Padding octets as well as octets which occur in the contributing source
> list
> > should also be included as they may differ on a per packet basis and
> would
> > make the total calculation invalid.
> >
> > During TCP communication any application layer header should NOT be
> > included in the total bytes count when including the header length.
> >
> > Any Rtcp packet counters should include the total length of the packet
> (header,
> > padding and any other data).
> >
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". If necessary, please use
> "Reply
> > All" to discuss whether it should be verified or rejected. When a
> decision
> is
> > reached, the verifying party (IESG) can log in to change the status and
> edit the
> > report, if necessary.
> >
> > --------------------------------------
> > RFC3550 (draft-ietf-avt-rtp-new-12)
> > --------------------------------------
> > Title               : RTP: A Transport Protocol for Real-Time
> Applications
> > Publication Date    : July 2003
> > Author(s)           : H. Schulzrinne, S. Casner, R. Frederick, V.
> Jacobson
> > Category            : DRAFT STANDARD
> > Source              : Audio/Video Transport
> > Area                : Real-time Applications and Infrastructure
> > Stream              : IETF
> > Verifying Party     : IESG
> >
> > _______________________________________________
> > Audio/Video Transport Core Maintenance
> > avt@ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
>
>