Re: [FECFRAME-PROTO] New SDP draft

["Rajiv Asati (rajiva)" <[e-mail]>]

> 	2. Are we going to specify a feedback description other 
> than the FEC-scheme specific one as part of SDP elements? 
> E.g., is the sender capable of receiving any FEC performance 
> feedback or whether the receiver capable of sending any feedback?

Given that it has to do with the capability of either sender or receiver
or both, it should be specified within the (common) configuration
information that can be utilized accordingly. It is the same field that
could be specified as either "rcv only" or "send only" etc.

Cheers,
Rajiv
 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Ali 
> Begen (abegen)
> Sent: Monday, February 04, 2008 5:26 PM
> To: Ulas Kozat
> Cc: [e-mail]
> Subject: Re: [FECFRAME-PROTO] New SDP draft
> 
> Hi Ulas.
>  
> Thanks for the comments.
>  
> 1- We define the priority field in the repair flow 
> descriptor. However, I did not want to use it in the examples 
> (not yet) since assigning priority means we can use multiple 
> repair flows in an additive manner. And as you know, that 
> issue is still at hand. I believe at least for now we should 
> not give examples involving additivity and prioritization.
>  
> However, different repair sizes are already used in the last example. 
>  
> 2- Good question. I am not sure whether that should be a part 
> of the FSSI (receiver side) or we should specify a new 
> separate element, which is part of the configuration 
> information (hence, common to all FEC schemes)? \
>  
> I am inclined towards including in the RS-FSSI? But, either 
> is fine with me. We decided to make it optional. So, the 
> configuration information may ignore or skip it.
>  
> Any comments?
>  
> -acbegen
> 
> 
> ________________________________
> 
> 	From: Ulas Kozat [mailto:[e-mail]] 
> 	Sent: Monday, February 04, 2008 2:05 PM
> 	To: Ali Begen (abegen)
> 	Cc: [e-mail]
> 	Subject: Re: [FECFRAME-PROTO] New SDP draft
> 	
> 	
> 	Ali,
> 	
> 	The document looks okay with the notes, etc. I have a 
> few comments: 
> 	1. Maybe we can add one more example for single source 
> flow and 2 repair flows with priority. Also, in such a 
> scenario, should we be able to define 2 different time 
> windows for each repair flow?
> 	2. Are we going to specify a feedback description other 
> than the FEC-scheme specific one as part of SDP elements? 
> E.g., is the sender capable of receiving any FEC performance 
> feedback or whether the receiver capable of sending any feedback?
> 	
> 	Ulas
> 	
> 	
> 	On Feb 3, 2008 3:41 AM, Ali Begen (abegen) 
> <[e-mail]> wrote:
> 	
> 
> 		Hi everyone,
> 		
> 		I made the changes we discussed last week in 
> the SDP draft. I am
> 		attaching the txt and xml files.
> 		
> 		I would like to hear your feedback before I 
> submit it as a WG document.
> 		Could you at least go over the new sections and 
> SDP examples?
> 		
> 		The changes include:
> 		- Divided the FEC-scheme-specific-information 
> (FSSI) container into two.
> 		Now, we have one container (Sender-side FSSI) 
> which includes the
> 		information required only by the sender. The 
> rest of the FSSI info goes
> 		to the other container (Receiver-side FSSI). 
> The FEC scheme decides what
> 		goes to where.
> 		
> 		- Media stream grouping: I updated the text 
> based on our last
> 		discussion. The discussion is still going on in 
> the MMUSIC and FECFRAME
> 		WGs. We need to come up with something that 
> allows us to associate the
> 		repair and source flows in a flexible manner. 
> RFC 3388 is severely
> 		limiting us.
> 		
> 		I also added the cases where we would want to 
> use multiple framework
> 		instances in Section 4.2.
> 		
> 		- Repair flow descriptors: I updated this 
> section (4.5) as we now have
> 		two containers for FSSI. I also changed the 
> "Scheme ID" to "Encoding ID"
> 		to be consistent with the framework draft.
> 		
> 		- Repair Window: Section 4.6 is re-written. 
> Now, we support both ms and
> 		us.
> 		
> 		- Section 5 is re-written. I added three SDP 
> examples. Please go over
> 		the examples and let me know if something is 
> missing or incorrect.
> 		
> 		Thanks,
> 		-acbegen
> 		
> 		
> 		_______________________________________________
> 		FECFRAME-PROTO mailing list
> 		[e-mail]
> 		http://www.ietf.org/mailman/listinfo/fecframe-proto
> 		
> 		
> 
> 
> 
_______________________________________________
FECFRAME-PROTO mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/fecframe-proto