Re: [MMUSIC] Streaming media

[Magnus Westerlund <[e-mail]>]

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:

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

-- 

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]



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