Re: [FECFRAME-PROTO] New SDP draft

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

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 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Ali 
> Begen (abegen)
> Sent: Sunday, February 03, 2008 6:42 AM
> To: [e-mail]
> Subject: [FECFRAME-PROTO] New SDP draft
> 
> 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