Subject: Re: [AVT] RTP w/ TCP, RTP w/o RTCP ...

From: John Lazzaro <[email-masked]>
Date: Sun, 1 Dec 2002 11:31:54 -0800

> Jonathan Rosenberg <[email-masked]> writes:
>
> No. Comedia was meant for non-RTP applications primarily (at least where 
> TCP is concerned). It used to be that you could use a certain character 
> in the TCP stream (* maybe?) to frame RTP packets, but this was removed 
> because no one implemented it.

Thanks for the information, I'll define a default TCP framing method
for use with MWPP in the normative MWPP I-D then ... 

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Sun, 01 Dec 2002 16:55:41 -0500

>for use with MWPP in the normative MWPP I-D then ... 

If it's useful, we might reconsider making a generic TCP framing?

Colin

---

From: Peter Westerink <[email-masked]>
Date: Tue, 3 Dec 2002 12:13:53 -0500

Colin,

I am very interested in having the generic RTP over TCP framing
reinstanted. As I understand it was removed because there were no
implementations, but I can offer you a working one today from my end
(client & server). I know of at least one other company interested in
implementing and interoperating with RTP over TCP according to the removed
specification (which merely added 2 length bytes in front of each RTP
packet). And looking at the discussions on the reflector recently it seems
there are more interested parties. What would be the steps to take to have
the generic framing of RTP over TCP move towards an RFC?

      Peter Westerink
      IBM

                      Colin Perkins                                                                                    
                      <[email-masked]        To:       John Lazzaro <[email-masked]>                        
                      g>                       cc:       [email-masked], [email-masked]                         
                      Sent by:                 Subject:  Re: [AVT] RTP w/ TCP, RTP w/o RTCP ...                        
                      [email-masked]                                                                                
                      g                                                                                                

                      12/01/2002 04:55                                                                                 
                      PM                                                                                               

Colin

---

From: Chuck Harrison <[email-masked]>
Date: Tue, 03 Dec 2002 09:58:13 -0800

Hi, all,

It seems to me that using a bytecount alone (as in the earlier RTP
draft) is ok for a *reliable* bytestream abstraction but that it
would be hard to re-sync in the generic bytestream case. (One
might add a sync code -- magic number -- to increase robustness
in the general case. I'm not suggesting that the sync code needs
to be absent from the encapsulated data; it just serves as a "hint"
to a receiver who is in a lost-sync state.)

Peter, since you have implementation experience here, can you
say whether there is any practical advantage or disadvantage to
adding a sync code now and then to a TCP-encapsulated stream?

Cheers,
  Chuck

>                       Sent by:                 Subject:  Re: [AVT] RTP w/ TCP, RTP w/o RTCP ...

#################################################################
#################################################################
#################################################################
#####
#####
#####
#################################################################
#################################################################
#################################################################
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Tue, 03 Dec 2002 13:07:47 -0500

>adding a sync code now and then to a TCP-encapsulated stream?

What would be the point? TCP is a reliable bytestream.

Colin

---

From: Colin Perkins <[email-masked]>
Date: Tue, 03 Dec 2002 13:10:52 -0500

[Please don't cc avt-admin on messages sent to the list]

>the generic framing of RTP over TCP move towards an RFC?

Write up an internet-draft describing the RTP-over-TCP framing scheme, and
if there is interest we can consider advancing it to RFC. I expect it will
be a very short draft.

Colin

---

From: Ron Frederick <[email-masked]>
Date: Tue, 03 Dec 2002 10:07:07 -0800

> the generic framing of RTP over TCP move towards an RFC?
Is there any reason to prefer this older encapsulation of RTP over TCP to
the one defined by RTSP? The RTSP one does increase the overhead slightly
(from 2 bytes to 4 bytes), but it offers the ability to multiplex multiple
RTP streams over a single TCP connection in the process, which can often
be a big win in overall resources consumed. It also allows control packets
and RTP data to be multiplexed on the same connection. While there might be
some applications out there that don't need these features, I doubt there
are very many. At the very least, most applications will need both RTP and
RTCP channels, and just being able to put those over a single TCP connection
more than makes up for the extra two bytes of header in most cases.

If we're going to bring back any kind of standard RTP-over-TCP encoding, I
would encourage it to be the RTSP encoding. It's simple to implement and it
really has no direct ties to RTSP. The only thing that we might need to do
is to pre-define one particular mode of operation where something like
interleaved channels 0 & 1 are known to contain the RTP & RTCP data,
respectively, so that the application doesn't need to negotiate this. Even
that could simply be left as "negotiated out of band", though, with
applications that wish to operate in this mode just agreeing to these
assignments in advance.

Here's the relevant section of the RFC:

10.12 Embedded (Interleaved) Binary Data

   Certain firewall designs and other circumstances may force a server
   to interleave RTSP methods and stream data. This interleaving should
   generally be avoided unless necessary since it complicates client and
   server operation and imposes additional overhead. Interleaved binary
   data SHOULD only be used if RTSP is carried over TCP.

   Stream data such as RTP packets is encapsulated by an ASCII dollar
   sign (24 hexadecimal), followed by a one-byte channel identifier,
   followed by the length of the encapsulated binary data as a binary,
   two-byte integer in network byte order. The stream data follows
   immediately afterwards, without a CRLF, but including the upper-layer
   protocol headers. Each $ block contains exactly one upper-layer
   protocol data unit, e.g., one RTP packet.

   The channel identifier is defined in the Transport header with the
   interleaved parameter(Section 12.39).

   When the transport choice is RTP, RTCP messages are also interleaved
   by the server over the TCP connection. As a default, RTCP packets are
   sent on the first available channel higher than the RTP channel. The
   client MAY explicitly request RTCP packets on another channel. This
   is done by specifying two channels in the interleaved parameter of
   the Transport header(Section 12.39).

     RTCP is needed for synchronization when two or more streams are
     interleaved in such a fashion. Also, this provides a convenient way
     to tunnel RTP/RTCP packets through the TCP control connection when
     required by the network configuration and transfer them onto UDP
     when possible.

     C->S: SETUP rtsp://foo.com/bar.file RTSP/1.0
           CSeq: 2
           Transport: RTP/AVP/TCP;interleaved=0-1

     S->C: RTSP/1.0 200 OK
           CSeq: 2
           Date: 05 Jun 1997 18:57:18 GMT
           Transport: RTP/AVP/TCP;interleaved=0-1
           Session: 12345678

     C->S: PLAY rtsp://foo.com/bar.file RTSP/1.0
           CSeq: 3
           Session: 12345678

     S->C: RTSP/1.0 200 OK
           CSeq: 3
           Session: 12345678
           Date: 05 Jun 1997 18:59:15 GMT
           RTP-Info: url=rtsp://foo.com/bar.file;
             seq=232433;rtptime=972948234

     S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}
     S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}
     S->C: $\001{2 byte length}{"length" bytes  RTCP packet}

--- end of RTSP RFC excerpt ---

I'm proposing here that we only take the last part of this sample trace, and
not any of the earlier RTSP messages. In other words, instead of going with
a 2-byte length field between packets completely unadorned, we go with a
4-byte header that looks like:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    $ (0x24)   |    channel    |        packet length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The use of the '$' allows the mixture of control messages and data messages
on the same connection, as long as no legal control message can start with
a '$'. The use of the 'channel' field allows for multiple RTP data streams
to be sent over the same connection.
--
Ron Frederick
[email-masked]
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 3 Dec 2002 19:05:16 +0000 (GMT)

> What would be the point? TCP is a reliable bytestream.

No, TCP provides the (leaky) abstraction of a reliable bytestream,
which is a somewhat different thing.

Whether an application could benefit from e.g. segments received ahead
of the left edge of the window being handed up to the app is an open
question - didn't just this thing pop up in recently in the context of
SCTP and framing hints?

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: Ross Finlayson <[email-masked]>
Date: Tue, 03 Dec 2002 12:38:56 -0800

I agree with Ron.  The RTP-over-TCP framing mechanism for RTSP is already 
standardized, is in widespread use, and has some clear benefits (in 
particular, being able to carry RTP and RTCP over a single TCP connection).

Having a single RTP-over-TCP framing mechanism will reduce confusion (and 
simplify implementations when RTSP is already supported).

	Ross.

---

From: Colin Perkins <[email-masked]>
Date: Tue, 03 Dec 2002 15:55:54 -0500

>question - didn't just this thing pop up in recently in the context of

Sure, and if one wanted to derive an RTP over SCTP mapping that would be
another issue we could consider. Changes to TCP to support record markers
and framing hints are definitely outside the scope of AVT - and outside my
understanding of the sync codes Chuck was suggesting - take it to TSVWG if
anyone's interested.

Colin

---

From: Stephen Casner <[email-masked]>
Date: Tue, 3 Dec 2002 23:11:16 -0800 (PST)

> if there is interest we can consider advancing it to RFC. I expect it will

Should this idea progress in that direction, note that the new RFC
would be an RTP profile-level specification, not a payload format.

                                                        -- Steve