[AVTCORE] On the following Eratta

[Julius Friedman <[e-mail]>]

Dear Members,

This is my last and final attempt to ensure I have clearly outlined my
issues as I see them, I will also attempt to address any confusion or
'hostility' or other such issues with my posts to this list.

I initially wrote to the ALL original authors of which only one replied
stating "no time was available to deal with the issue at present." at which
point I then wrote into the 'mmusic' group with an the same issue related
to Rtsp, this issue was what I have now filed as Errata 4199.

http://www.rfc-editor.org/errata_search.php?rfc=2435&eid=4199

Absolutely no one responded on the list and I assumed (possibly
incorrectly) that I was either not signed up correctly or there was another
issue related to the transmission of the message to the group.

I proceeded to wait for a response and in the mean time I also asked
questions about RFC2435 which also went unanswered.

There were 4 separate issues so I filed separate Errata for each issue:

http://www.rfc-editor.org/errata_search.php?rfc=2435

Respectively Errata 4094 - 4097.

When I filed those Errata using the same process I started receiving emails
which indicated my responses were now going through to the list.

I also had an issue with 3550, and specifically the one which I was
responded as a result of filling Errata 4192.

http://www.rfc-editor.org/errata_search.php?rfc=3550

Those are my only Errata at the current time.

On Errata 4192:

Mr. Casner advised me of the following on Dec 5 2014:

"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)."

Given this example I responded with concerns due to the following:

1) Time used for calculating inter-arrival jitter, transit and other such
values take into account the ABSOLUTE time of reference from when a packet
was received to when a packet was received.

Using such a time reference I am thus also using data which is not part of
the payload in my time reference point.

Without values to indicate how much of each field was not related to
payload data (which a receiver would have to track on it's own) it would
also be impossible to estimate such information.

I also indicated several scenarios which show that I may not increment any
values for the counter when using only csrc/extension and padding or any
combination therein.

This is again both a security issue and causes an invalid payload data rate
to be calculated.

At this point it was the following was stated "Rtp has worked for 18 years
and even if this is correct would cause a protocol change..."

I accepted that response and indicated how I didn't really agree that it
required a protocol change since other such textual changes have and
continue to be made to RFC3550.

As part of my argument I stated a scenario where padding should have been
at the top of the payload with any other option fields and the fact that it
was not CAN cause data loss and should require a protocol change where as
something like I proposed would not.

That itself opened up a totally separate discussion which was deemed valid
by at least two participants who advised I draft something because it was
more prestigious to draft rather then to file Errata.

It is not my intention to seek fame or profit for this work, I only intend
to either be corrected or to correct the standard.

I wrote in comments on the drafts which were published because of two
things:

1) Following the same thinking as given in response to my proposal  which
was "Rtp has worked for 18 years.." why are those new drafts needed? I went
further to show that my comments were more then just suggestive in the fact
that there are several ways one can achieve "keep alive" and "leap year
insertion" as well as local synchronization also where it is no necessary.
If those changes are valid then why would my change be any less valid
considering it adds nothing new?

2) Ideas presented in the one or two of drafts were limited in the sense
they did not address additional security concerns which were then possible
when introducing the related content. Specifically the leap year draft
doesn't state what happens if a person appears to be stuck in the leap year
instant and causes time to appear to stand still to a receiver. Or if I am
following a clock referenced  by another standard I should be aware of the
details which validate and invalidate such clock readings and would
otherwise cause loss.

Since NTP already provides a time reference when can then be used to
provide intermedia synchronization, this is indicated by
Mr.Schulzrinne here:

http://www.cs.columbia.edu/~hgs/rtp/faq.html#sr-timestamp

Where it also is indicated that there are issues when calculating jitter
when the Timestamp remains the same. (on the same page)

http://www.cs.columbia.edu/~hgs/rtp/faq.html#jitter

Given those notions and further the acknowledgement that no updated related
to the Timestamp has since been issued I am curious of the following:

Why were existing standard tools such as feedback or the AVB RTP / RTCP
definitions not used when there is a specific profile and separate draft
for them?

Realistically asking those questions may seem hostile so I digress, I
really just want to address the original issues I filled errata for rather
then arguing;

At this point if someone can indicate to me how I can just correctly
utilize the senders octet count when extension, csrc, padding and now "keep
alives" are in use I will also accept such an answer so long as the math
can be demonstrated correctly and retract my errata.

It would be also be a very good learning experience if someone would be
willing to indicate why it should not be done as I have suggested, after
all when I test these changes with legacy software I sometimes find they
also seem to agree with my understanding of the equations given rather then
the standards so I am only attempting to resolve those differences.

If anything else is required to have my Erratta answered please let me
know, at this point I don't care if it's rejected or scorned or annoying, I
would like to know HOW and WHY it breaks something when I cannot seem to
replicate anything but more positive results.


On Errata 4094 - 4097.

I have filed those before any of the others and have had no responses
relating to their creation or correctness.

If we would kindly address these items I would also appreciate it which are:

I have found an instance where the given code in the RFC did not handle
images with single quantization tables e.g. black and white images. I have
submitted a correction for this.

I have also showed that its possible to convey the exact sub sampling as
indicated in the image while allowing the existing 'Type' parameter to be
used.

I have shown larger images than the given can be sent using a simple
reversal of the FragmentOffset verses the actual offset in the file.

I have again demonstrated these changes can work with existing software
depending how they are employed and the format needing transfer.

On Errata 4199:

I have yet to receive a response for this even though it has been
replicated in the wild and in several different implementations as well as
Live 555 through VLC.

http://www.videolan.org/security/sa1202.html

I had originally written in about this issue many months ago but it seems
for some reason neither the Errata or any communication to the group in
reference can be found.

I recently submitted this Errata again and hopefully we can address the
following issues as well:


I would like to begin first by correcting my Errata which contains a typo:

*Please note the hexadecimal octet 0x36 should not be included in any
part of a RTSP message, if present it should be replaced with binary
escaped sequence as defined in: <consensus>*.


Should read as follows:

*Please note the hexadecimal octet 0x24 should not be included in any
part of a RTSP message, if present it should be replaced with binary
escaped sequence as defined in: <consensus>*.


This can be visualized under the following circumstance:


   S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 431
           Content-Type: text/parameters
           Session: 12345678
           Content-Length: 15

           packets_received
           jitter

S->C: $\000{2 byte length}{"length" bytes data, w/RTP header

 S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}

C->S: RTSP/1.0 200 OK CSeq: 431 Content-Length: 46 Content-Type:
text/parameters packets_received: 10 jitter: 0.3838


         S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}
     S->C: $\001{2 byte length}{"length" bytes  RTCP packet}