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

From: "Anders Klemets" <[email-masked]>
Date: Mon, 2 Dec 2002 13:18:02 -0800

I found a specification for RTP over TCP at
http://www.alternic.org/drafts/drafts-i-j/draft-ietf-avt-profile-new-09.
txt, section 7, page 34.  This is what the document says:

"  7 RTP over TCP and Similar Byte Stream Protocols
  
     Under special circumstances, it may be necessary to carry RTP in
     protocols offering a byte stream abstraction, such as TCP, possibly
     multiplexed with other data. If the application does not define its
     own method of delineating RTP and RTCP packets, it SHOULD prefix
each
     packet with a two-octet length field in network order (most
     significant octet first).
  
     (Note: RTSP [29] provides its own encapsulation and does not need
an
     extra length indication.)"

If possible, it would be nice if your new I-D would specify a compatible
framing mechanism.

-----Original Message-----
From: John Lazzaro [mailto:[email-masked]] 
Sent: Sunday, December 01, 2002 2:08 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [AVT] RTP w/ TCP, RTP w/o RTCP ...

> Colin Perkins <[email-masked]> writes:
>
> If it's useful, we might reconsider making a generic TCP framing?

I'll write it into the document in a modular way, so if there is
interest it can be broken out into a separate I-D ... 

The MWPP need for a TCP option is for "archival" applications, where
a musician's MIDI stream is being recorded for later use. Probably in
some sort of recording studio application, running over a switched LAN
that "almost" never drops packets.

------------------------------------------------------------------------
-
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
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: John Lazzaro <[email-masked]>
Date: Mon, 2 Dec 2002 13:47:39 -0800

> "Anders Klemets" <[email-masked]> writes:
>
> If possible, it would be nice if your new I-D would 
> specify a compatible framing mechanism.

OK, I'll preserve it as is ... 

-------------------------------------------------------------------------
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: John Lazzaro <[email-masked]>
Date: Tue, 3 Dec 2002 11:25:06 -0800

> Colin Perkins <[email-masked]> writes:
>
> 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.

A few observations:

   -- Looks like what is needed first is consensus on the "maintain
      compatibility with the old RTP RFC" vs "switch to an RTSP style
      of framing." Both sentiments have been posted to the list.

  -- It needs to be consistent with the comedia I-D.

  -- It needs to be clear about the use of bidirectionality in a 
     single TCP stream: if A -> B on a stream is carrying an RTP
     flow, does B -> A carry:

        (a) nothing
        (b) all RTCP from B to A 
        (c) only RTCP receiver reports for the forward stream
        (d) the RTP stream from B to A

     I think the comedia draft specifies some (if not all) of 
     this issue; the new I-D should be consistent with what is
     specified, and fill in what was left unspecified.

 -- The Security Considerations needs to warn implementors about
    being bulletproof to rogue senders -- code written for UDP
    might not be bulletproof at that level if it is crudely 
    ported to handle TCP. Basically, issues surrounding using
    a big frame number to get a buffer-overflow, etc.

 -- If the decision is made to take the "maintain compatibility
    with the old RTP RFC" route, then text needs to be added on
    how to do resyncing without a "$" or "*" character to help.
    This would be for recovery from sender programmer error, if
    nothing else ...

Basically, I had assumed I would need to write this as part of
completing the MWPP work -- but if someone else wants to do it
instead, that would be fantastic. Let me know if someone else
wants to write it, and I'll drop if off my list of things to do.