RE: [MMUSIC] Streaming media

[Jose Rey <[e-mail]>]

Gonzalo,

although I do not exactly know until what extend this is matching your
original question, the draft-ietf-avt-rtp-retransmission-03.txt offers
some signalling about buffering. It refers to the initial playout
buffering. The parameter "rtx-time" defines a way for the server to tell
the client how long will the server buffer the packets and be
retransmitted . So it's used to allocate playout buffer. You may wanna
take a look at what's done there.

cheers,

Jose

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf Of
> Gonzalo Camarillo
> Sent: Saturday, December 14, 2002 1:59 PM
> To: Flemming Andreasen
> Cc: mmusic; Janne Suotula (LMF)
> Subject: Re: [MMUSIC] Streaming media
>
>
> Flemming,
>
> thanks for the pointer. That was the draft I was looking for.
>
> I could use that framework to indicate streaming media, although for
> that application, an attribute per media stream, rather than
> per payload
> type would seem more appropriate.
>
> Thanks,
>
> Gonzalo
>
> Flemming Andreasen wrote:
> >
> > Gonzalo Camarillo wrote:
> >
> > > Hi,
> > >
> > > I kind of remember that some time ago there was a
> proposal about an SDP
> > > attribute to indicate that the receiver could use long buffers to
> > > receive the media. I believe it dealt with tones, mainly.
> > >
> >
> > Right (sort of). The basic discussion was support of fax
> and modem calls
> > and we've had a couple of different drafts on this topic
> (starting in
> > London 2001), with the latest one being
> > <draft-rajeshkumar-mmusic-gpmd-01.txt>. The approach taken
> has been to
> > associate optional attributes with a particular payload
> type in order to
> > indicate certain characeteristics about the media that the
> receiver may
> > benefit from knowing. For example, the gpmd draft defines a
> "voice band
> > data" attribute to indicate that the media is voice-band
> data. However, we
> > would not try and specify implementation specific ways of
> dealing with
> > "voice-band data" such as use of long buffers or other.
> >
> > >
> > > I was thinking that if we establish a session using SIP
> that will carry
> > > streaming media, we may want to tell the other end that
> it can buffer
> > > this stream.
> > >
> >
> > I believe the gpmd framework could be used for this, but in
> a slightly
> > different way. Rather than specifying that "media can be
> buffered" we would
> > have a more generic attribute that defines the media as
> "streaming" and
> > hence the receiver can apply whatever special processing it
> may desire for
> > streaming media, e.g. buffering it.
> >
> > >
> > > What is the status of that work? was there any interest
> in the group?
> > >
> >
> > There has been some interest expressed (mostly by modem
> folks) and the work
> > is being performed in the MMUSIC WG, although as an
> individual submission.
> > There are a few issues with the current gpmd draft and we
> will be issuing a
> > new version. Assuming it does not generate any major
> comments, we will then
> > be asking for a WG last call on it.
> >
> > -- Flemming
> >
> > >
> > > Thanks,
> > >
> > > Gonzalo
> > > _______________________________________________
> > > mmusic mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/mmusic
>
> --
> Gonzalo Camarillo         Phone :  [phone]
> Oy L M Ericsson Ab        Mobile:  [phone]
> Telecom R&D               Fax   :  [phone]
> FIN-02420 Jorvas          Email :  [e-mail]
> Finland                   http://www.hut.fi/~gonzalo
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mmusic