[AVTCORE] RFC2435 Errata

[Julius Friedman <[e-mail]>]

Hello Gentleman,

I have filed some errata for RFC2435, the details of which can be found :

http://www.rfc-editor.org/errata_search.php?rfc=2435&rec_status=15&presentation=table

I also have an issue regarding RFC2326 which I had originally addresses
with Mr. Schulzrinne however I feel this channel may be a better means of
conveying and resolving the issue.

My problems with RFC2435 are  ongoing as I have found yet more errata.

The RFC conveys that progressive images are able to be transported however
they utilize the FFC2 marker not the FFC0 marker and in most cases have
alternate huffman tables, this is also the case for 4:0:0 jpegs.

I have provided a few test images which show these problems including
several from the JPEG Reference Software which we fail to Packetize and
Depacketize correctly using this RFC.

Additionally CKYK and RGB are not addressed and I feel that it should be.

I have implemented these changes among others to experiment @
https://net7mma.codeplex.com/SourceControl/latest#Rtsp/Server/Streams/RFC2435Stream.cs

If you are curious to see the differences.


*RFC2326 Problems*
___________________

I have several possible changed regarding RFC2326 but before I get to those
I need to address issues I am having in my implementation with several
cameras.

I would have addressed the working group but I wanted to get your input
first and then if applicable proceed further

*Issue 1)*

RFC2326 Defines a Application Layer Framing for TCP Interleaved Data @ 10.12
Embedded (Interleaved) Binary Data.

There are several problems one can encounter when using this framing
especially when the server is sending RTSP messages while the client is
already in play.

The most prominent issue which I am surprised has not come up before is
that when Interleaving TCP over Http using the base64 tunneling it is
possible to encounter a 0x24, 36 => '$' which is part of the body of the
message.

This will result in the message body being truncated in transport and a
synchronization error in the framing which may take a few seconds to
recover from is the truncated body length is over 4 bytes long and may
result in frame loss if there are multiple characters in the message which
happen to be followed by a valid Context id (Channel).

This also is a problem although less so when using plain old TCP
Interleaving, when a SET_PARAMETER is used or any request which results in
a '$' character being seen in the body of the response.

Lastly this can also be a problem for Rtsp servers depending on how they
implement the sessions framing for each client e.g. it would also be
possible for a client to overrun or break the server by sending requests
which contain that character.

This brings me to another issue with the framing.

*Issue 2)*

The RFC makes no statements on what to do if the frame size is determined
to be larger then the data actually available on the wire.

E.g.
{
[Ethernet, IP]
$, 1, 0x00C1, {24 more bytes}
//Channel 0, 28 bytes
}

In this example it can be seen that the frame size is 28 but the socket
only has 24 more bytes (28 total)

What should be done in this case?

Also what about this case which is much MORE frequent!

E.g.
{
[Ethernet, IP]
$, 0, 0xffff, {35242 more bytes}
//Channel 0, 65535 bytes
}

In this example it can be seen that the frame size is 65535 but the socket
only has 35242 more bytes (35246 total)

*----------*

Currently libraries including my own just set the length to the length
received but I am wondering as to what you would say as from looking in
your libraries TCP is not supported.

Currently a quick solution for the problems involving '$' with Rtsp can
easily be fixed with a small addendum which required that the Body be
escaped of "$", this will resolve the first issue easily.

The seconds issue is slightly harder to address and would require a larger
more thought out process.

It is totally possible to define an alternative framing character (one
which also has bits to indicate if the server or client sent the message),
and that would help some of the issues which also might become apparent
when draft 2.0 of this spec comes out but it is also possible to keep the
same character and specify exactly what to do for those cases listed above.

I believe that we can either safely discard the packet if there is no
relevant context but if there is a relevant context then the problem
becomes much harder to solve especially if a new frame starts after the
cases listed above and the remaining data is not available on the wire.

Thanks for your help!