Re: [AVTCORE] [MMUSIC] [Technical Errata Reported] RFC2326 (4199)

[Julius Friedman <[e-mail]>]

Magnus, Et al,

Then Please, adjust what you / we can control which is the Binary
Interleaved Data.

One simple way would be to at least ensure that the application framing
lengths can be conveyed in a manner consistent with the underlying
transport *AND* with respect to any Blocksize in use on the session.

E.g.

A binary interleaved frame MAY NOT contain a frame size larger then any
Blocksize in use.

A binary interleaved frame MAY NOT contain less than 12 bytes for RTP or
RTCP.

A binary interleaved frame MUST be verified by using the packet header
fields e.g. (sequence number, timestamp, ssrc)

Instead of skipping the data what should happen is that the data propagated
to the lower layer transport in chunks.

Skipping data is causing the problem which is also defined as an
instruction when a packet is received for an unknown context, which should
again be handled by propagating the data to the lower layer.

I put this logic in my RtpClient implementation and it works well, and
never becomes unframed unless the client intentionally sends a large packet
which hides data inside (which should be related to the packet anyway)

https://net7mma.codeplex.com/SourceControl/latest#Rtp/RtpClient.cs

You will see in my unit tests I can receive all of the messages which
overflow most other client implementations cannot due to framing errors.

Using the information given and if needed my code as a reference an
implementation can make much better choices and actually never become
unframed and if they do recovering is always possible.

As a take way from this and final note I suppose that someone has also
looked at using independent TCP on a session which also uses Binary
Interleaved data transport, either for RTSP 2 or 1 if not I will ask anyway.

The reason for this question is I am revising some parts of my server and
client to be more dependent on a 'session' and that session is typically
tied to a underlying 'Transport'..

My question is

"What happens when a client signals in a single session that it wants to
use TCP Interleaved on one media item and Independent on another"

The result for my implementation is that if the end points overlap then the
framing will contain two additional bytes...

How is this being handled or how SHOULD it be so I can adjust my
implementation to allow for it as such.

I can see how it would work if the end points didn't overlap, the protocol
wouldn't have the RTSP Binary Interleaved header for the media flows using
the independent transport, correct?

But if and when they DO how is that handled?

Should it not be allowed that Binary Interleaved Transfer and Independent
transfer occur in the same session?

If that is the case then what about Binary (TCP/RTP/AVP) and (UDP/)RTP/AVP,
can they occur in the same session? If not why and where does one make that
determination given the information in the RFC either 2326 or BIZ).

I allow for this in my implementation as well and there is no issue (but
caused me to notice that the Session is still active when TEARDOWN occurs
and hence why I filled the other erratum).

Thanks!


On Fri, Jan 30, 2015 at 5:41 AM, Magnus Westerlund <
[e-mail]> wrote:

> Hi,
>
> I would still prefer that this discussion was done on the mailing list.
>
> The content of the Errata is formal broken. But, lets us not care about
> that.
>
> As I have written before, I still don't see how we can make the change
> Julius proposes even to RTSP 2.0. The core of the proposal to address
> this would make so that $ can only occur as starting point of an
> interleaved binary datagram. That appears impossible to me as the URI
> format for example do allow $ to occur in various parts. Putting in
> escaping at all these places at this stage will also be problematic.
>
> Yes, it is sub-optimal it will force clients or server to close the RTSP
> message transport if they become out of synch with message boundaries.
>
> So, in conclusion, I don't see how we can make any corrections or
> improvements on this.
>
> Cheers
>
> Magnus
>
>
> On 2015-01-30 04:30, Julius Friedman wrote:
> > I wrote in about that in a later email.
> >
> > Do you need my comments on that again?
> >
> > This issue is real and does need to be addressed,  either by using
> > hexadecimal notation in all header fields or otherwise by checking the
> > data using the timestamp and sequence numbers of the packets.
> >
> > Invalid packets (length or otherwise) and packets with no context are
> > also issues I ha e brought up.
> >
> > This is much worse when independent TCP is used if used with interleaved
> > transport in 1.0 as allowed because even though $ was the worst choice
> > based for a framing value it allows something better then what is
> > required when NO framing at all is used and every read has to be
> > verified to be in sync using the protocol level fields such as timestamp
> > and sequence numbers.
> >
> > I have already addressed this in my software as well if reference is
> > needed.
> >
> > Thanks,
> > Julius
> >
> > On Jan 29, 2015 10:18 PM, "Dale R. Worley" <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     Taking a first look at the erratum, two things occur to me:
> >
> >     The erratum quotes a large chunk of the text of section 4 in both the
> >     "says" and "should say" sections.  IMO the duplicated text should
> have
> >     not been put in either, and instead just the changed part, the
> insertion
> >     of:
> >
> >         *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 have been mentioned in "should say".
> >
> >     The second item is that the proposed addition clearly is not what was
> >     intended.  The text says "the hexadecimal octet 0x36", which is the
> >     ASCII code for the digit "6".  What was intended was "the octet 36",
> >     which is the ASCII code for the character '$'.
> >
> >     Dale
> >
>
>
> --
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>