RE: [MMUSIC] Streaming media

[Jose Rey <[e-mail]>]

Gonzalo,

thanks for your comments, see below.

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[e-mail]]
> Sent: Monday, December 16, 2002 3:02 PM
> To: Jose Rey
> Cc: Flemming Andreasen; mmusic; Janne Suotula (LMF)
> Subject: Re: [MMUSIC] Streaming media
>
>
> 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


This is already done but is, by itself, not enough.

'apt' is not used to group m-lines but to associate PTs. You can have an
m-line with different payload types PT1 and PT2 (say two cameras from
different angles) and both grouped together with one retransmission
m-line. If you just use the FID semantics there's no way to know for
which original PT the retransmissions are. 'apt' helps out here...

cheers,

Jose

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