Re: [FECFRAME-PROTO] New SDP draft
"Rajiv Asati (rajiva)" <rajiva@cisco.com> Mon, 18 February 2008 02:27 UTC
Return-Path: <fecframe-proto-bounces@ietf.org>
X-Original-To: ietfarch-fecframe-proto-archive@core3.amsl.com
Delivered-To: ietfarch-fecframe-proto-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B634A3A6BFC; Sun, 17 Feb 2008 18:27:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.262
X-Spam-Level:
X-Spam-Status: No, score=-3.262 tagged_above=-999 required=5 tests=[AWL=-0.825, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9epnJl99HYf; Sun, 17 Feb 2008 18:27:51 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B89273A6C2A; Sun, 17 Feb 2008 18:27:51 -0800 (PST)
X-Original-To: fecframe-proto@core3.amsl.com
Delivered-To: fecframe-proto@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBA6D3A67F7 for <fecframe-proto@core3.amsl.com>; Sun, 17 Feb 2008 18:27:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzXMrDVDkzgC for <fecframe-proto@core3.amsl.com>; Sun, 17 Feb 2008 18:27:48 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id ED9073A6BFC for <fecframe-proto@ietf.org>; Sun, 17 Feb 2008 18:27:47 -0800 (PST)
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 17 Feb 2008 21:27:45 -0500
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1I2Rju9004709 for <fecframe-proto@ietf.org>; Sun, 17 Feb 2008 21:27:45 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1I2QnSO013804 for <fecframe-proto@ietf.org>; Mon, 18 Feb 2008 02:27:45 GMT
Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Feb 2008 21:27:17 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sun, 17 Feb 2008 21:27:17 -0500
Message-ID: <15B86BC7352F864BB53A47B540C089B604F1F8D0@xmb-rtp-20b.amer.cisco.com>
In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5406755D80@xmb-sjc-215.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [FECFRAME-PROTO] New SDP draft
Thread-Index: AchmWcPQ/2cPVaSvQi2SWUyNdxQl7QLeUZuw
From: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
To: "Ali Begen (abegen)" <abegen@cisco.com>, fecframe-proto@ietf.org
X-OriginalArrivalTime: 18 Feb 2008 02:27:17.0289 (UTC) FILETIME=[C7BA0990:01C871D5]
Authentication-Results: rtp-dkim-2; header.From=rajiva@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; );
Subject: Re: [FECFRAME-PROTO] New SDP draft
X-BeenThere: fecframe-proto@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Fecframe protocol design team <fecframe-proto.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/fecframe-proto>, <mailto:fecframe-proto-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/fecframe-proto>
List-Post: <mailto:fecframe-proto@ietf.org>
List-Help: <mailto:fecframe-proto-request@ietf.org?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/fecframe-proto>, <mailto:fecframe-proto-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: fecframe-proto-bounces@ietf.org
Errors-To: fecframe-proto-bounces@ietf.org
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: fecframe-proto-bounces@ietf.org > [mailto:fecframe-proto-bounces@ietf.org] On Behalf Of Ali > Begen (abegen) > Sent: Sunday, February 03, 2008 6:42 AM > To: fecframe-proto@ietf.org > 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 FECFRAME-PROTO@ietf.org http://www.ietf.org/mailman/listinfo/fecframe-proto
- Re: [FECFRAME-PROTO] New SDP draft Greg Shepherd
- Re: [FECFRAME-PROTO] New SDP draft Ali Begen (abegen)
- Re: [FECFRAME-PROTO] New SDP draft Rajiv Asati (rajiva)
- Re: [FECFRAME-PROTO] New SDP draft Rajiv Asati (rajiva)