Re: [AVTCORE] Errata 4192 RFC 3550

[Stephen Casner <[e-mail]>]

On Fri, 5 Dec 2014, Julius Friedman wrote:

> Hello All.
>
> There is definitely some confusion related to the errata I submitted for
> RFC3550.

I believe the confusion is within your interpretation of the standard,
not in our interpretation of your proposed errata.  Perhaps you would
like RTP to have some functions that are different than those that
were specified, but those do not constitute errata.

> The RFC clearly states:
>
> 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.
>
> Just because it CAN be used for an average does not mean it should.

Let me clarify.  When we wrote that sentence, we were stating why this
field was included.  It was included so that receivers would be able
to know the sender's average payload data rate over various time
intervals by taking the value of this field from two sender reports
and dividing by the difference in time of the two sender reports.  The
receiver might want to compare that result with the average of the
data as received (perhaps with some losses).

> Further it is the total number of octets in the payload besides the
> header because the header is always 12 octets.
>
> Since csrc and extension octets are included then padding should be
> also.

The CSRC and extension octets part of the RTP header and the phrase
"not including header" means that they would not be included in the
sender's octet count.  What text in RFC 3550 led you to believe that
the header is always just the first 12 octets and that therefore the
CSRC and extension octets would be included in the sender's octet
count?

> Since rtcp also reflects the count with padding this is obviously
> correct.

I am not sure what you are referring to here.  In another email you
said "Rtcp counters include this value anyway."  What RTCP counters
include a count of padding bytes?  Perhaps you are referring to the
fact that the legnth field in the RTCP header includes padding on the
RTCP compound packet.  That is irrelevant to the question of whether
the sender's octet count, which is a count of payload octets, should
or should not include padding octets.

> Any padding only packet would not change the counter for rtp and is
> thus a security issue as well as a redundantly conveyed piece of
> information because each packet contains the number of padding bytes
> which can be accounted for in the implementation when required.

I do not see a security issue.  Please explain how there would be an
added security risk for an application that does send RTP data packets
with padding compared to an application does does not send RTP data
packets with padding, even if sometimes those applications send RTP
data packets containing no payload data.

The sender's octet count is an aggregate count of the payload octets
over some number, often a large number, of RTP data packets.  If the
receiver gets all of the data packets with no loss, then that same
count could be calculated.  However, some packets may be lost.  RTP is
designed to help implementations be tolerant of packet loss.

> To account for padding when padding is not required and would be 0
> is also contradictory.

I don't understand this sentence.  The sender's octet count does not
include padding octets, so for implementations that do not send
padding the number of excluded padding octets is zero, but that does
not form any contradiction.

> Please read and re read the errata if required.
>
> Please advise.  ( intelligently )

I suggest that careful reading and understanding of RFC 3550 is what
is required here.

                                                        -- Steve