Re: [MMUSIC] Streaming media

[Gonzalo Camarillo <[e-mail]>]

Hi Jose,

Thanks for the link.

I was after something similar, although not that precise. That is, I
wanted the server to say "this is streaming media, it is safe to
implement large buffers", rather than "you should implement a buffer of
10 seconds for this stream". But anyway, the idea is interesting. 

However, it seems to me that rtx-time is only defined to work within
your retransmission framework. It might have been nice to have a general
parameter (although I would need to think about it more carefully).

A comment on the draft. You use the apt= parameter to reference the
original stream in the SDP description of the stream carrying
retransmissions. What you are doing is basically grouping two media
lines. I do not know the status of this draft (I suspect that it may
already be in IETF LC), but using the SDP grouping framework would have
been a good idea.

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-fid-06.txt

Thanks for the reference,

Gonzalo

Jose Rey wrote:
> 
> 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

-- 
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