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

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