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

[Magnus Westerlund <[e-mail]>]

Hi,

Dropping AVTCORE.



On 2015-01-30 19:42, Julius Friedman wrote:
> 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.

That is not how it is defined in RFC 2326. If one uses Blocksize and the
server agrees to a value, then the largest interleaved media frame will
be block size value plus its framing, e.g. RTP.

But, for RTCP that value is no limit. The interleaved RTCP packet can be
much bigger, up to the 64K limit imposed by RTSP interleave mechanism.

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

That is implicit by using RTP and transport dependent. Due to the
transport dependency I don't see much value in providing such information.

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

This, is a good recommendation, but not something we can mandate in
retrospect. But, I assume most RTP stacks will perform this verification
when the data is provided to that lower layer. Once more what
verifications can be done is transport dependent.

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

Agree, if I implied skipping, that was more in the context of finding
the next boundary. But clear the intereleaved data is to be provided to
the lower layer the SETUP transport negotiated for that channel ID.

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

Once more, I was talking in the context of finding the boundaries
between RTSP messages and the interleaved binary data.

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

Depends on the server I would say. It can clearly work, there is nothing
in the protocol that prevents such usage.

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

Sorry, what do you mean with overlapp. The independent and the TCP
interleaved are using two different TCP connections, so how can they
overlapp? Thus, the TCP connection context separates these two medias
and their different framings.

> 
> 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?

Can't be done, they are in separate TCP connections.

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

Okay, that explains things. Because from my perspective the RTSP
protocol shall negotiate a situation where Interleaved and any
IP/UDP/RTP or IP/TCP/RTP (Independnet TCP) will result in different
transports which can be identified based on there IP/UDP Or IP/TCP
information compared to what comes in over the RTSP message TCP connection.



/Cheers

Magnus

> Thanks!
> 
> 
> On Fri, Jan 30, 2015 at 5:41 AM, Magnus Westerlund
> <[e-mail] <mailto:[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]>
>     > <mailto:[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]
>     <tel:%2B46%2010%207148287>
>     Färögatan 6                 | Mobile [phone]
>     <tel:%2B46%2073%200949079>
>     SE-164 80 Stockholm, Sweden | mailto: [e-mail]
>     <mailto:[e-mail]>
>     ----------------------------------------------------------------------
> 
> 


-- 

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]
----------------------------------------------------------------------