Subject: [MMUSIC] Streaming media

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 04 Dec 2002 17:26:18 +0200

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.

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.

What is the status of that work? was there any interest in the group?

Thanks,

Gonzalo
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Flemming Andreasen <[email-masked]>
Date: Sat, 07 Dec 2002 18:44:43 -0500

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

> streaming media, we may want to tell the other end that it can buffer

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

---

From: Flemming Andreasen <[email-masked]>
Date: Sat, 07 Dec 2002 18:44:43 -0500

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Sat, 07 Dec 2002 18:44:43 -0500

-- Flemming

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 14 Dec 2002 14:59:14 +0200

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

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Jose Rey <[email-masked]>
Date: Mon, 16 Dec 2002 14:24:24 +0100

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: [email-masked] [mailto:[email-masked]]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,
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 16 Dec 2002 16:01:51 +0200

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 16 Dec 2002 15:36:33 +0100

Hi Gonzalo,

The retransmission proposal are using the fid attribute when session 
multiplexing is used to bind the original data  session to the 
retransmission data session. The apt attribute is still needed to bind 
the payload types together. As the original session can contain multiple 
PTs the retransmission PTs must be explicitly bound to its original.

Best

Regards

Gonzalo Camarillo wrote:

>>>>>I kind of remember that some time ago there was a
>>>>>          
>>>>>
>>>proposal about an SDP
>>>      
>>>
>>>>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
>>>      
>>>
>>>><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
>>>      
>>>
>>>>>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
>>>      
>>>
>>>>>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
>>>      
>>>

-- 

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Jose Rey <[email-masked]>
Date: Mon, 16 Dec 2002 15:45:46 +0100

Gonzalo,

thanks for your comments, see below.

> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Monday, December 16, 2002 3:02 PM
> To: Jose Rey
> Cc: Flemming Andreasen; mmusic; Janne Suotula (LMF)

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

> > original question, the
> draft-ietf-avt-rtp-retransmission-03.txt offers
> > > From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> > > Gonzalo Camarillo