Re: [AVTCORE] On the following Eratta

[Julius Friedman <[e-mail]>]

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 <[e-mail]>
wrote:
>
> 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}
>
>
>
>