Subject: [FECFRAME-PROTO] New SDP draft

From: "Ali Begen (abegen)" <[email-masked]>
Date: Sun, 3 Feb 2008 03:41:50 -0800

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
[email-masked]
http://www.ietf.org/mailman/listinfo/fecframe-proto

---

From: "Greg Shepherd" <[email-masked]>
Date: Tue, 5 Feb 2008 15:53:43 -0800

Did we ever come to conclusion with mmusic wrt grouping? The
conversation seemed to spin off track discussing uses/application of
groups but away from our original question.

Ali, can you summarize and restate to the mmusic list? ..or did I miss
something?

Thanks,
Greg

On Feb 4, 2008 2:26 PM, Ali Begen (abegen) <[email-masked]> wrote:
>
>
> 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:[email-masked]]
> Sent: Monday, February 04, 2008 2:05 PM
> To: Ali Begen (abegen)
> Cc: [email-masked]
> 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) <[email-masked]> wrote:
>
> > Hi everyone,
> >

---

From: "Ali Begen (abegen)" <[email-masked]>
Date: Tue, 5 Feb 2008 16:14:50 -0800

Hi Greg,

Nope, nobody has commented on the original question. The discussion was
merely about whether we should support inter-dependent FEC layers. In
the meeting, we decided not to support such FEC layers, but only
independent (maybe additive) FEC layers.

On the other hand, the main issue is still there. Flexible FEC grouping.
No comments from the chairs, either.

I will send another email to mmusic.

-acbegen

> -----Original Message-----
> From: Greg Shepherd [mailto:[email-masked]] 
> Sent: Tuesday, February 05, 2008 3:54 PM
> To: Ali Begen (abegen)
> Cc: Ulas Kozat; [email-masked]
> conversation seemed to spin off track discussing 
> uses/application of groups but away from our original question.
> 
> Ali, can you summarize and restate to the mmusic list? ..or 
> did I miss something?
> 
> Thanks,
> Greg
> 
> > 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.
> >
> > 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)? \
> >
> > We decided to make it optional. So, the configuration 
> information may 
> > ignore or skip it.
> >
> > Any comments?
> >
> > -acbegen
> >
> >
> > 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
> >
> >
> > > 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.
> > >
> > > 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.
> > >
> > > - 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"
> > > - 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
> > >
> > >

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sun, 17 Feb 2008 21:24:47 -0500

> 	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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ali 
> Begen (abegen)
> Sent: Monday, February 04, 2008 5:26 PM
> To: Ulas Kozat
> 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.
>  
> 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
> 
> 
> 	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
> 	
>

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sun, 17 Feb 2008 21:27:17 -0500

Hi Ali,

Sorry about the delay. I had few comments to
draft-begen-fecframe-sdp-elements-00. Perhaps, you could consider them
during the next revision.

~~~~~~~~~~~~~~~
1) Section 1- Introduction & Section 4

.....Framework, a set of parameters pertaining to the FEC Framework MUST
be initially communicated between the sender(s) and receiver(s).
One way to communicate this information is to use the Session
Description Protocol (SDP)[RFC4566].  SDP provides a simple ....

TO

.....Framework, a set of parameters pertaining to the FEC Framework
Configuration Information MUST be initially communicated between the
sender(s) and receiver(s). While a signaling protocol (such as one
described in draft-asati-fecframe-config-signaling) is required to
enable such communication, the parameters pertaining to the
Configuration Information must be appropriately encoded so that they are
carried by the signaling protocol.

One format to encode the parameters is to use the Session Description
Protocol (SDP)[RFC4566].  SDP provides a simple ....

2) Section 1- Introduction & Section 4

< The current text doesn't refer to the fact that SDP is used to encode
the FEC framework configuration information>

One way to communicate this information is to use the Session
Description Protocol (SDP)[RFC4566].  SDP provides a simple text-based
format for announcements and invitations to describe multimedia
sessions. These SDP announcements and invitations include sufficient
information for the sender(s) and receiver(s) to participate in the
multimedia sessions.  SDP also provides a framework for capability
negotiation, which MAY be used to negotiate all or a subset of the
parameters pertaining to the individual sessions.

TO

One format to communicate this information is to use the Session
Description Protocol (SDP)[RFC4566].  SDP provides a simple text-based
format to describe multimedia sessions (i.e. to encode some information)
signaled within an annoucement or invitation. The encoded information is
sufficient for the sender(s) and receiver(s) to participate in the
multimedia sessions. The multimedia session is considered to be an
instance of FEC Framework, as per this document. SDP also provides a
framework for capability negotiation, which MAY be used to negotiate all
or a subset of the parameters pertaining to the FEC Framework
configuration information.

Note that SDP does not provide the transport for dissemination of the
encoded information. Signaling Protocol such as the one described in
draft-asati-fecframe-config-signaling can be used to transport the SDP
encoded configuration information.

3) Section 1- Introduction & Section 4

< The current text doesn't refer to the fact that SDP is used to encode
the FEC framework configuration information>

The purpose of this document is to introduce the SDP elements that MUST
be used by the CDPs using the FEC Framework that choose SDP [RFC4566] as
their session description protocol.

TO

The purpose of this document is to introduce the SDP elements that MUST
be used by the CDPs using the FEC Framework that choose SDP [RFC4566] as
encoding format for the FEC Framework configuration information.

4) Section 1

We are freely interchanging stream and flow terms. Need to define them
and use them appropriately.  Suggest to stick with Flow.

5) Section 3.3 - FEC framework Config Info

... .. This information is called the FEC Framework Configuration
Information.  This information specifies how the sender applies
protection to the source flow(s) and how the repair flow(s) can be used
to recover lost data... . .
 
TO

.....This information is called the FEC Framework Configuration
Information.  This information specifies the parameter(s) that the
sender uses to apply protection to the source flow(s) and to recover the
lost data using the repair flow(s) .......

6) Section 4- FEC framework descriptors
The title should be changed to 'SDP Descriptors for FEC framework
configuration information'.

7) "FEC Framework Instance"

The configuration information is to be formulated for each FEC framework
instance. The SDP draft must include, if not already, a mean to encode
the "instance" identifier in addition to the SDP elements themselves,
since without the "instance" identifier, the config info may not be
useful. 

Is the "instance" the same as "group"? If so, then we definitely need to
add some text section 4 and section 4.2 to call it out.

8) Section 4.3 Source IP address

The section should also acknowledge that the Source IP address specified
in "origin:" attribute of the SDP message is independent of the Source
IP address(es) specified in the source-filter attribute.
Also need some verbiage regarding the source-filter usage at the session
level or media level or both.
 ~~~~~~~~~~~~~~

Cheers,
Rajiv 

> Sent: Sunday, February 03, 2008 6:42 AM
> To: [email-masked]
> Subject: [FECFRAME-PROTO] New SDP draft
> 
> Hi everyone,
>