Re: [AVT] Vorbis RTP issues list for Vienna

[Mark Baugher <[e-mail]>]

At 04:51 PM 7/9/2003 -0700, Aaron Colwell wrote:


>On Wed, 9 Jul 2003, John Lazzaro wrote:
>
> >
> > > Aaron Colwell <[e-mail]> writes:
> > > I agree with Ross on this. It seems that these codebooks are causing too
> > > many problems that aren't worth dealing with. People have been suggesting
> > > getting the codebooks via HTTP, alternate TCP links, and all sorts of
> > > other methods. If your going to go that far why not just use HTTP to
> > > deliver the data. That way you are guaranteed to get everything in the
> > > right order.
> >
> > I think its just an instance of a general problem -- transport of
> > hybrid streams with two components:
> >
> >   -- A steady flow of media information that can handle the
> >      occassional packet loss episode gracefully and without
> >      retransmission
> >
> >   -- Occassional chunks of data, which can be sent well ahead of
> >      its need, which needs reliability, and which is synchronous
> >      to the media flow.
> >
> > So, I think its a good idea for RTP to offer solutions that work
> > in this domain.  There are some studio-oriented uses of RTP MIDI
> > which fit into the model, and my motivation for doing
> > draft-lazzaro-avt-rtp-framing-contrans-01 is to support those in
> > a general way, so that when things like Vorbis codebooks come
> > along, RTP has a way to support them.  I really don't think that
> > posing the question as all-or-none -- RTP streaming or Shoutcast-esqe
> > pseudo-streaming -- benefits AVT, it will just spawn more HTTP
> > streaming implementations.
>
>When stated in these more general terms I can see your point about how
>this scenario could be useful. Another use may be a key stream for
>encrypted content that changes encryption keys often. You would want this
>data to be transmitted reliably and ensure that it gets there before the
>data that depends on it arrives.

The keys to the data need to be delivered "at least as reliably" as the 
data but not necessarily "reliably."  Putting keys in the data packet is 
one such method, but we are not likely to use this method in RTP (poor 
separation of functions, no third-party key mgt, etc).  But there have been 
proposals for using RTCP or SRTCP.  Rather than extend RTCP or SRTCP for 
this purpose, however, a better approach IMHO is to put the key in the SDP 
and send it "at least as reliably" as the SRTP.  The SDP must of course be 
authenticated/integrity-checked and encrypted.


>I did not mean to actually suggest the use of HTTP as a viable delivery
>mechanism instead of RTP. I don't really want more "Shoutcast-esqe
>pseudo-streaming" solutions either. I'll be a little more careful with
>comments like this.

It's hard to engineer a network where media flows masquerade as something else.

Mark


>I'll take a look at the draft that you mentioned and send you any comments
>I may have.
>
> >
> > That said:
> >
> > > The Vorbis folks
> > > should come up with a "streamable" profile that encodes the audio using
> > > predefined codebooks.
> >
> > This is a good option too -- my guess is that most Vorbis setups
> > will only need one codebook for the life of the stream, and that
> > need will be known in advance.  A URL in the session description
> > to support HTTP download of that one codebook would be a way to
> > go, with perhaps a known set of "standard codebooks" codable by
> > speak tokens or by GUIDs for the MIME HTTP codebook object.
>
>Hopefully they will embrace these ideas. I think it could simplify client
>implementations a bit. If they used just predefined codebooks or only used
>one codebook and specified it via SDP, Vorbis would be just like many
>other datatypes and would not require a lot of extra work to support in
>existing players.
>
>Aaron
>
> >
> > -------------------------------------------------------------------------
> > 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
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/avt
> >
>
>_______________________________________________
>Audio/Video Transport Working Group
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/avt



_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt