Subject: [AVTCORE] On the following Eratta

From: Julius Friedman <[email-masked]>
Date: Wed, 17 Dec 2014 15:47:46 -0500

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}

---

From: Julius Friedman <[email-masked]>
Date: Wed, 17 Dec 2014 16:09:35 -0500

My previous email accidentally sent when formatting the response and I do
apologize AGAIN for any inconvenience.

In short I resume where I was explaining that during Interleaved RTSP
Communication RTSP Responses may be interleaved with RTP data.

The example shows that the presence of "$" in either the headers or in the
body portion of the request would cause an invalid frame to be parsed as if
it was an Rtp or Rtcp packet.

This can also occur in HTTP Tunneled transport especially with Interleaved
binary communication.

I have posted on this issue here as well
http://sourceforge.net/p/rtspspec/bugs/227/

Additionally,

If I receive a Frame header which indicates 1436 more bytes are in the PDU
and the MSS only encompasses 1300 bytes show should I proceed? How can one
determine if the next data received is the start of the new PDU or the data
from the last indicated PDU? What about if the frame indicates 28 bytes and
there are 1464 bytes available? should a new ALF and PDU be parsed at
offset 32 (4 + 28)? What if the remaining data is RTSP or does not consist
of "$"?

Since that may be a little hectic to understand my question is as follows:

How can I reliably re-sync when framing is lost?
- Scanning for '$' is problematic and allows for situations where I can
create a specially crafted TCP Segment which contains a bunch of "$0FFRTSP"
data which can then be used to overload the receiver or force data loss.

I have included the original email to ensure that my response can
appropriately be found if required:

----------------------

"Hello I am currently implementing Rtsp and Rtp in my project @
https://net7mma.codeplex.com

I have a complete implementation of Rtsp as a Client and as a Server, the
solution also can translate from Http variations of MJPEG and JPEG to (as
well as create from existing files)RFC2435 JPEG and hopefully soon to MPEG
/ H264 etc.

The interleaved support was the most interesting thing to implement because
of invalid data in-between valid ALF framing e.g. the infamous "$" block.

The standard does not say what to do about what should occur if ( < || >)
 length is received as indicated in the ALF (bytes 3 and 4 [2 and 3 from a
0 based index]) from the TCP socket.

I have coped with this in the situation of < received by performing another
read.

In the situation of > I just assume another frame is present and re-parse
the ALF from the indicated length + 4.

There is also something like the possibility of length being corrupt or
invalid and I think the standard should deal with that explicitly, possibly
something like PMPP Encoding should be employed to ensure that all packets
arrive, then the PMPP Header would be used as required for the channel ID
and length information but perhaps that is too much to employ and I leave
that decision up to you.

Something also needs to definitely be included in the situation where
RFC4751 is being employed, e.g. the first two bytes need to be removed this
way the Rtsp layer is not indicating a length which would then start at the
first 2 bytes of the 4571 framing which is exactly the same as the RFC4571
length fields.

RTSP should also possibly identify a special byte which indicates the ALF
is up or down stream, e.g. the reverse of 36 ('$'), but this would be
incompatible with previous implementations, the original framing character
while "cute" as '$' left no room for flagging additional bits by a later
spec such as validity or multiplicity of frames inter alia, something
Mr. Schulzrinne is not famous for I assure you.

Re-guarding additional RFC's I think that something should also be
indicated about support of non "Rtp" mechanisms.

This would be an abstract definition which would allow the Describe request
to be used on the root of a server and for a non SDP response type to be
used which would allow for listing of media URI's which are available on
the server as well as their Transport Type e.g. Rtp or Rtsp on demand
(http) or something else such as RTMP or what have you.

I can propose something simple but I don't want to step on any toes.

This would allow for the Setup request phase to contain a non Rtp
implementation details in the header and require that those who implement
Rtsp would thus have a 'Transport' layer which would also make the handling
of tunneled Http requests easier.

This would also allow for translation of protocols such as RTMP where the
RTMP protocol would then be used after the Play request and based off the
Setup requests and optionally either in place of Rtp or in conjunction with
Rtp among other protocols on a different channel.

E.g. Rtp on channel 0, Rtcp on channel 1, and Rtmp on channel 3, possibly
Http on channel 4.

This would be essential for Mixers and Translators IMHO as a single
RtspServer would then be able to attain multiple channels of information
when required for whatever purpose.

Something I see possible with this is servers synchronizing archived data
with another server e.g. bulk transfers or a scenario where a single box is
receiving data for multiple end users and streams and then taking the data
and sending it out on it's own to different end points.

If nothing else this would be a way to standardize the GET_PARAMETER
implementation to include details of the playing media and when a root
request was performed information as indicated above would be returned.

I would also like something said about Video on Demand vs Rtp Transport if
possible this way those who are just streaming a file "http" style will
have definite ways to initiate pause and resume operations on a on demand
video...

E.g. When using a download on demand request which is multi-part response
the server could be sending the client the requested video in chunks on the
request socket while a new request comes in to pause that video on demand
request... or skip certain portions or resume at a certain point.

Last but not least something should be stated about time differences in
relaying media e.g. when one server is relaying media to many clients from
a single source there should be an indication in the Rtp-Transport header
such as "ntptime=xyz" which indicates the ntp time of the media so that the
server can use this timestamp to synchonrize all media and generate new
timestamps as well and sequence numbers when relaying media, the Date
header could also optionally be used.

If you have any questions let me know as this email was written very
hastily with little effort put into grammar.

Thank you for your time,

Sincerely,
Julius Richard Friedman"
------------------------------

I apologize again for any inconvenience I have caused the committee
hopefully I have rounded up everything in summary as to get the responses I
require.

Hopefully in this process I can both educate myself why my proposed changes
were wrong and not make the same mistakes twice and if necessary retract
any Errata as a result of my erroneous understanding.

Thank you for your time in these matters.

Sincerely,
Julius Richard Friedman

On Wed, Dec 17, 2014 at 3:47 PM, Julius Friedman <[email-masked]>
wrote:
> When I filed those Errata using the same process I started receiving
> emails which indicated my responses were now going through to the list.
>
> This is again both a security issue and causes an invalid payload data
> rate to be calculated.
>
> Given those notions and further the acknowledgement that no updated
> related to the Timestamp has since been issued I am curious of the
> following:
>