Re: [AVT] RFC3550 .... -> RTP light?

[Ladan Gharai <ladan at isi.edu>]

An alternative to a RTP-light protocol would be a RTP profile which 
satisfies the features you list.

The current version of the  "RTP Profile for TCP Friendly Rate Control" 
has the following properties:

    1. is only defined for unicast flows  (no multicast)
    2. includes a 32 bit send timestamp and round trip time in the RTP 
data packet

I'd be interested to know what other timing information media 
applications would be interested in exchanging between unicast 
sender/receivers which would be useful to add to the profile?

The new version of the draft can be found at:
    
http://www.ietf.org/internet-drafts/draft-ietf-avt-tfrc-profile-02.txt
or
  http://www.east.isi.edu/projects/MACC/tfrc-profile.txt

Ladan

On Aug 12, 2004, at 4:05 PM, John Lazzaro wrote:

> On Aug 12, 2004, at 11:56 AM, Stephan Wenger wrote:
> > Sometimes I wake up in the middle of the night asking myself whether 
> > an
> > RTP-light would be feasible, without multicast support, without 
> > mixers,
> > without SSRC, CSRC, but instead with a timing model that fits the 
> > needs
> > of modern video codecs (that decouples sampling/presentation time from
> > transmission time).
>
> If we ever start down this path, picking a few other timing-challenged
> applications to guide the new timing model would be a good thing ...
>
> ---
> John Lazzaro
> http://www.cs.berkeley.edu/~lazzaro
> lazzaro [at] cs [dot] berkeley [dot] edu
> ---
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www1.ietf.org/mailman/listinfo/avt


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt