From tme@multicasttech.com Wed Apr 1 05:38:35 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C454928C181 for ; Wed, 1 Apr 2009 05:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.567 X-Spam-Level: X-Spam-Status: No, score=-103.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 6cro1hc5cnee for ; Wed, 1 Apr 2009 05:38:35 -0700 (PDT) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 3375A3A6E5B for ; Wed, 1 Apr 2009 05:35:51 -0700 (PDT) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 15172942 for fecframe@ietf.org; Wed, 01 Apr 2009 07:34:18 -0500 Message-Id: From: Marshall Eubanks To: fecframe@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 1 Apr 2009 08:36:50 -0400 X-Mailer: Apple Mail (2.930.3) Subject: [Fecframe] WGLC on draft-ietf-fecframe-interleaved-fec-scheme X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 12:38:35 -0000 As was discussed in the meeting last week, I would like to start a Working Group Last Call on draft-ietf-fecframe-interleaved-fec-scheme . This draft can be found at http://tools.ietf.org/html/draft-ietf-fecframe-interleaved-fec-scheme-02 This WGLC will run until midnight, UTC, on April 16th. Please read this draft and send your comments and questions to the list. Regards Marshall From rajiva@cisco.com Wed Apr 1 05:58:41 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 169F93A688F for ; Wed, 1 Apr 2009 05:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.63 X-Spam-Level: X-Spam-Status: No, score=-5.63 tagged_above=-999 required=5 tests=[AWL=-0.530, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, WHOIS_MYPRIVREG=1.499] 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 ojiM3S+aVIwg for ; Wed, 1 Apr 2009 05:58:40 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3BDE43A67F4 for ; Wed, 1 Apr 2009 05:58:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,306,1235952000"; d="scan'208";a="164918205" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 01 Apr 2009 12:59:40 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n31CxeuF009769; Wed, 1 Apr 2009 05:59:40 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n31Cxdnv014609; Wed, 1 Apr 2009 12:59:40 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 08:59:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Apr 2009 08:59:37 -0400 Message-ID: <15B86BC7352F864BB53A47B540C089B6077E2277@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC for draft-ietf-fecframe-config-signaling Thread-Index: AcmyybZWJhYeaihPRuedXl1DzpNCmw== From: "Rajiv Asati (rajiva)" To: X-OriginalArrivalTime: 01 Apr 2009 12:59:39.0892 (UTC) FILETIME=[B7D1CB40:01C9B2C9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=369; t=1238590780; x=1239454780; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rajiva@cisco.com; z=From:=20=22Rajiv=20Asati=20(rajiva)=22=20 |Subject:=20WGLC=20for=20draft-ietf-fecframe-config-signali ng |Sender:=20; bh=Ty3XJQFecQTxaPt1zRuEfx5SIV2BXZf1/kFZYWILMr0=; b=eoXgsca/Xr6My2zIUyoFUgbRtt3V9TxztO7lml/lZNPGGTofk0m0Buqcsi ylFt/Vp/aDVZ24x6NXHtfFs6d76dwIltpBl+d7a2Dm4X7nATyDyNHvt/qp84 EJaRqax0dC; Authentication-Results: sj-dkim-4; header.From=rajiva@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Fecframe] WGLC for draft-ietf-fecframe-config-signaling X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 12:58:41 -0000 Greg, Marshall, Was there ever a WGLC on draft-ietf-fecframe-config-signaling? Sorry, if I lost track of it. If not, then could you plesae issue one? I recall that the plan was to issue WGLC on draft-ietf-fecframe-config-signaling after the last to last IETF (ietf73). =20 http://www.nabble.com/FECFrame-WG-Agenda---IETF-73-td20355517.html Cheers, Rajiv From abegen@cisco.com Thu Apr 2 12:25:32 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6A363A6A6E for ; Thu, 2 Apr 2009 12:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.726 X-Spam-Level: X-Spam-Status: No, score=-5.726 tagged_above=-999 required=5 tests=[AWL=-0.626, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, WHOIS_MYPRIVREG=1.499] 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 l3Q2qxS3Wa1T for ; Thu, 2 Apr 2009 12:25:24 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 6984F3A6A40 for ; Thu, 2 Apr 2009 12:25:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,315,1235952000"; d="scan'208";a="149725515" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 02 Apr 2009 19:26:20 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n32JQK4h028837 for ; Thu, 2 Apr 2009 12:26:20 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n32JQKoa007458 for ; Thu, 2 Apr 2009 19:26:20 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 12:26:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Apr 2009 12:26:18 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540902A92D@xmb-sjc-215.amer.cisco.com> In-Reply-To: <15B86BC7352F864BB53A47B540C089B6077E2277@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] WGLC for draft-ietf-fecframe-config-signaling Thread-Index: AcmyybZWJhYeaihPRuedXl1DzpNCmwA/wO9g References: <15B86BC7352F864BB53A47B540C089B6077E2277@xmb-rtp-20b.amer.cisco.com> From: "Ali C. Begen (abegen)" To: "Rajiv Asati (rajiva)" X-OriginalArrivalTime: 02 Apr 2009 19:26:20.0169 (UTC) FILETIME=[E6ACDF90:01C9B3C8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1055; t=1238700380; x=1239564380; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[Fecframe]=20WGLC=20for=20draft-ietf-fe cframe-config-signaling |Sender:=20; bh=fzE0MHcOMMtiqYSFME+Nc1dBPmvtp74uS6mpE//l/rg=; b=Y0WvyqZ9mXkiz1O2Tn2n81IlL4O9yDaigmvtQyMXAr0pdRYf/FSLbpcbkR yltgQPWq1IAWIiswh3zsG+/BgSKSNc8KfIbG8Jx4P5j5l62uWjN3ireidMKb YYoBBQ7N+AfeUbdOVOVd6AwtUl2GiuJba+qmjzYXWHKIDH5ARXYSk=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: fecframe@ietf.org Subject: Re: [Fecframe] WGLC for draft-ietf-fecframe-config-signaling X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 19:25:32 -0000 Hi Rajiv, The latest decision from the session is to last call the framework draft = and then last call the other drafts that are dependent on it, like = yours, sdp draft, raptor draft, etc. -acbegen=20 > -----Original Message----- > From: fecframe-bounces@ietf.org=20 > [mailto:fecframe-bounces@ietf.org] On Behalf Of Rajiv Asati (rajiva) > Sent: Wednesday, April 01, 2009 6:00 AM > To: fecframe@ietf.org > Subject: [Fecframe] WGLC for draft-ietf-fecframe-config-signaling >=20 > Greg, Marshall, >=20 > Was there ever a WGLC on=20 > draft-ietf-fecframe-config-signaling? Sorry, if > I lost track of it. If not, then could you plesae issue one? >=20 > I recall that the plan was to issue WGLC on > draft-ietf-fecframe-config-signaling after the last to last IETF > (ietf73). =20 > http://www.nabble.com/FECFrame-WG-Agenda---IETF-73-td20355517.html >=20 > Cheers, > Rajiv > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe >=20 From vincent.roca@inrialpes.fr Fri Apr 3 05:21:42 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 057013A6862 for ; Fri, 3 Apr 2009 05:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 J7A9b76o-dit for ; Fri, 3 Apr 2009 05:21:40 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id 3C3043A6C65 for ; Fri, 3 Apr 2009 05:21:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,431,1233529200"; d="txt'?scan'208";a="26956268" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO macbook-pro-de-roca.local) ([82.236.155.50]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Apr 2009 14:22:37 +0200 Message-ID: <49D5FF8D.8020806@inrialpes.fr> Date: Fri, 03 Apr 2009 14:22:37 +0200 From: Vincent Roca User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: fecframe@ietf.org Content-Type: multipart/mixed; boundary="------------040405090902010308030304" Subject: [Fecframe] Review of draft-ietf-fecframe-framework-03 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 12:21:42 -0000 This is a multi-part message in MIME format. --------------040405090902010308030304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mark, everybody, Since the goal was to start a WGLC on the framework document, I anticipated a little bit the announce... (sorry if it creates problems). Here are my comments. Regards, Vincent --------------040405090902010308030304 Content-Type: text/plain; name="fecframe-framework-03_comments.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fecframe-framework-03_comments.txt" Comments to draft-ietf-fecframe-framework-03 - VR ------------------------------------------------- For discussion... 1/ Terminology: --------------- The terminology is not sufficiently well defined and throughout the text we find several terms for the same concept (I won't list them here). I tried to compile them below. At the sender, from top to bottom: * the application layer provides "Source Transport Data Payloads" through one or several "Source Data Flow(s)". * the "Source Transport Data Payloads" are gathered in a "Source Block". * after the F, L and padding fields have been added to each "Source Transport Data Payload" for the purpose of FEC encoding, the resulting unit of data is called the "Source Packet Information (SPI)" (NB: this comes from the Raptor I-D). * from the FEC scheme point of view, we now have "Source Symbols" (i.e., a subset of the "Source Packet Information") and "Repair Symbols". They are globally called "Encoding Symbols". * the unit of data containing the source information, plus the "Explicit Source FEC Payload ID" (if used), is now called the "FEC Source Packet". It is given to the transport protocol. * the unit of data containing repair information, plus the "Repair FEC Payload ID", is now called "FEC Repair Packet". It can contain one or more "repair symbols" depending on the FEC scheme. It is given to the transport protocol. We should discuss the above names IMHO... In particular I'm not satisfied by the "Source Transport Data Payloads" which follows the transport protocol point of view (payload given to the transport protocol) rather than what leaves the application layer. Additionally, it's no longer the transport payload if the "Explicit Source FEC Payload ID" is appended by the FEC framework. I suggest: "Application Source Data Units", or simply "Application Data Units". There is also a clash between the "Source Packet Information" and the "Source Transport Data Payload". The two names should be close to one another. I suggest: "Application (Source) Data Unit Information" I think that, inside the FEC scheme itself, the usual terminology (source/repair/encoding symbols) must be used. This is common terminology with the FEC schemes coming from the RMT WG. Then we must make sure that the agreed terminology, and only it, is used in this I-D and others. 2/ Section 6.5. "FEC Framework Configuration Information" --------------------------------------------------------- I have several comments WRT the pieces of information included in the FFCI. 2.1/ It is said: " 1. Identification of the packet flow(s) carrying FEC Repair packets, known as the FEC repair flow(s)." I think we need more than just an identification. We need to know the *number* of FEC repair flows for this FEC framework instance and the *definition* of each FEC repair flow (e.g., the associated tuple). 2.2/ It is said: " b. An integer identifier for this flow definition (i.e. tuple). This identifier MUST be unique amongst all source packet flows which are protected by the same FEC repair flow." So, if I follow this text, if a source flow is protected by 2 FEC repair flows, this source flow can be assigned two different identifiers. This is a bit strange! I suggest that the identifier be unique among a FEC framework instance. The drawback I see, however, when this identifier is encoded in a single byte (e.g. Raptor or R-), is the limited number (256) of source data flows that can be protected globally. But is 256 really an issue? 2.3/ It is said: " 4. The length of the Explicit Source FEC Payload Id, in bytes" Why should the length be communicated to the FEC framework instance whereas the Explicit Source FEC Payload ID is totally defined by the FEC scheme, whose FEC Encoding ID is provided to the FEC framework? 3/ Section 8. "Transport protocols" ----------------------------------- It is said: "The following transport protocols are supported:" What does "supported" mean, since the framework is relatively independent of the transport protocol used (it impacts the tuple used to identify flows and it should preserve the data unit boundaries, but that's all). I'd be in favor of having a less directive text, like: "The FEC framework is compatible with any transport protocol that fulfills the requirements (e.g., in terms of real-time delivery of datagrams) of the original source data flows. Examples of such protocols include: o User Datagram Protocol (UDP) o Datagram Congestion Control Protocol (DCCP)" 4/ Section 9.1 "Normative requirements" --------------------------------------- I do understand and agree with the fact that there is a reasonable limit to the repair overhead. However I'm wondering if it makes sense to provide an actual figure. This limit depends on the target use-case, and the framework I-D specifies the architecture, not the use-case. There is also a potential problem with the current wording: " The bandwidth of FEC Repair packet flows MUST NOT exceed the bandwidth of the source packet flows being protected." In complex scenarios, it could result in non desirable limitations. This can be the case with Fig. 1 of draft-ietf-fecframe-sdp-elements-02: ____| FEC FRAMEWORK / | INSTANCE / | 3: Repair Flow / SOURCE FLOWS / | FEC FRAMEWORK 0: Source Flow |___/ |------| INSTANCE __| 1: Source Flow | | 4: Repair Flow | | 2: Source Flow | | FEC FRAMEWORK |__________________________| INSTANCE | 5: Repair Flow | 6: Repair Flow | 7: Repair Flow Admittedly (1) the total bit rate of the 7 repair flows can be lower than that of the 3 source flows and (2) there are several framework instances. But this is an example where the section 9.1 limit can be a problem if we measure the aggregated repair flow bandwidth at the sending host. I suggest to have a less directive text, like: The bandwidth of FEC Repair packet flows MUST NOT exceed a certain threshold of the bandwidth of the source packet flows being protected. This threshold depends on the use-case where the FEC framework is used. When transmissions take place over Internet, the bandwidth of the FEC Repair packet flow(s) of a single FEC framework instance MUST NOT exceed the bandwidth of the source packet flow(s). In any case I agree with you, Mark, that using FEC codes in a rateless way is definitively useless ;-) 5/ Section 6.2. "Structure of the source block" ----------------------------------------------- It is said: " For each source transport payload included in a source block, the following information is provided to the FEC Scheme: o A description of the source transport flow with which the transport payload is associated (See 6.5)" I'd rather provide the "identification" of the source flow. The description of the flow is provided only once, upon FEC framework instantiation initialization. 6/ Section 6.3.1. "Generic Explicit Source FEC Payload Id" ---------------------------------------------------------- I don't think that any of the current FEC schemes specifies this Generic Explicit Source FEC Payload Id. This is a problem... Besides, how is the 2 byte counter managed? Does it take into account the source block structure or not? It seems that it is the case, but it is not clearly said that the counter should be reset to 0 at the beginning of a new source block. Additionally, the various FEC schemes can have different maximum source block sizes which means that the source block structure can differ. Maybe we should say that all the FEC schemes MUST share the same source block structure if we want the FEC Source Packets to be shared between the various FEC schemes. Additional comments: -------------------- ** Current I-D mentions either "Content Delivery Protocol" or CDP. I suggest to use only CDP throughout of the text. ** Section 6.6. "FEC Scheme requirements" It is said: " ...and the valid packet payload sizes (where packet payload refers to the space - not necessarily contiguous - within a packet dedicated to carrying encoding symbol bytes)." Sorry, I don't understand "not necessarily contiguous". I also suggest to say: "...and the valid transport (e.g., UDP) datagram payload sizes". (if I understand correctly the goal). --------------040405090902010308030304-- From magnus.westerlund@ericsson.com Wed Apr 15 07:56:50 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB77E3A6E84 for ; Wed, 15 Apr 2009 07:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.188 X-Spam-Level: X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 tXqOpkHfclzM for ; Wed, 15 Apr 2009 07:56:50 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id EF8743A6E0B for ; Wed, 15 Apr 2009 07:56:49 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0D8A921FB3 for ; Wed, 15 Apr 2009 16:58:01 +0200 (CEST) X-AuditID: c1b4fb3e-ae824bb0000024d5-b8-49e5f05aae48 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AC8042165E for ; Wed, 15 Apr 2009 16:34:02 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 16:31:28 +0200 Received: from [147.214.183.173] ([147.214.183.173]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 16:31:27 +0200 Message-ID: <49E5EFC0.90709@ericsson.com> Date: Wed, 15 Apr 2009 16:31:28 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "fecframe@ietf.org" X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Apr 2009 14:31:27.0982 (UTC) FILETIME=[DCAE20E0:01C9BDD6] X-Brightmail-Tracker: AAAAAA== Subject: [Fecframe] Ongoing WG last calls X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 14:56:50 -0000 Hi, I do expect to see comments and reviews being published to the list. We can't go forward only on silent consensus. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From csp@csperkins.org Wed Apr 15 08:54:15 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E95A43A694A for ; Wed, 15 Apr 2009 08:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.839 X-Spam-Level: X-Spam-Status: No, score=-3.839 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 zKyhOiXaTI00 for ; Wed, 15 Apr 2009 08:54:15 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by core3.amsl.com (Postfix) with ESMTP id 223983A6936 for ; Wed, 15 Apr 2009 08:54:15 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1Lu7SR-0003VH-Zn; Wed, 15 Apr 2009 15:55:27 +0000 Message-Id: <2BAE4713-AB3A-4117-BE9F-FB23E3F5F8A5@csperkins.org> From: Colin Perkins To: Marshall Eubanks In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 15 Apr 2009 16:55:26 +0100 References: X-Mailer: Apple Mail (2.930.3) Cc: fecframe@ietf.org Subject: Re: [Fecframe] WGLC on draft-ietf-fecframe-interleaved-fec-scheme X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 15:54:16 -0000 On 1 Apr 2009, at 13:36, Marshall Eubanks wrote: > As was discussed in the meeting last week, I would like to start a > Working Group Last Call on > > draft-ietf-fecframe-interleaved-fec-scheme . This draft can be found > at > > http://tools.ietf.org/html/draft-ietf-fecframe-interleaved-fec-scheme-02 > > This WGLC will run until midnight, UTC, on April 16th. Please read > this draft and send your comments and questions to the list. [Apologies for the late review - my day job got in the way of IETF these past few months...] I note that this draft protects the P, X, and CC fields of the source packets using the corresponding fields in the RTP header of the repair packets. This was one of the main problems with RFC 2733, since it produces repair packets that sometimes fail the RTP header validity checks in RFC 3550, and one of the drivers for the changed FEC header in RFC 5109. I guess we may have no choice but to perpetuate this mistake here, to maintain backwards compatibility, but this draft should at least document the issue. -- Colin Perkins http://csperkins.org/ From abegen@cisco.com Wed Apr 15 09:04:59 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36FD83A6BBB for ; Wed, 15 Apr 2009 09:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.458 X-Spam-Level: X-Spam-Status: No, score=-6.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 QYtXNrV4Vl1j for ; Wed, 15 Apr 2009 09:04:58 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 4273B3A6B9E for ; Wed, 15 Apr 2009 09:04:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,192,1238976000"; d="scan'208";a="153554159" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 15 Apr 2009 16:06:10 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3FG6AtV007899; Wed, 15 Apr 2009 09:06:10 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3FG6AtK013717; Wed, 15 Apr 2009 16:06:10 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 09:06:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Apr 2009 09:05:53 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540913E654@xmb-sjc-215.amer.cisco.com> In-Reply-To: <2BAE4713-AB3A-4117-BE9F-FB23E3F5F8A5@csperkins.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] WGLC on draft-ietf-fecframe-interleaved-fec-scheme Thread-Index: Acm94p3CBMy+lXZbQGObtHsY32baiAAALnvQ References: <2BAE4713-AB3A-4117-BE9F-FB23E3F5F8A5@csperkins.org> From: "Ali C. Begen (abegen)" To: "Colin Perkins" , "Marshall Eubanks" X-OriginalArrivalTime: 15 Apr 2009 16:06:10.0397 (UTC) FILETIME=[17A9D8D0:01C9BDE4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1915; t=1239811570; x=1240675570; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[Fecframe]=20WGLC=20on=20draft-ietf-fec frame-interleaved-fec-scheme |Sender:=20; bh=zM5SerDMjSjXnGfIe+yZreBTqbXD0eifp+w/vrGewdU=; b=TYonzPgGHYTizI+aUxvbsTiN0VD9EljM0QM1EVZi5US4a6d0EBjnqNFK+D mGIdOh/vE1mLGy9XshFGbmVM6PDmxUfevkwoJAC4gYha6tHcToSsdhxZc+m1 N594A7nZxw; Authentication-Results: sj-dkim-4; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: fecframe@ietf.org Subject: Re: [Fecframe] WGLC on draft-ietf-fecframe-interleaved-fec-scheme X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 16:04:59 -0000 (Not sure if I have to cc AVT on this message)=20 This is a good suggestion. I'll take care of it in the revision (after = all comments are received). Thanks. -acbegen > -----Original Message----- > From: fecframe-bounces@ietf.org=20 > [mailto:fecframe-bounces@ietf.org] On Behalf Of Colin Perkins > Sent: Wednesday, April 15, 2009 8:55 AM > To: Marshall Eubanks > Cc: fecframe@ietf.org > Subject: Re: [Fecframe] WGLC on=20 > draft-ietf-fecframe-interleaved-fec-scheme >=20 > On 1 Apr 2009, at 13:36, Marshall Eubanks wrote: > > As was discussed in the meeting last week, I would like to start a > > Working Group Last Call on > > > > draft-ietf-fecframe-interleaved-fec-scheme . This draft can=20 > be found =20 > > at > > > >=20 > http://tools.ietf.org/html/draft-ietf-fecframe-interleaved-fec -scheme-02 > > > > This WGLC will run until midnight, UTC, on April 16th. Please read > > this draft and send your comments and questions to the list. >=20 >=20 > [Apologies for the late review - my day job got in the way of IETF =20 > these past few months...] >=20 > I note that this draft protects the P, X, and CC fields of=20 > the source =20 > packets using the corresponding fields in the RTP header of=20 > the repair =20 > packets. This was one of the main problems with RFC 2733, since it =20 > produces repair packets that sometimes fail the RTP header validity =20 > checks in RFC 3550, and one of the drivers for the changed=20 > FEC header =20 > in RFC 5109. I guess we may have no choice but to perpetuate this =20 > mistake here, to maintain backwards compatibility, but this draft =20 > should at least document the issue. >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe >=20 From tme@multicasttech.com Sat Apr 18 10:57:14 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 554DA3A6C2C for ; Sat, 18 Apr 2009 10:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.964 X-Spam-Level: X-Spam-Status: No, score=-102.964 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 7QmnVOQ3dii4 for ; Sat, 18 Apr 2009 10:57:14 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 2F75C3A6E2B for ; Sat, 18 Apr 2009 10:57:14 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 8E47D39D9E5D for ; Sat, 18 Apr 2009 13:58:28 -0400 (EDT) Message-Id: <14F76614-5B0C-4296-8CF5-6FA3B100EEF1@multicasttech.com> From: Marshall Eubanks To: fecframe@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 18 Apr 2009 13:58:27 -0400 X-Mailer: Apple Mail (2.930.3) Subject: [Fecframe] Working Group Last Call on draft-ietf-fecframe-framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 17:57:14 -0000 Based on the discussion at the FECFRAME meeting in San Francisco, I would like to issue a working group last call on draft-ietf-fecframe-framework-03. This document can be found at http://www.ietf.org/internet-drafts/draft-ietf-fecframe-framework-03.txt This is an essential document for the Fecframe work, so I would like to encourage everyone to read it again and comment. This last call will end on Monday, May 4th, 2009. Regards Marshall Eubanks From tme@multicasttech.com Sat Apr 18 11:03:01 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FC5028C129 for ; Sat, 18 Apr 2009 11:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.962 X-Spam-Level: X-Spam-Status: No, score=-102.962 tagged_above=-999 required=5 tests=[AWL=-0.363, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 WSzuQlDRtK71 for ; Sat, 18 Apr 2009 11:03:00 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id C101B28C128 for ; Sat, 18 Apr 2009 11:03:00 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 2AEFA39DA0C9 for ; Sat, 18 Apr 2009 14:04:15 -0400 (EDT) Message-Id: <387DA3D4-8B91-48C8-BB08-3C0725D112F8@multicasttech.com> From: Marshall Eubanks To: fecframe@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 18 Apr 2009 14:04:14 -0400 X-Mailer: Apple Mail (2.930.3) Subject: [Fecframe] Working Group Last Call on draft-ietf-fecframe-config-signaling X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 18:03:01 -0000 I think that this document is also ready, so I would like to issue a working group last call on draft-ietf-fecframe-config-signaling-01. This document can be found at http://tools.ietf.org/id/draft-ietf-fecframe-config-signaling-01.txt I encourage everyone to read this document and comment during the last call period. This last call will end on Monday, May 4th, 2009. Regards Marshall Eubanks From root@core3.amsl.com Sat Apr 18 14:00:02 2009 Return-Path: X-Original-To: fecframe@ietf.org Delivered-To: fecframe@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1AAC028C15D; Sat, 18 Apr 2009 14:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090418210002.1AAC028C15D@core3.amsl.com> Date: Sat, 18 Apr 2009 14:00:02 -0700 (PDT) Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-interleaved-fec-scheme-03.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 21:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the FEC Framework Working Group of the IETF. Title : RTP Payload Format for 1-D Interleaved Parity FEC Author(s) : A. Begen Filename : draft-ietf-fecframe-interleaved-fec-scheme-03.txt Pages : 31 Date : 2009-04-18 This document defines a new RTP payload format for the Forward Error Correction (FEC) that is generated by the 1-D interleaved parity code from a source media encapsulated in RTP. The 1-D interleaved parity code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The 1-D interleaved parity code offers a good protection against bursty packet losses at a cost of decent complexity. The new payload format defined in this document is used (with some exceptions) as a part of the DVB Application-layer FEC specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interleaved-fec-scheme-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-fecframe-interleaved-fec-scheme-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-18135807.I-D@ietf.org> --NextPart-- From abegen@cisco.com Sat Apr 18 14:03:24 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30C123A6C5A; Sat, 18 Apr 2009 14:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.457 X-Spam-Level: X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 hqpZ+NQ1OcnE; Sat, 18 Apr 2009 14:03:23 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 465593A6988; Sat, 18 Apr 2009 14:03:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,210,1238976000"; d="scan'208";a="288701445" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 18 Apr 2009 21:04:38 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3IL4cDJ004000; Sat, 18 Apr 2009 14:04:38 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3IL4cei021300; Sat, 18 Apr 2009 21:04:38 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Apr 2009 14:04:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sat, 18 Apr 2009 14:03:36 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54091BAA88@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03 Thread-Index: AcnAaI0k+CHA6Xe+Sfy0BV96KkoCXgAAB9bA From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 18 Apr 2009 21:04:37.0765 (UTC) FILETIME=[48869B50:01C9C069] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2324; t=1240088678; x=1240952678; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20FW=3A=20New=20Version=20Notification=20for=20dr aft-ietf-fecframe-interleaved-fec-scheme-03=20 |Sender:=20; bh=woGjytyxYttCHrOb85Z2AIIet5IphOG9dp8aMD7Kq5k=; b=sToCP6K2C7RxZ8wckFZmjRXXIjXDNkE64OfOJX7N5uGI98m8v+/8jWxINa +rNvzutU5BM46MhOEhX2FxAnAe1xM+8qxVNtYzWQjiZZX6GJsA2AGwGMRWs/ Q3Xsj3lqoa/GHIDuyyabFjFTQ9y8ns0WfvPGLRW/UNYowJl9SONYQ=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: avt@ietf.org Subject: [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 21:03:24 -0000 VGhpcyB1cGRhdGUgYWRkcmVzc2VzIGFsbCB0aGUgY29tbWVudHMgcmVjZWl2ZWQgaW4gdGhlIFdH TEMgcGVyaW9kIGluaXRhdGVkIG9uIEFwcmlsIDFzdC4gSWYgdGhlcmUgYXJlIGZ1cnRoZXIgY29t bWVudHMsIHBsZWFzZSBwb3N0IHRoZW0gc29vbiBhcyB3ZSB3b3VsZCBsaWtlIHRvIG1vdmUgZm9y d2FyZCB3aXRoIHRoaXMgZHJhZnQuDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUtMDMudHh0DQoNCkJS LA0KLWFjYmVnZW4gDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJRVRGIEkt RCBTdWJtaXNzaW9uIFRvb2wgW21haWx0bzppZHN1Ym1pc3Npb25AaWV0Zi5vcmddIA0KU2VudDog U2F0dXJkYXksIEFwcmlsIDE4LCAyMDA5IDE6NTggUE0NClRvOiBBbGkgQy4gQmVnZW4gKGFiZWdl bikNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1mZWNm cmFtZS1pbnRlcmxlYXZlZC1mZWMtc2NoZW1lLTAzIA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUtMDMudHh0IGhhcyBi ZWVuIHN1Y2Nlc3NmdWx5IHN1Ym1pdHRlZCBieSBBbGkgQmVnZW4gYW5kIHBvc3RlZCB0byB0aGUg SUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWlldGYtZmVjZnJhbWUtaW50ZXJs ZWF2ZWQtZmVjLXNjaGVtZQ0KUmV2aXNpb246CSAwMw0KVGl0bGU6CQkgUlRQIFBheWxvYWQgRm9y bWF0IGZvciAxLUQgSW50ZXJsZWF2ZWQgUGFyaXR5IEZFQw0KQ3JlYXRpb25fZGF0ZToJIDIwMDkt MDQtMTgNCldHIElEOgkJIGZlY2ZyYW1lDQpOdW1iZXJfb2ZfcGFnZXM6IDMxDQoNCkFic3RyYWN0 Og0KVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IFJUUCBwYXlsb2FkIGZvcm1hdCBmb3IgdGhl IEZvcndhcmQgRXJyb3INCkNvcnJlY3Rpb24gKEZFQykgdGhhdCBpcyBnZW5lcmF0ZWQgYnkgdGhl IDEtRCBpbnRlcmxlYXZlZCBwYXJpdHkgY29kZQ0KZnJvbSBhIHNvdXJjZSBtZWRpYSBlbmNhcHN1 bGF0ZWQgaW4gUlRQLiAgVGhlIDEtRCBpbnRlcmxlYXZlZCBwYXJpdHkNCmNvZGUgaXMgYSBzeXN0 ZW1hdGljIGNvZGUsIHdoZXJlIGEgbnVtYmVyIG9mIHJlcGFpciBzeW1ib2xzIGFyZQ0KZ2VuZXJh dGVkIGZyb20gYSBzZXQgb2Ygc291cmNlIHN5bWJvbHMgYW5kIHNlbnQgaW4gYSByZXBhaXIgZmxv dw0Kc2VwYXJhdGUgZnJvbSB0aGUgc291cmNlIGZsb3cgdGhhdCBjYXJyaWVzIHRoZSBzb3VyY2Ug c3ltYm9scy4gIFRoZQ0KMS1EIGludGVybGVhdmVkIHBhcml0eSBjb2RlIG9mZmVycyBhIGdvb2Qg cHJvdGVjdGlvbiBhZ2FpbnN0IGJ1cnN0eQ0KcGFja2V0IGxvc3NlcyBhdCBhIGNvc3Qgb2YgZGVj ZW50IGNvbXBsZXhpdHkuICBUaGUgbmV3IHBheWxvYWQgZm9ybWF0DQpkZWZpbmVkIGluIHRoaXMg ZG9jdW1lbnQgaXMgdXNlZCAod2l0aCBzb21lIGV4Y2VwdGlvbnMpIGFzIGEgcGFydCBvZg0KdGhl IERWQiBBcHBsaWNhdGlvbi1sYXllciBGRUMgc3BlY2lmaWNhdGlvbi4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdC4NCg0KDQo= From abegen@cisco.com Tue Apr 21 14:51:13 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DE5D3A6909; Tue, 21 Apr 2009 14:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.457 X-Spam-Level: X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 IhRJXDewYtKq; Tue, 21 Apr 2009 14:51:12 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6B2BA3A6D19; Tue, 21 Apr 2009 14:51:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,226,1238976000"; d="scan'208";a="290373109" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 21 Apr 2009 21:52:20 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3LLqK66012433; Tue, 21 Apr 2009 14:52:20 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3LLqKZH025683; Tue, 21 Apr 2009 21:52:20 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Apr 2009 14:52:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Apr 2009 14:52:17 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5409250056@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Additive FEC flows Thread-Index: AcnCy3A8L5fVyraVRjiT9EUqpNg1Lg== From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 21 Apr 2009 21:52:20.0072 (UTC) FILETIME=[71D53E80:01C9C2CB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1157; t=1240350740; x=1241214740; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20Additive=20FEC=20flows |Sender:=20; bh=GDDnLXZwl7zJiN6YGUOkj39fU+/4emNdMcAIIhvRah0=; b=ZQEUjWeLw9VUxuo9i/IyG/AyfZ69FW+mQvHFNTWNghZBSdqLJTkRaexbwB UCyo5o9zx2fF1zAUmaLbwAdDf+4C+0kZFqW1VfkFGVVetT5VM0tdok7wkGNN AuWD5WiYNC; Authentication-Results: sj-dkim-4; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: mmusic@ietf.org Subject: [Fecframe] Additive FEC flows X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 21:51:13 -0000 This question is related to draft 4756bis, which is an MMUSIC draft but = the question probably belongs to FECFRAME. Comments are welcome from = both WGs. In the new semantics we are proposing (FEC-XR), which supports = describing additive repair flows in the SDP (Additivity is signaled if = the repair flows are in the same group). There is a "language" question = and I would like to hear your opinions. Suppose that we have a source flow (S1) and two repair flows (R1, R2). = If the repair flows are not additive with each other, we MUST have in = the SDP: a=3Dgroup:FEC-XR S1 R1 a=3Dgroup:FEC-XR S1 R2 However, if the repair flows are additive, MUST or SHOULD we write the = following? a=3Dgroup:FEC-XR S1 R1 R2 Because writing a=3Dgroup:FEC-XR S1 R1 a=3Dgroup:FEC-XR S1 R2 would not be strictly wrong, either. In other words, we must state = explicitly when the repair flows are not additive, but are we also = required to state explicitly when they are additive? My personal view is = that we "must" do so to avoid any confusion and fully benefit from this = new semantics. -acbegen From tme@multicasttech.com Tue Apr 21 16:11:36 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EED23A7057; Tue, 21 Apr 2009 16:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.956 X-Spam-Level: X-Spam-Status: No, score=-102.956 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 rwTIAy8RL1L3; Tue, 21 Apr 2009 16:11:35 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 32A8C3A6B07; Tue, 21 Apr 2009 16:11:35 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id ADDEF3A3A6AF; Tue, 21 Apr 2009 19:12:50 -0400 (EDT) Message-Id: <0DDC662C-C82B-4BDA-9FA4-6295617EBDF6@multicasttech.com> From: Marshall Eubanks To: "Ali C. Begen (abegen)" In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5409250056@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 21 Apr 2009 19:12:45 -0400 References: <04CAD96D4C5A3D48B1919248A8FE0D5409250056@xmb-sjc-215.amer.cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: mmusic@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] Additive FEC flows X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 23:11:36 -0000 I would say that this is a MUST. Of course, most repair flows will be additive. Marshall On Apr 21, 2009, at 5:52 PM, Ali C. Begen (abegen) wrote: > This question is related to draft 4756bis, which is an MMUSIC draft > but the question probably belongs to FECFRAME. Comments are welcome > from both WGs. > > In the new semantics we are proposing (FEC-XR), which supports > describing additive repair flows in the SDP (Additivity is signaled > if the repair flows are in the same group). There is a "language" > question and I would like to hear your opinions. > > Suppose that we have a source flow (S1) and two repair flows (R1, > R2). If the repair flows are not additive with each other, we MUST > have in the SDP: > > a=group:FEC-XR S1 R1 > a=group:FEC-XR S1 R2 > > However, if the repair flows are additive, MUST or SHOULD we write > the following? > > a=group:FEC-XR S1 R1 R2 > > Because writing > > a=group:FEC-XR S1 R1 > a=group:FEC-XR S1 R2 > > would not be strictly wrong, either. In other words, we must state > explicitly when the repair flows are not additive, but are we also > required to state explicitly when they are additive? My personal > view is that we "must" do so to avoid any confusion and fully > benefit from this new semantics. > > -acbegen > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > Regards Marshall Eubanks CEO / AmericaFree.TV From ron.even.tlv@gmail.com Fri Apr 24 07:31:18 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 832913A6B0A; Fri, 24 Apr 2009 07:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599] 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 h+kYam3XxBSo; Fri, 24 Apr 2009 07:31:17 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id F13CB3A69CA; Fri, 24 Apr 2009 07:31:16 -0700 (PDT) Received: by bwz7 with SMTP id 7so1127715bwz.37 for ; Fri, 24 Apr 2009 07:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=cEECRJu9dwFzaRz91b/RMZfe4NJGa6lqgYD07UXRP6A=; b=V2blGunYFkmmnz9HphxGEcr5/HQ/wEIqw9mPG14CVFgTY+5gufdhJX0Oj5S8TFKv6D Nrs42EB0dIJQ7YgH4N96/Q4aDz4sCBi96mmAHfTrcd4JTt40Df/ASMxUc9qvrMho5ENa RLkWrZKrzi6Yc2yqfIKeiJfarZVcHjBA0do4w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=dfjvtqGHCoH290vZI4fvWPiIBGb3hirDJYyFqR4MRN+v19pRVH/qREm13jccJjoAk5 6OwOymjG3KddnoFC5E9lWhXKlaMWpubqF9pyXIeRhV1lD4dqkWp1ytmQWy8gIFWStJyD ESKJVnTq+MQg5/R4UwwRqP8hCYpiHePTTXP7g= Received: by 10.204.68.73 with SMTP id u9mr2097323bki.192.1240583554987; Fri, 24 Apr 2009 07:32:34 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-121-32.red.bezeqint.net [79.179.121.32]) by mx.google.com with ESMTPS id 21sm316675fkx.36.2009.04.24.07.32.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 24 Apr 2009 07:32:34 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , References: <04CAD96D4C5A3D48B1919248A8FE0D54091BAA88@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54091BAA88@xmb-sjc-215.amer.cisco.com> Date: Fri, 24 Apr 2009 17:30:29 +0300 Message-ID: <49f1cd82.15185e0a.0fc3.ffffb9e7@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnAaI0k+CHA6Xe+Sfy0BV96KkoCXgAAB9bAAR8Fr7A= Content-Language: en-us X-Mailman-Approved-At: Fri, 24 Apr 2009 07:39:47 -0700 Cc: avt@ietf.org Subject: Re: [Fecframe] [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 14:31:18 -0000 Hi, I am sorry that I did not review the draft before since I am not subscribed to fecframe and AVT was not cc'ed on the WGLC. I have some editorial comments: 1. In section 1 you reference RFC2733, I think it was obsolete by RFC 5109 , do you need this downref? 2. In the registration section 5.1, the comments applies to all subtypes: 2.1 You have for security considerations and published specification "this document" it is better to write RFC xxxx and have a note to the RFC editor to replace it with the RFC number allocated, this will show in the IANA registry with the write pointer. 2.2 In the restriction on usage I assume that the document is using RTP framing and is not specified for other types, if this is the case it should say so. E.g. " This media type depends on RTP framing, and hence is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time" 2.3 You need to add the "additional information" that is in the template probably saying none 3. In section 5.2.1 it looks like you require symmetry between the send and received stream. Is this your requirement. 4. In section 5.2.1 can the answerer send a response with no FEC at all even if not offered. 5. In section 5.2.2 Can the receiver just ignore the fec stream, the text has a MUST use the configuration that is offered which can hint that it MUST use FEC. 6. In section 7 you discuss an exchange using grouping. Is it also allowed to use FEC withoutout grouping using the video or audio media types like section 14 in RFC 5109 Thanks Roni Even -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ali C. Begen (abegen) Sent: Sunday, April 19, 2009 12:04 AM To: fecframe@ietf.org Cc: avt@ietf.org Subject: [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03 This update addresses all the comments received in the WGLC period initated on April 1st. If there are further comments, please post them soon as we would like to move forward with this draft. http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interleaved-fec-sche me-03.txt BR, -acbegen -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Saturday, April 18, 2009 1:58 PM To: Ali C. Begen (abegen) Subject: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03 A new version of I-D, draft-ietf-fecframe-interleaved-fec-scheme-03.txt has been successfuly submitted by Ali Begen and posted to the IETF repository. Filename: draft-ietf-fecframe-interleaved-fec-scheme Revision: 03 Title: RTP Payload Format for 1-D Interleaved Parity FEC Creation_date: 2009-04-18 WG ID: fecframe Number_of_pages: 31 Abstract: This document defines a new RTP payload format for the Forward Error Correction (FEC) that is generated by the 1-D interleaved parity code from a source media encapsulated in RTP. The 1-D interleaved parity code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The 1-D interleaved parity code offers a good protection against bursty packet losses at a cost of decent complexity. The new payload format defined in this document is used (with some exceptions) as a part of the DVB Application-layer FEC specification. The IETF Secretariat. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From abegen@cisco.com Fri Apr 24 09:51:14 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F8DD3A6B8F; Fri, 24 Apr 2009 09:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.476 X-Spam-Level: X-Spam-Status: No, score=-6.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Zm3Xm3KB2HD2; Fri, 24 Apr 2009 09:51:08 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id DDD2E3A6986; Fri, 24 Apr 2009 09:50:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,242,1238976000"; d="scan'208";a="292374100" Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-6.cisco.com with ESMTP; 24 Apr 2009 16:52:07 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id n3OGq7ta020483; Fri, 24 Apr 2009 09:52:07 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3OGq71O002512; Fri, 24 Apr 2009 16:52:07 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 09:52:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Apr 2009 09:52:02 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C80EF@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49f1cd82.15185e0a.0fc3.ffffb9e7@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03 Thread-Index: AcnAaI0k+CHA6Xe+Sfy0BV96KkoCXgAAB9bAAR8Fr7AABY9UAA== References: <04CAD96D4C5A3D48B1919248A8FE0D54091BAA88@xmb-sjc-215.amer.cisco.com> <49f1cd82.15185e0a.0fc3.ffffb9e7@mx.google.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , X-OriginalArrivalTime: 24 Apr 2009 16:52:07.0736 (UTC) FILETIME=[00E22380:01C9C4FD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4864; t=1240591927; x=1241455927; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20FW=3A=20New=20Version=20Notific ation=20for=09draft-ietf-fecframe-interleaved-fec-scheme-03 |Sender:=20; bh=CBq8kALL90ZF9JNoMziOxZb4YtqCnP5CDzCW0fjqwjU=; b=FYNBhc4gRRZySpseLMHgXulGeOESYJ9oJp1Blp3w/hDo/Y7ZAhlS1a/paI KAPdFvLJe6a8c8KDr/v+dCqcNrxbIwl1LEf9F0Pjt2tES8BsAF2E4PzJKIOp cQaH6zmtXw; Authentication-Results: sj-dkim-8; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); Cc: avt@ietf.org Subject: Re: [Fecframe] [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 16:51:14 -0000 Thanks for the review. See inline.=20 > 1. In section 1 you reference RFC2733, I think it was=20 > obsolete by RFC 5109 , > do you need this downref? Yes, this has been already discussed within fecframe and with Magnus. We = give an informative reference as we are using an extension of the header = RFC 2733 had. =20 > 2. In the registration section 5.1, the comments applies to=20 > all subtypes: =20 > 2.1 You have for security considerations and published=20 > specification > "this document" it is better to write RFC xxxx and have a=20 > note to the > RFC editor to replace it with the RFC number allocated, this=20 > will show in > the IANA registry with the write pointer. Will do. =20 > 2.2 In the restriction on usage I assume that the document=20 > is using RTP > framing and is not specified for other types, if this is the case it > should say so. E.g. " This media type depends on RTP=20 > framing, and hence is > only defined for transfer via RTP [RFC3550]. =09 > Transport within other > framing protocols is not defined at this time" Will do. > 2.3 You need to add the "additional information" that is in=20 > the template > probably saying none I believe I already have "additional information: none" for each = subtype. > 3. In section 5.2.1 it looks like you require symmetry=20 > between the send and > received stream. Is this your requirement.=20 I am not sure what "symmetry" means here. Could you explain? =20 > 4. In section 5.2.1 can the answerer send a response with no=20 > FEC at all even > if not offered. If the answerer does not want FEC, yes, it can drop FEC from the offer. = Let me make that clear in the text. =20 > 5. In section 5.2.2 Can the receiver just ignore the fec=20 > stream, the text > has a MUST use the configuration that is offered which can=20 > hint that it MUST > use FEC. The receiver may decide to receive or not receive the FEC stream. If it = decides to receive, it MUST use the configuration that is provided for = the session. I guess the text is clear about this point. =20 > 6. In section 7 you discuss an exchange using grouping. Is it=20 > also allowed > to use FEC withoutout grouping using the video or audio media=20 > types like > section 14 in RFC 5109 Per FEC framework, we require the FEC to be in a separate flow, which = requires the source and FEC streams to be on different RTP sessions. = Thus, we require grouping (RFC 4756 or 4756bis) BR, -acbegen =20 >=20 > Thanks > Roni Even > =20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > Behalf Of Ali C. > Begen (abegen) > Sent: Sunday, April 19, 2009 12:04 AM > To: fecframe@ietf.org > Cc: avt@ietf.org > Subject: [AVT] FW: New Version Notification for > draft-ietf-fecframe-interleaved-fec-scheme-03 >=20 > This update addresses all the comments received in the WGLC=20 > period initated > on April 1st. If there are further comments, please post them=20 > soon as we > would like to move forward with this draft. > http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interl eaved-fec-sche > me-03.txt >=20 > BR, > -acbegen=20 >=20 > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 > Sent: Saturday, April 18, 2009 1:58 PM > To: Ali C. Begen (abegen) > Subject: New Version Notification for > draft-ietf-fecframe-interleaved-fec-scheme-03=20 >=20 >=20 > A new version of I-D,=20 > draft-ietf-fecframe-interleaved-fec-scheme-03.txt has > been successfuly submitted by Ali Begen and posted to the=20 > IETF repository. >=20 > Filename: draft-ietf-fecframe-interleaved-fec-scheme > Revision: 03 > Title: RTP Payload Format for 1-D Interleaved=20 > Parity FEC > Creation_date: 2009-04-18 > WG ID: fecframe > Number_of_pages: 31 >=20 > Abstract: > This document defines a new RTP payload format for the Forward Error > Correction (FEC) that is generated by the 1-D interleaved parity code > from a source media encapsulated in RTP. The 1-D interleaved parity > code is a systematic code, where a number of repair symbols are > generated from a set of source symbols and sent in a repair flow > separate from the source flow that carries the source symbols. The > 1-D interleaved parity code offers a good protection against bursty > packet losses at a cost of decent complexity. The new payload format > defined in this document is used (with some exceptions) as a part of > the DVB Application-layer FEC specification. > =20 >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt >=20 >=20 From abegen@cisco.com Fri Apr 24 10:54:07 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 230053A7058 for ; Fri, 24 Apr 2009 10:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 wZRYf0xWvgkK for ; Fri, 24 Apr 2009 10:54:06 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 61C203A6A0D for ; Fri, 24 Apr 2009 10:54:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,243,1238976000"; d="scan'208";a="292408506" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 24 Apr 2009 17:55:25 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3OHtPLW026321; Fri, 24 Apr 2009 10:55:25 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3OHtP9P019820; Fri, 24 Apr 2009 17:55:25 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 10:55:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Apr 2009 10:53:43 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RTP stream multiplexing in the fec framework Thread-Index: AcnFBZvmuqXE5ODwSgqb8A8kdmxCRw== From: "Ali C. Begen (abegen)" To: , X-OriginalArrivalTime: 24 Apr 2009 17:55:25.0242 (UTC) FILETIME=[D85F91A0:01C9C505] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2017; t=1240595725; x=1241459725; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RTP=20stream=20multiplexing=20in=20the=20fec=20 framework |Sender:=20; bh=O4H+f8rP6Y+Ro57ZsZlkf9Qt0Dlw8SFwFR+vMSScSaU=; b=r6NMl4C4Da4TNQpvZjmXZcA62fUuArz5ulTERMLSu0nhxjHI51tcp9ht1A RSR4KbYASLjzpd/rRAEQNRiX2FZ0btBqnOhPnPOZ4NmN4vG4CXI4AU136NlP YlNFo3L5cw; Authentication-Results: sj-dkim-3; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Fecframe] RTP stream multiplexing in the fec framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 17:54:07 -0000 Mark, All, I have a question about multiplexing the source and repair streams when = they are both RTP. Currently, we have the following text: (Start of section 4) The FEC Framework is described in terms of an additional layer between the transport layer (e.g. UDP or DCCP) and protocols running over this transport layer. Examples of such protocols are RTP, RTCP, etc. As such, the data path interface between the FEC Framework and both underlying and overlying layers can be thought of as being the same as the standard interface to the transport layer - i.e. the data exchanged consists of datagram payloads each associated with a single transport flow identified (in the case of UDP) by the standard 5-tuple { Source IP Address, Source Transport Port, Destination IP Address, Destination Transport Port, Transport Protocol }. In the case that RTP is used for the repair flows, the source and repair data may be multiplexed using RTP onto a single UDP flow and must consequently be demultiplexed at the receiver. There are various ways in which this multiplexing can be done, for example as described in [RFC4588]. RFC 4588 mentions two ways of multiplexing RTP streams. One is session = multiplexing, where source and repair RTP streams are in different RTP = sessions (different dest address/port). In this case, I don't have any = issues, this works beautifully with the framework. The other one is SSRC multiplexing where the source and repair RTP = streams have different SSRCs but are transmitted in the same RTP session = (which is a single UDP flow). Is the text above saying that the = framework also support this kind of multiplexing? In other words, is = using a single UDP flow to carry source + FEC data acceptable when they = have separate SSRCs? Not that FEC could not be used in this scenario, but as I recall the = framework required different UDP flows for source and repair flows... BR, -acbegen From watson@qualcomm.com Fri Apr 24 11:01:17 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C45C13A73B0 for ; Fri, 24 Apr 2009 11:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.74 X-Spam-Level: X-Spam-Status: No, score=-105.74 tagged_above=-999 required=5 tests=[AWL=0.858, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 7DMBq0hjSdB7 for ; Fri, 24 Apr 2009 11:01:07 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id E871528C1FC for ; Fri, 24 Apr 2009 11:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=watson@qualcomm.com; q=dns/txt; s=qcdkim; t=1240596120; x=1272132120; h=from:to:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Watson,=20Mark"=20|To:=20" Ali=20C.=20Begen=20(abegen)"=20,=0D=0A =20=20=20=20=20=20=20=20"fecframe@ietf.org"=0D=0A=09|Date:=20Fri,=2024=20Apr=202009=2011:01:53 =20-0700|Subject:=20Re:=20RTP=20stream=20multiplexing=20i n=20the=20fec=20framework|Thread-Topic:=20RTP=20stream=20 multiplexing=20in=20the=20fec=20framework|Thread-Index: =20AcnFBZvmuqXE5ODwSgqb8A8kdmxCRwAASOYc|Message-ID:=20|In-Reply-To:=20<04CAD96 D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco. com>|Accept-Language:=20en-US|Content-Language:=20en |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_C6174CA12CB35watsonqualcommcom_" |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5595"=3B=20a=3D"17433182"; bh=oe+anMdtVXbHEA3iYyqy1kBRn1DVm7X4bAL7GcMcG9g=; b=NuxB5OSKItsVrb2YAdbH+yugARY/TCp9Fgjy2MIglr5JbTp22l0kvvHB OBVz2UrzruX/qrzgOMR2+1A5ZBCJE5ni+rtQZ2QYQuFzkoDBGjIraaoig 5xWsUQwv3VT1qZCA3HtxWpEwOQfqrr6NaX/hn5kR9X259ISObmqMzKoZJ c=; X-IronPort-AV: E=McAfee;i="5300,2777,5595"; a="17433182" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Apr 2009 11:01:59 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3OI1xIu022262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 24 Apr 2009 11:01:59 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3OI1uHP017601 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 24 Apr 2009 11:01:58 -0700 Received: from nasclexhc01.na.qualcomm.com (10.227.147.14) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.1.358.0; Fri, 24 Apr 2009 11:01:55 -0700 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc01.na.qualcomm.com ([10.227.147.14]) with mapi; Fri, 24 Apr 2009 11:01:55 -0700 From: "Watson, Mark" To: "Ali C. Begen (abegen)" , "fecframe@ietf.org" Date: Fri, 24 Apr 2009 11:01:53 -0700 Thread-Topic: RTP stream multiplexing in the fec framework Thread-Index: AcnFBZvmuqXE5ODwSgqb8A8kdmxCRwAASOYc Message-ID: In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C6174CA12CB35watsonqualcommcom_" MIME-Version: 1.0 Subject: Re: [Fecframe] RTP stream multiplexing in the fec framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 18:01:17 -0000 --_000_C6174CA12CB35watsonqualcommcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ali, What do you think the Framework should do ? SSRC multiplexing of source and repair is possible and the intention was to= support this in the Framework, but if it is not required we could simplify= by supporting only port multiplexing. Port multiplexing is more straightfo= rwardly backwards-compatible (I'm not sure what an RTP receiver does if it = is expecting just one SSRC and it sees two). ...Mark On 4/24/09 10:53 AM, "Ali C. Begen (abegen)" wrote: Mark, All, I have a question about multiplexing the source and repair streams when the= y are both RTP. Currently, we have the following text: (Start of section 4) The FEC Framework is described in terms of an additional layer between the transport layer (e.g. UDP or DCCP) and protocols running over this transport layer. Examples of such protocols are RTP, RTCP, etc. As such, the data path interface between the FEC Framework and both underlying and overlying layers can be thought of as being the same as the standard interface to the transport layer - i.e. the data exchanged consists of datagram payloads each associated with a single transport flow identified (in the case of UDP) by the standard 5-tuple { Source IP Address, Source Transport Port, Destination IP Address, Destination Transport Port, Transport Protocol }. In the case that RTP is used for the repair flows, the source and repair data may be multiplexed using RTP onto a single UDP flow and must consequently be demultiplexed at the receiver. There are various ways in which this multiplexing can be done, for example as described in [RFC4588]. RFC 4588 mentions two ways of multiplexing RTP streams. One is session mult= iplexing, where source and repair RTP streams are in different RTP sessions= (different dest address/port). In this case, I don't have any issues, this= works beautifully with the framework. The other one is SSRC multiplexing where the source and repair RTP streams = have different SSRCs but are transmitted in the same RTP session (which is = a single UDP flow). Is the text above saying that the framework also suppor= t this kind of multiplexing? In other words, is using a single UDP flow to = carry source + FEC data acceptable when they have separate SSRCs? Not that FEC could not be used in this scenario, but as I recall the framew= ork required different UDP flows for source and repair flows... BR, -acbegen --_000_C6174CA12CB35watsonqualcommcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: RTP stream multiplexing in the fec framework Ali,

What do you think the Framework should do ?

SSRC multiplexing of source and repair is possible and the intention was to= support this in the Framework, but if it is not required we could simplify= by supporting only port multiplexing. Port multiplexing is more straightfo= rwardly backwards-compatible (I’m not sure what an RTP receiver does = if it is expecting just one SSRC and it sees two).

...Mark


On 4/24/09 10:53 AM, "Ali C. Begen (abegen)" <abegen@cisco.com> wrote:

Mark, All,

I have a question about multiplexing the source and repair streams when the= y are both RTP. Currently, we have the following text:

(Start of section 4)

   The FEC Framework is described in terms of an additional = layer
   between the transport layer (e.g.  UDP or DCCP) and = protocols running
   over this transport layer.  Examples of such protoco= ls are RTP, RTCP,
   etc.  As such, the data path interface between the F= EC Framework and
   both underlying and overlying layers can be thought of as= being the
   same as the standard interface to the transport layer - i= .e. the data
   exchanged consists of datagram payloads each associated w= ith a single
   transport flow identified (in the case of UDP) by the sta= ndard
   5-tuple { Source IP Address, Source Transport Port, Desti= nation IP
   Address, Destination Transport Port, Transport Protocol }= .  In the
   case that RTP is used for the repair flows, the source an= d repair
   data may be multiplexed using RTP onto a single UDP flow = and must
   consequently be demultiplexed at the receiver.  Ther= e are various
   ways in which this multiplexing can be done, for example = as described
   in [RFC4588].


RFC 4588 mentions two ways of multiplexing RTP streams. One is session mult= iplexing, where source and repair RTP streams are in different RTP sessions= (different dest address/port). In this case, I don't have any issues, this= works beautifully with the framework.

The other one is SSRC multiplexing where the source and repair RTP streams = have different SSRCs but are transmitted in the same RTP session (which is = a single UDP flow). Is the text above saying that the framework also suppor= t this kind of multiplexing? In other words, is using a single UDP flow to = carry source + FEC data acceptable when they have separate SSRCs?

Not that FEC could not be used in this scenario, but as I recall the framew= ork required different UDP flows for source and repair flows...

BR,
-acbegen

--_000_C6174CA12CB35watsonqualcommcom_-- From abegen@cisco.com Fri Apr 24 11:12:39 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40CCF3A68A6; Fri, 24 Apr 2009 11:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 nnq76bbcyVph; Fri, 24 Apr 2009 11:12:38 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 424F828C290; Fri, 24 Apr 2009 11:11:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,243,1238976000"; d="scan'208";a="176513428" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 24 Apr 2009 18:13:13 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3OIDDTg015973; Fri, 24 Apr 2009 11:13:13 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3OIDDTP008176; Fri, 24 Apr 2009 18:13:13 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 11:13:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Apr 2009 11:13:08 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RTP stream multiplexing in the fec framework Thread-Index: AcnFBZvmuqXE5ODwSgqb8A8kdmxCRwAASOYcAAAKG9A= References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> From: "Ali C. Begen (abegen)" To: "Watson, Mark" , X-OriginalArrivalTime: 24 Apr 2009 18:13:13.0050 (UTC) FILETIME=[54D623A0:01C9C508] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4277; t=1240596793; x=1241460793; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20RTP=20stream=20multiplexing=20in=20the= 20fec=20framework |Sender:=20; bh=n1qvAUkvNllGXqId83LII4hvaWZZm7DWmpoGMdZ5PsM=; b=J3ZYzHgjdhY8y1Kxx3RxMnztxqbPCi3bNJ0T+3p/r8q1feogw9GP2qEdHO anAHhABwluxaMYtcgWbs4Whu9ttIbWquLJU/zdlQn08iLbrrYMn6rOdoYEPP Mr8qFIHLwf; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: mmusic@ietf.org Subject: Re: [Fecframe] RTP stream multiplexing in the fec framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 18:12:39 -0000 Copying MMUSIC as this is relevant to: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-source-attribut= es-02.txt http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4756bis-01.txt=20 > -----Original Message----- > From: Watson, Mark [mailto:watson@qualcomm.com]=20 > Sent: Friday, April 24, 2009 11:02 AM > To: Ali C. Begen (abegen); fecframe@ietf.org > Subject: Re: RTP stream multiplexing in the fec framework >=20 > Ali, >=20 > What do you think the Framework should do ? IMO, we should not restrict FEC to work only for session multiplexing = (although I agree with you that doing so has many advantages). I see a few key reasons why people would use SSRC multiplexing, one = being to simplify the port operations on NAT traversal. One session = means one hole on NAT for the RTP transport (rtcp port can be the same = or different). So, some apps may use ssrc multiplexing. I am about to finalize the 4756bis draft and so far my assumption has = been that we would only do session multiplexing and use "a=3Dgroup" for = associations. This would not work for SSRC multiplexed streams, though. = For that, we can use the "a=3Dssrc-group" attribute from Jonathan's = draft. > SSRC multiplexing of source and repair is possible and the=20 > intention was to support this in the Framework, but if it is=20 > not required we could simplify by supporting only port=20 > multiplexing. Port multiplexing is more straightforwardly=20 > backwards-compatible (I'm not sure what an RTP receiver does=20 > if it is expecting just one SSRC and it sees two). If it has a payload that it does not understand, it will discard it. If = it understands and knows what the stream is for, it would just use it as = if the stream was received from a different port. Are there any comments/suggestions from MMUSIC? -acbegen =20 > ...Mark >=20 >=20 > On 4/24/09 10:53 AM, "Ali C. Begen (abegen)" wrote: >=20 >=20 >=20 > Mark, All, > =09 > I have a question about multiplexing the source and=20 > repair streams when they are both RTP. Currently, we have the=20 > following text: > =09 > (Start of section 4) > =09 > The FEC Framework is described in terms of an=20 > additional layer > between the transport layer (e.g. UDP or DCCP) and=20 > protocols running > over this transport layer. Examples of such=20 > protocols are RTP, RTCP, > etc. As such, the data path interface between the=20 > FEC Framework and > both underlying and overlying layers can be thought=20 > of as being the > same as the standard interface to the transport=20 > layer - i.e. the data > exchanged consists of datagram payloads each=20 > associated with a single > transport flow identified (in the case of UDP) by=20 > the standard > 5-tuple { Source IP Address, Source Transport Port,=20 > Destination IP > Address, Destination Transport Port, Transport=20 > Protocol }. In the > case that RTP is used for the repair flows, the=20 > source and repair > data may be multiplexed using RTP onto a single UDP=20 > flow and must > consequently be demultiplexed at the receiver. =20 > There are various > ways in which this multiplexing can be done, for=20 > example as described > in [RFC4588]. > =09 > =09 > RFC 4588 mentions two ways of multiplexing RTP streams.=20 > One is session multiplexing, where source and repair RTP=20 > streams are in different RTP sessions (different dest=20 > address/port). In this case, I don't have any issues, this=20 > works beautifully with the framework. > =09 > The other one is SSRC multiplexing where the source and=20 > repair RTP streams have different SSRCs but are transmitted=20 > in the same RTP session (which is a single UDP flow). Is the=20 > text above saying that the framework also support this kind=20 > of multiplexing? In other words, is using a single UDP flow=20 > to carry source + FEC data acceptable when they have separate SSRCs? > =09 > Not that FEC could not be used in this scenario, but as=20 > I recall the framework required different UDP flows for=20 > source and repair flows... > =09 > BR, > -acbegen > =09 > =09 >=20 >=20 From ron.even.tlv@gmail.com Fri Apr 24 12:05:24 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DE4F28C710; Fri, 24 Apr 2009 12:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599] 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 YX-WIFJ+nbXb; Fri, 24 Apr 2009 12:05:23 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id 3CE9928C763; Fri, 24 Apr 2009 12:03:44 -0700 (PDT) Received: by bwz7 with SMTP id 7so1254738bwz.37 for ; Fri, 24 Apr 2009 12:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=IVjVdbVLHOQanoBZLg4HlZLgRtnsuDo3+X7TOsxESvg=; b=OkvCc0FOLlgDxm/Ep1fjFAlmk3PIjU9lWJyupRNvAMSkT1B3TsArbaX5cg3glrfa8s ZZZSwCp1jqXu88s8LazzS83LT5NcfTsfJp0Orp5DVhZDDs7dqA+6aE+UGqdxJ7u4Ziog AXVx6Ok1c4Rn9yCQ/Grh4FaCinpAOAWN8Z2zg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=tADi3zxRF7LN/Ce1W0kSdUKmRxjhOcG/TbvO+lzNkWhH9IeCezM20ezIT7aq7Kkow8 hlH7GJB0HFT2LKlbkhTwCQQWNzNPP+gxfdnSAw7Gxx2EFVFv6Xn9VPDvZ0sKDdINc/wt NtYFl1yE8vuZ2DzZCwtLFVUqRvvzoZz/mbkVI= Received: by 10.204.118.138 with SMTP id v10mr2334042bkq.182.1240599902190; Fri, 24 Apr 2009 12:05:02 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-121-32.red.bezeqint.net [79.179.121.32]) by mx.google.com with ESMTPS id f31sm2842049fkf.12.2009.04.24.12.04.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 24 Apr 2009 12:05:01 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , References: <04CAD96D4C5A3D48B1919248A8FE0D54091BAA88@xmb-sjc-215.amer.cisco.com> <49f1cd82.15185e0a.0fc3.ffffb9e7@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80EF@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C80EF@xmb-sjc-215.amer.cisco.com> Date: Fri, 24 Apr 2009 22:03:13 +0300 Message-ID: <49f20d5d.1f205e0a.2719.fffffab1@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnAaI0k+CHA6Xe+Sfy0BV96KkoCXgAAB9bAAR8Fr7AABY9UAAAE5sqQ Content-Language: en-us Cc: avt@ietf.org Subject: Re: [Fecframe] [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 19:05:24 -0000 Ali, Inline Roni > 2.3 You need to add the "additional information" that is in > the template > probably saying none I believe I already have "additional information: none" for each subtype. RE- The order was different so I missed it > 3. In section 5.2.1 it looks like you require symmetry > between the send and > received stream. Is this your requirement. I am not sure what "symmetry" means here. Could you explain? RE - Symmetry means that the offerer and answerer MUST use the same mode since this exchange results in a two streams, one from each direction. > 5. In section 5.2.2 Can the receiver just ignore the fec > stream, the text > has a MUST use the configuration that is offered which can > hint that it MUST > use FEC. The receiver may decide to receive or not receive the FEC stream. If it decides to receive, it MUST use the configuration that is provided for the session. I guess the text is clear about this point. RE- I think it has to do with my assumption that you can multiplex the streams like RFC 5109 > 6. In section 7 you discuss an exchange using grouping. Is it > also allowed > to use FEC withoutout grouping using the video or audio media > types like > section 14 in RFC 5109 Per FEC framework, we require the FEC to be in a separate flow, which requires the source and FEC streams to be on different RTP sessions. Thus, we require grouping (RFC 4756 or 4756bis) RE- I will have to look at that draft, this is different from RFC 5109 and RFC 2733 BR, -acbegen > > Thanks > Roni Even > > > > > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Ali C. > Begen (abegen) > Sent: Sunday, April 19, 2009 12:04 AM > To: fecframe@ietf.org > Cc: avt@ietf.org > Subject: [AVT] FW: New Version Notification for > draft-ietf-fecframe-interleaved-fec-scheme-03 > > This update addresses all the comments received in the WGLC > period initated > on April 1st. If there are further comments, please post them > soon as we > would like to move forward with this draft. > http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interl eaved-fec-sche > me-03.txt > > BR, > -acbegen > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Saturday, April 18, 2009 1:58 PM > To: Ali C. Begen (abegen) > Subject: New Version Notification for > draft-ietf-fecframe-interleaved-fec-scheme-03 > > > A new version of I-D, > draft-ietf-fecframe-interleaved-fec-scheme-03.txt has > been successfuly submitted by Ali Begen and posted to the > IETF repository. > > Filename: draft-ietf-fecframe-interleaved-fec-scheme > Revision: 03 > Title: RTP Payload Format for 1-D Interleaved > Parity FEC > Creation_date: 2009-04-18 > WG ID: fecframe > Number_of_pages: 31 > > Abstract: > This document defines a new RTP payload format for the Forward Error > Correction (FEC) that is generated by the 1-D interleaved parity code > from a source media encapsulated in RTP. The 1-D interleaved parity > code is a systematic code, where a number of repair symbols are > generated from a set of source symbols and sent in a repair flow > separate from the source flow that carries the source symbols. The > 1-D interleaved parity code offers a good protection against bursty > packet losses at a cost of decent complexity. The new payload format > defined in this document is used (with some exceptions) as a part of > the DVB Application-layer FEC specification. > > > > > The IETF Secretariat. > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > From ron.even.tlv@gmail.com Fri Apr 24 12:32:23 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D8953A697F; Fri, 24 Apr 2009 12:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599] 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 FA9QJ4A5DG3m; Fri, 24 Apr 2009 12:32:22 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id 1E7563A688F; Fri, 24 Apr 2009 12:32:21 -0700 (PDT) Received: by bwz7 with SMTP id 7so1266370bwz.37 for ; Fri, 24 Apr 2009 12:33:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=cGju+VpuBmCHQU/5qsmxPBPNF2QsKu8pYJ7gWw+a8jk=; b=v6BtwB9st/u/Sp95qq1S0jxAJzgqgM4WXDifwoRGCsgI2E4rDNMVPo5WWbqRhGUMxv Y2rHBljpUtsCFtS4Z/Mn6zSXqeCkxJh5YTQJuSft4RS29PBgWG9t8tcpM6F6RndMMs/d /vOfqm6A5YO+dJhBiK9zVMfGAYe0n6GjGtFDk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=br7STxkN0VB0OkSqYWFFl82lFlo30hVfgfD6CRsjaim1oOS0fUtdzw8XmiuJNF1xrZ x4G8Ijy2Krc682i97GFNcKvwmrJwMbHJLnZOC3T6QK4lO1FLQAZ5oHZHDmH8lDWMqtH3 5kmqMvcbN7FAhlonGpqCSSc6ZhanvyHCHU53I= Received: by 10.103.160.9 with SMTP id m9mr1470399muo.96.1240601619925; Fri, 24 Apr 2009 12:33:39 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-121-32.red.bezeqint.net [79.179.121.32]) by mx.google.com with ESMTPS id n7sm4175456mue.42.2009.04.24.12.33.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 24 Apr 2009 12:33:39 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , References: <04CAD96D4C5A3D48B1919248A8FE0D54091BAA88@xmb-sjc-215.amer.cisco.com> <49f1cd82.15185e0a.0fc3.ffffb9e7@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80EF@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C80EF@xmb-sjc-215.amer.cisco.com> Date: Fri, 24 Apr 2009 22:31:39 +0300 Message-ID: <49f21413.07a5660a.3f7f.ffff99e5@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnAaI0k+CHA6Xe+Sfy0BV96KkoCXgAAB9bAAR8Fr7AABY9UAAAF8PqA Content-Language: en-us Cc: avt@ietf.org Subject: Re: [Fecframe] [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 19:32:23 -0000 Ali, I am a bit confused about your answer, I assume that FEC framework you refer to draft-ietf-fecframe-framework-03, at least I cold not see any reference in the draft to a document. In section 4 of the above draft it says " In the case that RTP is used for the repair flows, the source and repair data may be multiplexed using RTP onto a single UDP flow and must consequently be demultiplexed at the receiver." Roni > 6. In section 7 you discuss an exchange using grouping. Is it > also allowed > to use FEC withoutout grouping using the video or audio media > types like > section 14 in RFC 5109 Per FEC framework, we require the FEC to be in a separate flow, which requires the source and FEC streams to be on different RTP sessions. Thus, we require grouping (RFC 4756 or 4756bis) In the case that RTP is used for the repair flows, the source and repair data may be multiplexed using RTP onto a single UDP flow and must consequently be demultiplexed at the receiver. From abegen@cisco.com Fri Apr 24 12:37:40 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A718C3A6F95; Fri, 24 Apr 2009 12:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.434 X-Spam-Level: X-Spam-Status: No, score=-6.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 zHVNp+TW3bCO; Fri, 24 Apr 2009 12:37:39 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D012E3A68AB; Fri, 24 Apr 2009 12:37:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,243,1238976000"; d="scan'208";a="292462426" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 24 Apr 2009 19:38:36 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3OJcaYM014489; Fri, 24 Apr 2009 12:38:36 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3OJcaWL017061; Fri, 24 Apr 2009 19:38:36 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 12:38:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Apr 2009 12:38:34 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C8204@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49f20d5d.1f205e0a.2719.fffffab1@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03 Thread-Index: AcnAaI0k+CHA6Xe+Sfy0BV96KkoCXgAAB9bAAR8Fr7AABY9UAAAE5sqQAABiiFA= References: <04CAD96D4C5A3D48B1919248A8FE0D54091BAA88@xmb-sjc-215.amer.cisco.com> <49f1cd82.15185e0a.0fc3.ffffb9e7@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80EF@xmb-sjc-215.amer.cisco.com> <49f20d5d.1f205e0a.2719.fffffab1@mx.google.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , X-OriginalArrivalTime: 24 Apr 2009 19:38:36.0761 (UTC) FILETIME=[42CE6490:01C9C514] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=949; t=1240601916; x=1241465916; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20FW=3A=20New=20Version=20Notific ation=20for=09draft-ietf-fecframe-interleaved-fec-scheme-03 |Sender:=20; bh=pSdmVm6WLoeK5WekIXjVjkc3Q+D7Q+p+2m2pE8wPY7U=; b=n/jf5xPZUJYiwb0urc9IBebDDDkBWucTELQsg5TyXfzZvETjYeMoGupQdB AZT90eT+7aURvNg3aeXV0n/wfPTTo+CkQzvij3u2qO+T/YDAgFKWVNzoQb9i hdpkrR+gX7; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: avt@ietf.org Subject: Re: [Fecframe] [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 19:37:40 -0000 > > 6. In section 7 you discuss an exchange using grouping. Is it=20 > > also allowed > > to use FEC withoutout grouping using the video or audio media=20 > > types like > > section 14 in RFC 5109 >=20 > Per FEC framework, we require the FEC to be in a separate flow, which > requires the source and FEC streams to be on different RTP=20 > sessions. Thus, > we require grouping (RFC 4756 or 4756bis) >=20 > RE- I will have to look at that draft, this is different from=20 > RFC 5109 and > RFC 2733 Actually, we might be supporting SSRC multiplexing in the fec framework = (see my email sent today to fecframe/mmusic about this topic), since = there are some use cases for it. It does bring up other issues, though. = I would be glad to hear your comments. There are also some issues with RFC 5109 regarding SSRC multiplexing as = you mentioned in one of your earlier emails that may need to be = addressed. BR, -acbegen From abegen@cisco.com Fri Apr 24 12:45:25 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57D2A3A6B42; Fri, 24 Apr 2009 12:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.438 X-Spam-Level: X-Spam-Status: No, score=-6.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 MXiTqmPVDeiI; Fri, 24 Apr 2009 12:45:24 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 518FF3A68C1; Fri, 24 Apr 2009 12:45:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,243,1238976000"; d="scan'208";a="73246472" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 24 Apr 2009 19:46:43 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3OJkheN031881; Fri, 24 Apr 2009 12:46:43 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3OJkhjj021348; Fri, 24 Apr 2009 19:46:43 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 12:46:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Apr 2009 12:46:40 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C820A@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49f21413.07a5660a.3f7f.ffff99e5@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03 Thread-Index: AcnAaI0k+CHA6Xe+Sfy0BV96KkoCXgAAB9bAAR8Fr7AABY9UAAAF8PqAAABmxsA= References: <04CAD96D4C5A3D48B1919248A8FE0D54091BAA88@xmb-sjc-215.amer.cisco.com> <49f1cd82.15185e0a.0fc3.ffffb9e7@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80EF@xmb-sjc-215.amer.cisco.com> <49f21413.07a5660a.3f7f.ffff99e5@mx.google.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , X-OriginalArrivalTime: 24 Apr 2009 19:46:43.0227 (UTC) FILETIME=[64C336B0:01C9C515] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1695; t=1240602403; x=1241466403; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20FW=3A=20New=20Version=20Notific ation=20for=09draft-ietf-fecframe-interleaved-fec-scheme-03 |Sender:=20; bh=Hb0If4wtetRF/51WMkhtrk6uBaGQkQKyIlVi7ATZHDI=; b=LP+Y9UHzLzcrPU4EfNdu1wY09Zvknjp5uXaRbfjxmmLGCUrE1pbQWIdk4P JaIwq3Mft1R8otSE4saCoPG0xJumCk9WGmLe1o/KBeI2epf2dp3a5Z2iRIsw zGbV6rgjVhCom9W/60rPSHUVWxJFMoDKNhayP9v8V5RL5H7yM14n0=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: avt@ietf.org Subject: Re: [Fecframe] [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 19:45:25 -0000 Yes, that is the fecframework draft, and I raised exactly the same point = this morning in the fecframe/mmusic list when I noticed that text in the = draft. Please use that thread for that discussion.=20 -acbegen > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > Sent: Friday, April 24, 2009 12:32 PM > To: Ali C. Begen (abegen); fecframe@ietf.org > Cc: avt@ietf.org > Subject: RE: [AVT] FW: New Version Notification for=20 > draft-ietf-fecframe-interleaved-fec-scheme-03 >=20 > Ali, > I am a bit confused about your answer, I assume that FEC=20 > framework you refer > to draft-ietf-fecframe-framework-03, at least I cold not see=20 > any reference > in the draft to a document.=20 > In section 4 of the above draft it says=20 >=20 > " > In the case that RTP is used for the repair flows, the source=20 > and repair > data may be multiplexed using RTP onto a single UDP flow and must > consequently be demultiplexed at the receiver." >=20 >=20 > Roni >=20 >=20 > > 6. In section 7 you discuss an exchange using grouping. Is it=20 > > also allowed > > to use FEC withoutout grouping using the video or audio media=20 > > types like > > section 14 in RFC 5109 >=20 > Per FEC framework, we require the FEC to be in a separate flow, which > requires the source and FEC streams to be on different RTP=20 > sessions. Thus, > we require grouping (RFC 4756 or 4756bis) >=20 >=20 >=20 >=20 >=20 > In the case that RTP is used for the repair flows, the source=20 > and repair > data may be multiplexed using RTP onto a single UDP flow and must > consequently be demultiplexed at the receiver. >=20 >=20 From tme@americafree.tv Fri Apr 24 19:22:13 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACC813A6AEB for ; Fri, 24 Apr 2009 19:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599] 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 IzfyNIuU-LSf for ; Fri, 24 Apr 2009 19:22:12 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 759483A6876 for ; Fri, 24 Apr 2009 19:21:31 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 0957E3A976FD; Fri, 24 Apr 2009 22:22:50 -0400 (EDT) Message-Id: <3BFDBEB9-527D-4751-A10F-D2A591D6CF86@americafree.tv> From: Marshall Eubanks To: "Watson, Mark" In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 24 Apr 2009 22:22:49 -0400 References: X-Mailer: Apple Mail (2.930.3) Cc: "fecframe@ietf.org" Subject: Re: [Fecframe] RTP stream multiplexing in the fec framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 02:22:13 -0000 On Apr 24, 2009, at 2:01 PM, Watson, Mark wrote: > Ali, > > What do you think the Framework should do ? > I think it should support both modes, but that repair flows SHOULD use =20= separate port, address, or other multiplexing. Read, for example, http://www.cs.columbia.edu/~hgs/rtp/faq.html#ssrc-mux An RTP mixer normally combines all the SSRCs it receives on an RTP =20 session according to the composition method that is appropriate for =20 that session (e.g., mixing for audio). If multiple media are sent on =20 one session, then the SSRCs must be segregated per medium based on =20 external information. -- So, it seems to me that there could be cases (for example, audio =20 mixing or video conferencing) where having multiple SSRCs, some for (say) different audio flows and some for repair flows, would =20= not be backwards compatible. > SSRC multiplexing of source and repair is possible and the intention =20= > was to support this in the Framework, but if it is not required we =20 > could simplify by supporting only port multiplexing. Port =20 > multiplexing is more straightforwardly backwards-compatible (I=92m not = =20 > sure what an RTP receiver does if it is expecting just one SSRC and =20= > it sees two). > Unless it is told what to do by RTCP, it should ignore the second. I =20 think that the trouble may come if the data type allows for the =20 possibility of having more than one SSRC data flow. Note, however, if you are doing proper RTP with RTCP, then this will =20 add some state (RFC3550) : 6.3.3 Receiving an RTP or Non-BYE RTCP Packet When an RTP or RTCP packet is received from a participant whose SSRC =20 is not in the member table, the SSRC is added to the table, and the =20 value for members is updated once the participant has been validated =20 as described in Section 6.2.1. The same processing occurs for each =20 CSRC in a validated RTP packet. When an RTP packet is received from a =20= participant whose SSRC is not in the sender table, the SSRC is added =20 to the table, and the value for senders is updated. ---- It would clearly be a bad idea to have unlimited numbers of repair =20 SSRCs (say, hundreds or thousands), as the RTCP rate for the original =20= flow would get squelched due to the bandwidth restrictions applied to RTCP. Regards Marshall > ...Mark > > > On 4/24/09 10:53 AM, "Ali C. Begen (abegen)" wrote: > > Mark, All, > > I have a question about multiplexing the source and repair streams =20 > when they are both RTP. Currently, we have the following text: > > (Start of section 4) > > The FEC Framework is described in terms of an additional layer > between the transport layer (e.g. UDP or DCCP) and protocols =20 > running > over this transport layer. Examples of such protocols are RTP, =20 > RTCP, > etc. As such, the data path interface between the FEC Framework =20= > and > both underlying and overlying layers can be thought of as being the > same as the standard interface to the transport layer - i.e. the =20= > data > exchanged consists of datagram payloads each associated with a =20 > single > transport flow identified (in the case of UDP) by the standard > 5-tuple { Source IP Address, Source Transport Port, Destination IP > Address, Destination Transport Port, Transport Protocol }. In the > case that RTP is used for the repair flows, the source and repair > data may be multiplexed using RTP onto a single UDP flow and must > consequently be demultiplexed at the receiver. There are various > ways in which this multiplexing can be done, for example as =20 > described > in [RFC4588]. > > > RFC 4588 mentions two ways of multiplexing RTP streams. One is =20 > session multiplexing, where source and repair RTP streams are in =20 > different RTP sessions (different dest address/port). In this case, =20= > I don't have any issues, this works beautifully with the framework. > > The other one is SSRC multiplexing where the source and repair RTP =20 > streams have different SSRCs but are transmitted in the same RTP =20 > session (which is a single UDP flow). Is the text above saying that =20= > the framework also support this kind of multiplexing? In other =20 > words, is using a single UDP flow to carry source + FEC data =20 > acceptable when they have separate SSRCs? > > Not that FEC could not be used in this scenario, but as I recall the =20= > framework required different UDP flows for source and repair flows... > > BR, > -acbegen > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe Regards Marshall Eubanks CEO / AmericaFree.TV From abegen@cisco.com Fri Apr 24 19:41:29 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B18D33A63EC for ; Fri, 24 Apr 2009 19:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 3xy7h-8wDCzr for ; Fri, 24 Apr 2009 19:41:28 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E58003A68C2 for ; Fri, 24 Apr 2009 19:40:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,244,1238976000"; d="scan'208";a="176695943" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 25 Apr 2009 02:42:10 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3P2gAPx009922; Fri, 24 Apr 2009 19:42:10 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3P2gA8J010784; Sat, 25 Apr 2009 02:42:10 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 19:42:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Apr 2009 19:42:06 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C8383@xmb-sjc-215.amer.cisco.com> In-Reply-To: <3BFDBEB9-527D-4751-A10F-D2A591D6CF86@americafree.tv> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] RTP stream multiplexing in the fec framework Thread-Index: AcnFTVT0Cs/EO/l6Su6wjmE70SSMMAAAdY4g References: <3BFDBEB9-527D-4751-A10F-D2A591D6CF86@americafree.tv> From: "Ali C. Begen (abegen)" To: "Marshall Eubanks" , "Watson, Mark" X-OriginalArrivalTime: 25 Apr 2009 02:42:10.0131 (UTC) FILETIME=[6E5AEA30:01C9C54F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5683; t=1240627330; x=1241491330; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[Fecframe]=20RTP=20stream=20multiplexin g=20in=20the=20fec=20framework |Sender:=20; bh=acKBjXkmn5meMhRn9RF56EiIBzREQHGZJtjSNtK6YO8=; b=l+5Af/Jpw+XmP2flMch+NpmCnXf8zERN2gB95BnuVdKMk+W3r1DpVyvbTV StAT98wPO0ZL4wjWGEGI2BbpGvwi3YBECd8t2JGcYUd+vtMcwU13ENTPu2a/ NZOgC8K0gf; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: fecframe@ietf.org Subject: Re: [Fecframe] RTP stream multiplexing in the fec framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 02:41:29 -0000 If the repair RTP stream is sent to a different address and/or port, = then it is already in a different RTP session, and we naturally support = session multiplexing between source and repair flows. -acbegen > -----Original Message----- > From: Marshall Eubanks [mailto:tme@americafree.tv]=20 > Sent: Friday, April 24, 2009 7:23 PM > To: Watson, Mark > Cc: Ali C. Begen (abegen); fecframe@ietf.org > Subject: Re: [Fecframe] RTP stream multiplexing in the fec framework >=20 >=20 > On Apr 24, 2009, at 2:01 PM, Watson, Mark wrote: >=20 > > Ali, > > > > What do you think the Framework should do ? > > >=20 > I think it should support both modes, but that repair flows=20 > SHOULD use =20 > separate port, address, or other multiplexing. Read, for example, >=20 > http://www.cs.columbia.edu/~hgs/rtp/faq.html#ssrc-mux >=20 > An RTP mixer normally combines all the SSRCs it receives on an RTP =20 > session according to the composition method that is appropriate for =20 > that session (e.g., mixing for audio). If multiple media are sent on =20 > one session, then the SSRCs must be segregated per medium based on =20 > external information. > -- >=20 > So, it seems to me that there could be cases (for example, audio =20 > mixing or video conferencing) where having multiple SSRCs, > some for (say) different audio flows and some for repair=20 > flows, would =20 > not be backwards compatible. >=20 > > SSRC multiplexing of source and repair is possible and the=20 > intention =20 > > was to support this in the Framework, but if it is not required we =20 > > could simplify by supporting only port multiplexing. Port =20 > > multiplexing is more straightforwardly backwards-compatible=20 > (I=92m not =20 > > sure what an RTP receiver does if it is expecting just one=20 > SSRC and =20 > > it sees two). > > >=20 > Unless it is told what to do by RTCP, it should ignore the second. I =20 > think that the trouble may come if the data type allows for the =20 > possibility of having more than one SSRC data flow. >=20 > Note, however, if you are doing proper RTP with RTCP, then this will =20 > add some state (RFC3550) : >=20 > 6.3.3 Receiving an RTP or Non-BYE RTCP Packet > When an RTP or RTCP packet is received from a participant whose SSRC =20 > is not in the member table, the SSRC is added to the table, and the =20 > value for members is updated once the participant has been validated =20 > as described in Section 6.2.1. The same processing occurs for each =20 > CSRC in a validated RTP packet. When an RTP packet is=20 > received from a =20 > participant whose SSRC is not in the sender table, the SSRC is added =20 > to the table, and the value for senders is updated. > ---- > It would clearly be a bad idea to have unlimited numbers of repair =20 > SSRCs (say, hundreds or thousands), as the RTCP rate for the=20 > original =20 > flow would get squelched due to the > bandwidth restrictions applied to RTCP. > Regards > Marshall >=20 >=20 >=20 > > ...Mark > > > > > > On 4/24/09 10:53 AM, "Ali C. Begen (abegen)"=20 > wrote: > > > > Mark, All, > > > > I have a question about multiplexing the source and repair streams =20 > > when they are both RTP. Currently, we have the following text: > > > > (Start of section 4) > > > > The FEC Framework is described in terms of an additional layer > > between the transport layer (e.g. UDP or DCCP) and protocols =20 > > running > > over this transport layer. Examples of such protocols are RTP, =20 > > RTCP, > > etc. As such, the data path interface between the FEC=20 > Framework =20 > > and > > both underlying and overlying layers can be thought of=20 > as being the > > same as the standard interface to the transport layer -=20 > i.e. the =20 > > data > > exchanged consists of datagram payloads each associated with a =20 > > single > > transport flow identified (in the case of UDP) by the standard > > 5-tuple { Source IP Address, Source Transport Port,=20 > Destination IP > > Address, Destination Transport Port, Transport Protocol=20 > }. In the > > case that RTP is used for the repair flows, the source and repair > > data may be multiplexed using RTP onto a single UDP flow and must > > consequently be demultiplexed at the receiver. There are various > > ways in which this multiplexing can be done, for example as =20 > > described > > in [RFC4588]. > > > > > > RFC 4588 mentions two ways of multiplexing RTP streams. One is =20 > > session multiplexing, where source and repair RTP streams are in =20 > > different RTP sessions (different dest address/port). In=20 > this case, =20 > > I don't have any issues, this works beautifully with the framework. > > > > The other one is SSRC multiplexing where the source and repair RTP =20 > > streams have different SSRCs but are transmitted in the same RTP =20 > > session (which is a single UDP flow). Is the text above=20 > saying that =20 > > the framework also support this kind of multiplexing? In other =20 > > words, is using a single UDP flow to carry source + FEC data =20 > > acceptable when they have separate SSRCs? > > > > Not that FEC could not be used in this scenario, but as I=20 > recall the =20 > > framework required different UDP flows for source and=20 > repair flows... > > > > BR, > > -acbegen > > > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe >=20 > Regards > Marshall Eubanks > CEO / AmericaFree.TV >=20 >=20 From tme@americafree.tv Sat Apr 25 03:38:52 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ECB23A6B5C for ; Sat, 25 Apr 2009 03:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] 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 MNzXkEcwpN1i for ; Sat, 25 Apr 2009 03:38:50 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id A03A03A682B for ; Sat, 25 Apr 2009 03:38:50 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 9F39B3AA2685; Sat, 25 Apr 2009 06:40:09 -0400 (EDT) Message-Id: <3DC394DA-3513-4F6C-BDB1-C30AE66A94AF@americafree.tv> From: Marshall Eubanks To: "Ali C. Begen (abegen)" In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C8383@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 25 Apr 2009 06:40:06 -0400 References: <3BFDBEB9-527D-4751-A10F-D2A591D6CF86@americafree.tv> <04CAD96D4C5A3D48B1919248A8FE0D54092C8383@xmb-sjc-215.amer.cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: fecframe@ietf.org Subject: Re: [Fecframe] RTP stream multiplexing in the fec framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 10:38:52 -0000 On Apr 24, 2009, at 10:42 PM, Ali C. Begen (abegen) wrote: > If the repair RTP stream is sent to a different address and/or port, =20= > then it is already in a different RTP session, and we naturally =20 > support session multiplexing between source and repair flows. Yes, that is basically my point. That type of multiplexing is fine, =20 but if all you have is SSRC multiplexing of repair flows, in some =20 cases you could get into trouble. I see no reason not to allow that, but we should recommend against it. Regards Marshall > > > -acbegen > >> -----Original Message----- >> From: Marshall Eubanks [mailto:tme@americafree.tv] >> Sent: Friday, April 24, 2009 7:23 PM >> To: Watson, Mark >> Cc: Ali C. Begen (abegen); fecframe@ietf.org >> Subject: Re: [Fecframe] RTP stream multiplexing in the fec framework >> >> >> On Apr 24, 2009, at 2:01 PM, Watson, Mark wrote: >> >>> Ali, >>> >>> What do you think the Framework should do ? >>> >> >> I think it should support both modes, but that repair flows >> SHOULD use >> separate port, address, or other multiplexing. Read, for example, >> >> http://www.cs.columbia.edu/~hgs/rtp/faq.html#ssrc-mux >> >> An RTP mixer normally combines all the SSRCs it receives on an RTP >> session according to the composition method that is appropriate for >> that session (e.g., mixing for audio). If multiple media are sent on >> one session, then the SSRCs must be segregated per medium based on >> external information. >> -- >> >> So, it seems to me that there could be cases (for example, audio >> mixing or video conferencing) where having multiple SSRCs, >> some for (say) different audio flows and some for repair >> flows, would >> not be backwards compatible. >> >>> SSRC multiplexing of source and repair is possible and the >> intention >>> was to support this in the Framework, but if it is not required we >>> could simplify by supporting only port multiplexing. Port >>> multiplexing is more straightforwardly backwards-compatible >> (I=92m not >>> sure what an RTP receiver does if it is expecting just one >> SSRC and >>> it sees two). >>> >> >> Unless it is told what to do by RTCP, it should ignore the second. I >> think that the trouble may come if the data type allows for the >> possibility of having more than one SSRC data flow. >> >> Note, however, if you are doing proper RTP with RTCP, then this will >> add some state (RFC3550) : >> >> 6.3.3 Receiving an RTP or Non-BYE RTCP Packet >> When an RTP or RTCP packet is received from a participant whose SSRC >> is not in the member table, the SSRC is added to the table, and the >> value for members is updated once the participant has been validated >> as described in Section 6.2.1. The same processing occurs for each >> CSRC in a validated RTP packet. When an RTP packet is >> received from a >> participant whose SSRC is not in the sender table, the SSRC is added >> to the table, and the value for senders is updated. >> ---- >> It would clearly be a bad idea to have unlimited numbers of repair >> SSRCs (say, hundreds or thousands), as the RTCP rate for the >> original >> flow would get squelched due to the >> bandwidth restrictions applied to RTCP. >> Regards >> Marshall >> >> >> >>> ...Mark >>> >>> >>> On 4/24/09 10:53 AM, "Ali C. Begen (abegen)" >> wrote: >>> >>> Mark, All, >>> >>> I have a question about multiplexing the source and repair streams >>> when they are both RTP. Currently, we have the following text: >>> >>> (Start of section 4) >>> >>> The FEC Framework is described in terms of an additional layer >>> between the transport layer (e.g. UDP or DCCP) and protocols >>> running >>> over this transport layer. Examples of such protocols are RTP, >>> RTCP, >>> etc. As such, the data path interface between the FEC >> Framework >>> and >>> both underlying and overlying layers can be thought of >> as being the >>> same as the standard interface to the transport layer - >> i.e. the >>> data >>> exchanged consists of datagram payloads each associated with a >>> single >>> transport flow identified (in the case of UDP) by the standard >>> 5-tuple { Source IP Address, Source Transport Port, >> Destination IP >>> Address, Destination Transport Port, Transport Protocol >> }. In the >>> case that RTP is used for the repair flows, the source and repair >>> data may be multiplexed using RTP onto a single UDP flow and must >>> consequently be demultiplexed at the receiver. There are various >>> ways in which this multiplexing can be done, for example as >>> described >>> in [RFC4588]. >>> >>> >>> RFC 4588 mentions two ways of multiplexing RTP streams. One is >>> session multiplexing, where source and repair RTP streams are in >>> different RTP sessions (different dest address/port). In >> this case, >>> I don't have any issues, this works beautifully with the framework. >>> >>> The other one is SSRC multiplexing where the source and repair RTP >>> streams have different SSRCs but are transmitted in the same RTP >>> session (which is a single UDP flow). Is the text above >> saying that >>> the framework also support this kind of multiplexing? In other >>> words, is using a single UDP flow to carry source + FEC data >>> acceptable when they have separate SSRCs? >>> >>> Not that FEC could not be used in this scenario, but as I >> recall the >>> framework required different UDP flows for source and >> repair flows... >>> >>> BR, >>> -acbegen >>> >>> _______________________________________________ >>> Fecframe mailing list >>> Fecframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/fecframe >> >> Regards >> Marshall Eubanks >> CEO / AmericaFree.TV >> >> > Regards Marshall Eubanks CEO / AmericaFree.TV From csp@csperkins.org Mon Apr 27 11:54:54 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3158928C1A6; Mon, 27 Apr 2009 11:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 HmAtvghcH9yt; Mon, 27 Apr 2009 11:54:53 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by core3.amsl.com (Postfix) with ESMTP id C2FE228C1A1; Mon, 27 Apr 2009 11:54:52 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=mangole.lan) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1LyVzw-0000xf-bO; Mon, 27 Apr 2009 18:56:13 +0000 Message-Id: <8F9DD728-5AE9-4394-9BDD-4EDBFB92E4A5@csperkins.org> From: Colin Perkins To: Ali C. Begen (abegen) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 27 Apr 2009 18:53:58 +0100 References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: mmusic@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] RTP stream multiplexing in the fec framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 18:54:54 -0000 On 24 Apr 2009, at 19:13, Ali C. Begen (abegen) wrote: > Copying MMUSIC as this is relevant to: > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-source-attributes-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-mmusic- > rfc4756bis-01.txt > >> -----Original Message----- >> From: Watson, Mark [mailto:watson@qualcomm.com] >> Sent: Friday, April 24, 2009 11:02 AM >> To: Ali C. Begen (abegen); fecframe@ietf.org >> Subject: Re: RTP stream multiplexing in the fec framework >> >> Ali, >> >> What do you think the Framework should do ? > > IMO, we should not restrict FEC to work only for session > multiplexing (although I agree with you that doing so has many > advantages). > > I see a few key reasons why people would use SSRC multiplexing, one > being to simplify the port operations on NAT traversal. One session > means one hole on NAT for the RTP transport (rtcp port can be the > same or different). So, some apps may use ssrc multiplexing. The trend is clearly towards allowing multiplexing by RTP SSRC, to ease NAT traversal by reducing the number of UDP ports. By that argument, sending FEC data on the same port as the media it's protecting doesn't seem problematic. (I wouldn't want to see different media types on one port, but this is close enough related that I don't see a big issue). > I am about to finalize the 4756bis draft and so far my assumption > has been that we would only do session multiplexing and use > "a=group" for associations. This would not work for SSRC multiplexed > streams, though. For that, we can use the "a=ssrc-group" attribute > from Jonathan's draft. > >> SSRC multiplexing of source and repair is possible and the >> intention was to support this in the Framework, but if it is >> not required we could simplify by supporting only port >> multiplexing. Port multiplexing is more straightforwardly >> backwards-compatible (I'm not sure what an RTP receiver does >> if it is expecting just one SSRC and it sees two). > > If it has a payload that it does not understand, it will discard it. > If it understands and knows what the stream is for, it would just > use it as if the stream was received from a different port. > > Are there any comments/suggestions from MMUSIC? > > -acbegen > >> ...Mark >> >> >> On 4/24/09 10:53 AM, "Ali C. Begen (abegen)" >> wrote: >> >> >> >> Mark, All, >> >> I have a question about multiplexing the source and >> repair streams when they are both RTP. Currently, we have the >> following text: >> >> (Start of section 4) >> >> The FEC Framework is described in terms of an >> additional layer >> between the transport layer (e.g. UDP or DCCP) and >> protocols running >> over this transport layer. Examples of such >> protocols are RTP, RTCP, >> etc. As such, the data path interface between the >> FEC Framework and >> both underlying and overlying layers can be thought >> of as being the >> same as the standard interface to the transport >> layer - i.e. the data >> exchanged consists of datagram payloads each >> associated with a single >> transport flow identified (in the case of UDP) by >> the standard >> 5-tuple { Source IP Address, Source Transport Port, >> Destination IP >> Address, Destination Transport Port, Transport >> Protocol }. In the >> case that RTP is used for the repair flows, the >> source and repair >> data may be multiplexed using RTP onto a single UDP >> flow and must >> consequently be demultiplexed at the receiver. >> There are various >> ways in which this multiplexing can be done, for >> example as described >> in [RFC4588]. >> >> >> RFC 4588 mentions two ways of multiplexing RTP streams. >> One is session multiplexing, where source and repair RTP >> streams are in different RTP sessions (different dest >> address/port). In this case, I don't have any issues, this >> works beautifully with the framework. >> >> The other one is SSRC multiplexing where the source and >> repair RTP streams have different SSRCs but are transmitted >> in the same RTP session (which is a single UDP flow). Is the >> text above saying that the framework also support this kind >> of multiplexing? In other words, is using a single UDP flow >> to carry source + FEC data acceptable when they have separate SSRCs? >> >> Not that FEC could not be used in this scenario, but as >> I recall the framework required different UDP flows for >> source and repair flows... >> >> BR, >> -acbegen >> >> >> >> > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe -- Colin Perkins http://csperkins.org/ From abegen@cisco.com Mon Apr 27 12:03:12 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51EA93A6FD4; Mon, 27 Apr 2009 12:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.329 X-Spam-Level: X-Spam-Status: No, score=-6.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 XPWim09W7AOG; Mon, 27 Apr 2009 12:03:10 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id CA88D3A6FD6; Mon, 27 Apr 2009 12:00:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,256,1238976000"; d="scan'208";a="293820178" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 27 Apr 2009 19:01:19 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3RJ1JSG002934; Mon, 27 Apr 2009 12:01:19 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3RJ1Jur001156; Mon, 27 Apr 2009 19:01:19 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 12:01:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Apr 2009 12:00:49 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C86BE@xmb-sjc-215.amer.cisco.com> In-Reply-To: <8F9DD728-5AE9-4394-9BDD-4EDBFB92E4A5@csperkins.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] RTP stream multiplexing in the fec framework Thread-Index: AcnHadz22guj5TBhSs6bHzEE811o3wAAIUqw References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> <8F9DD728-5AE9-4394-9BDD-4EDBFB92E4A5@csperkins.org> From: "Ali C. Begen (abegen)" To: "Colin Perkins" X-OriginalArrivalTime: 27 Apr 2009 19:01:19.0349 (UTC) FILETIME=[8C71AA50:01C9C76A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5658; t=1240858879; x=1241722879; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[Fecframe]=20RTP=20stream=20multiplexin g=20in=20the=20fec=20framework |Sender:=20; bh=4vHm0tNhP1kp7Uqu9/Ag5YzalRvLM6yQ7qDhtkYzRvM=; b=SAukOms7ONEpOOxEXu1Gwm2mfQ70r9f8KdA18X+1yBkrUXbm1BiQKpPM/y RZhI6rkmJZaqv8YuHX10ucxol1UWftwI8jZRMUNwnYz2CLvZaiDY0xnwXGMO b4Vub47piW; Authentication-Results: sj-dkim-3; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: mmusic@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] RTP stream multiplexing in the fec framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 19:03:12 -0000 Is that a "yes" for ssrc-level grouping for FEC? -acbegen=20 > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org]=20 > Sent: Monday, April 27, 2009 10:54 AM > To: Ali C. Begen (abegen) > Cc: Watson, Mark; fecframe@ietf.org; mmusic@ietf.org > Subject: Re: [Fecframe] RTP stream multiplexing in the fec framework >=20 > On 24 Apr 2009, at 19:13, Ali C. Begen (abegen) wrote: > > Copying MMUSIC as this is relevant to: > > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-sour ce-attributes-02.txt > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-=20 > > rfc4756bis-01.txt > > > >> -----Original Message----- > >> From: Watson, Mark [mailto:watson@qualcomm.com] > >> Sent: Friday, April 24, 2009 11:02 AM > >> To: Ali C. Begen (abegen); fecframe@ietf.org > >> Subject: Re: RTP stream multiplexing in the fec framework > >> > >> Ali, > >> > >> What do you think the Framework should do ? > > > > IMO, we should not restrict FEC to work only for session =20 > > multiplexing (although I agree with you that doing so has many =20 > > advantages). > > > > I see a few key reasons why people would use SSRC=20 > multiplexing, one =20 > > being to simplify the port operations on NAT traversal. One=20 > session =20 > > means one hole on NAT for the RTP transport (rtcp port can be the =20 > > same or different). So, some apps may use ssrc multiplexing. >=20 > The trend is clearly towards allowing multiplexing by RTP SSRC, to =20 > ease NAT traversal by reducing the number of UDP ports. By that =20 > argument, sending FEC data on the same port as the media it's =20 > protecting doesn't seem problematic. (I wouldn't want to see=20 > different =20 > media types on one port, but this is close enough related=20 > that I don't =20 > see a big issue). >=20 > > I am about to finalize the 4756bis draft and so far my assumption =20 > > has been that we would only do session multiplexing and use =20 > > "a=3Dgroup" for associations. This would not work for SSRC=20 > multiplexed =20 > > streams, though. For that, we can use the "a=3Dssrc-group" attribute = =20 > > from Jonathan's draft. > > > >> SSRC multiplexing of source and repair is possible and the > >> intention was to support this in the Framework, but if it is > >> not required we could simplify by supporting only port > >> multiplexing. Port multiplexing is more straightforwardly > >> backwards-compatible (I'm not sure what an RTP receiver does > >> if it is expecting just one SSRC and it sees two). > > > > If it has a payload that it does not understand, it will=20 > discard it. =20 > > If it understands and knows what the stream is for, it would just =20 > > use it as if the stream was received from a different port. > > > > Are there any comments/suggestions from MMUSIC? > > > > -acbegen > > > >> ...Mark > >> > >> > >> On 4/24/09 10:53 AM, "Ali C. Begen (abegen)" =20 > >> wrote: > >> > >> > >> > >> Mark, All, > >> =09 > >> I have a question about multiplexing the source and > >> repair streams when they are both RTP. Currently, we have the > >> following text: > >> =09 > >> (Start of section 4) > >> =09 > >> The FEC Framework is described in terms of an > >> additional layer > >> between the transport layer (e.g. UDP or DCCP) and > >> protocols running > >> over this transport layer. Examples of such > >> protocols are RTP, RTCP, > >> etc. As such, the data path interface between the > >> FEC Framework and > >> both underlying and overlying layers can be thought > >> of as being the > >> same as the standard interface to the transport > >> layer - i.e. the data > >> exchanged consists of datagram payloads each > >> associated with a single > >> transport flow identified (in the case of UDP) by > >> the standard > >> 5-tuple { Source IP Address, Source Transport Port, > >> Destination IP > >> Address, Destination Transport Port, Transport > >> Protocol }. In the > >> case that RTP is used for the repair flows, the > >> source and repair > >> data may be multiplexed using RTP onto a single UDP > >> flow and must > >> consequently be demultiplexed at the receiver. > >> There are various > >> ways in which this multiplexing can be done, for > >> example as described > >> in [RFC4588]. > >> =09 > >> =09 > >> RFC 4588 mentions two ways of multiplexing RTP streams. > >> One is session multiplexing, where source and repair RTP > >> streams are in different RTP sessions (different dest > >> address/port). In this case, I don't have any issues, this > >> works beautifully with the framework. > >> =09 > >> The other one is SSRC multiplexing where the source and > >> repair RTP streams have different SSRCs but are transmitted > >> in the same RTP session (which is a single UDP flow). Is the > >> text above saying that the framework also support this kind > >> of multiplexing? In other words, is using a single UDP flow > >> to carry source + FEC data acceptable when they have=20 > separate SSRCs? > >> =09 > >> Not that FEC could not be used in this scenario, but as > >> I recall the framework required different UDP flows for > >> source and repair flows... > >> =09 > >> BR, > >> -acbegen > >> =09 > >> =09 > >> > >> > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe >=20 >=20 >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 >=20 From tme@americafree.tv Mon Apr 27 12:03:17 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45D693A7012; Mon, 27 Apr 2009 12:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599] 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 Nqc3uRVhfIVl; Mon, 27 Apr 2009 12:03:16 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 79A1B28C171; Mon, 27 Apr 2009 12:01:27 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 042FB3AE75CA; Mon, 27 Apr 2009 15:02:46 -0400 (EDT) Message-Id: <2FA6A311-8B9F-41FF-B9A3-04EB1E399732@americafree.tv> From: Marshall Eubanks To: Colin Perkins In-Reply-To: <8F9DD728-5AE9-4394-9BDD-4EDBFB92E4A5@csperkins.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 27 Apr 2009 15:02:45 -0400 References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> <8F9DD728-5AE9-4394-9BDD-4EDBFB92E4A5@csperkins.org> X-Mailer: Apple Mail (2.930.3) Cc: mmusic@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] RTP stream multiplexing in the fec framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 19:03:17 -0000 Dear Colin; On Apr 27, 2009, at 1:53 PM, Colin Perkins wrote: > On 24 Apr 2009, at 19:13, Ali C. Begen (abegen) wrote: >> Copying MMUSIC as this is relevant to: >> >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-source-attributes-02.txt >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4756bis-01.txt >> >>> -----Original Message----- >>> From: Watson, Mark [mailto:watson@qualcomm.com] >>> Sent: Friday, April 24, 2009 11:02 AM >>> To: Ali C. Begen (abegen); fecframe@ietf.org >>> Subject: Re: RTP stream multiplexing in the fec framework >>> >>> Ali, >>> >>> What do you think the Framework should do ? >> >> IMO, we should not restrict FEC to work only for session >> multiplexing (although I agree with you that doing so has many >> advantages). >> >> I see a few key reasons why people would use SSRC multiplexing, one >> being to simplify the port operations on NAT traversal. One session >> means one hole on NAT for the RTP transport (rtcp port can be the >> same or different). So, some apps may use ssrc multiplexing. > > The trend is clearly towards allowing multiplexing by RTP SSRC, to > ease NAT traversal by reducing the number of UDP ports. By that > argument, sending FEC data on the same port as the media it's > protecting doesn't seem problematic. (I wouldn't want to see > different media types on one port, but this is close enough related > that I don't see a big issue). > If someone wanted to use SSRC multiplexing in a audio or video conference with multiplexing (audio) or multiple displays (video), and then wanted to apply SSRC multiplexed FEC to that (say for sources on lossy wireless links), isn't there a danger that non-FEC aware receivers would not do the right thing with the FEC ? Regards Marshall >> I am about to finalize the 4756bis draft and so far my assumption >> has been that we would only do session multiplexing and use >> "a=group" for associations. This would not work for SSRC >> multiplexed streams, though. For that, we can use the "a=ssrc- >> group" attribute from Jonathan's draft. >> >>> SSRC multiplexing of source and repair is possible and the >>> intention was to support this in the Framework, but if it is >>> not required we could simplify by supporting only port >>> multiplexing. Port multiplexing is more straightforwardly >>> backwards-compatible (I'm not sure what an RTP receiver does >>> if it is expecting just one SSRC and it sees two). >> >> If it has a payload that it does not understand, it will discard >> it. If it understands and knows what the stream is for, it would >> just use it as if the stream was received from a different port. >> >> Are there any comments/suggestions from MMUSIC? >> >> -acbegen >> >>> ...Mark >>> >>> >>> On 4/24/09 10:53 AM, "Ali C. Begen (abegen)" >>> wrote: >>> >>> >>> >>> Mark, All, >>> >>> I have a question about multiplexing the source and >>> repair streams when they are both RTP. Currently, we have the >>> following text: >>> >>> (Start of section 4) >>> >>> The FEC Framework is described in terms of an >>> additional layer >>> between the transport layer (e.g. UDP or DCCP) and >>> protocols running >>> over this transport layer. Examples of such >>> protocols are RTP, RTCP, >>> etc. As such, the data path interface between the >>> FEC Framework and >>> both underlying and overlying layers can be thought >>> of as being the >>> same as the standard interface to the transport >>> layer - i.e. the data >>> exchanged consists of datagram payloads each >>> associated with a single >>> transport flow identified (in the case of UDP) by >>> the standard >>> 5-tuple { Source IP Address, Source Transport Port, >>> Destination IP >>> Address, Destination Transport Port, Transport >>> Protocol }. In the >>> case that RTP is used for the repair flows, the >>> source and repair >>> data may be multiplexed using RTP onto a single UDP >>> flow and must >>> consequently be demultiplexed at the receiver. >>> There are various >>> ways in which this multiplexing can be done, for >>> example as described >>> in [RFC4588]. >>> >>> >>> RFC 4588 mentions two ways of multiplexing RTP streams. >>> One is session multiplexing, where source and repair RTP >>> streams are in different RTP sessions (different dest >>> address/port). In this case, I don't have any issues, this >>> works beautifully with the framework. >>> >>> The other one is SSRC multiplexing where the source and >>> repair RTP streams have different SSRCs but are transmitted >>> in the same RTP session (which is a single UDP flow). Is the >>> text above saying that the framework also support this kind >>> of multiplexing? In other words, is using a single UDP flow >>> to carry source + FEC data acceptable when they have separate SSRCs? >>> >>> Not that FEC could not be used in this scenario, but as >>> I recall the framework required different UDP flows for >>> source and repair flows... >>> >>> BR, >>> -acbegen >>> >>> >>> >>> >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe > > > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > Regards Marshall Eubanks CEO / AmericaFree.TV From rem@videolan.org Mon Apr 27 12:13:35 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98AFE3A7007; Mon, 27 Apr 2009 12:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[AWL=1.174, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 qVE4vz4gDQ6o; Mon, 27 Apr 2009 12:13:34 -0700 (PDT) Received: from yop.chewa.net (yop.chewa.net [91.121.105.214]) by core3.amsl.com (Postfix) with ESMTP id 5E8BE3A6ACB; Mon, 27 Apr 2009 12:13:34 -0700 (PDT) Received: from basile.remlab.net (unknown [IPv6:2002:591b:3e37:0:211:11ff:fe25:e6b4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTPSA id 11949382; Mon, 27 Apr 2009 21:14:53 +0200 (CEST) From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: VideoLAN project - www.videolan.org To: mmusic@ietf.org Date: Mon, 27 Apr 2009 22:14:46 +0300 User-Agent: KMail/1.11.2 (Linux/2.6.29-1-686; KDE/4.2.2; i686; ; ) References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200904272214.47982.rem@videolan.org> X-Mailman-Approved-At: Mon, 27 Apr 2009 12:28:19 -0700 Cc: fecframe@ietf.org Subject: Re: [Fecframe] [MMUSIC] RTP stream multiplexing in the fec framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: remi@remlab.net List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 19:13:35 -0000 Le vendredi 24 avril 2009 21:13:08 Ali C. Begen (abegen), vous avez =E9crit= : > > What do you think the Framework should do ? > > IMO, we should not restrict FEC to work only for session multiplexing > (although I agree with you that doing so has many advantages). > > I see a few key reasons why people would use SSRC multiplexing, one being > to simplify the port operations on NAT traversal. One session means one > hole on NAT for the RTP transport (rtcp port can be the same or different= ). > So, some apps may use ssrc multiplexing. I actually do not see the point of SSRC multiplexing at all. If you want to= =20 include FEC infos on the same transport tuple as the protected media data, = why=20 don't you use a separate payload type? Using a separate SSRC on the same transport tuple will break compatiblity w= ith=20 receivers that only accept one session per socket at a time. Worse, it coul= d=20 break those pseudo-randomly, which would be hell from customer support=20 perspective. > I am about to finalize the 4756bis draft and so far my assumption has been > that we would only do session multiplexing and use "a=3Dgroup" for > associations. This would not work for SSRC multiplexed streams, though. F= or > that, we can use the "a=3Dssrc-group" attribute from Jonathan's draft. > > > SSRC multiplexing of source and repair is possible and the > > intention was to support this in the Framework, but if it is > > not required we could simplify by supporting only port > > multiplexing. Port multiplexing is more straightforwardly > > backwards-compatible (I'm not sure what an RTP receiver does > > if it is expecting just one SSRC and it sees two). > > If it has a payload that it does not understand, it will discard it. If it > understands and knows what the stream is for, it would just use it as if > the stream was received from a different port. That looks like the sanest (most backward compatible and NAT-friendly) opti= on=20 to me. =2D-=20 R=E9mi Denis-Courmont http://git.remlab.net/cgi-bin/gitweb.cgi?p=3Dvlc-courmisch.git;a=3Dsummary From abegen@cisco.com Mon Apr 27 12:32:33 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B4A03A692F; Mon, 27 Apr 2009 12:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.334 X-Spam-Level: X-Spam-Status: No, score=-6.334 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 VGiq+axfuIUB; Mon, 27 Apr 2009 12:32:32 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4E2A728C1EE; Mon, 27 Apr 2009 12:32:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,256,1238976000"; d="scan'208";a="293842813" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 27 Apr 2009 19:33:41 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3RJXf1j027819; Mon, 27 Apr 2009 12:33:41 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3RJXfCj027875; Mon, 27 Apr 2009 19:33:41 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 12:33:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Apr 2009 12:33:35 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C86F2@xmb-sjc-215.amer.cisco.com> In-Reply-To: <200904272214.47982.rem@videolan.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] RTP stream multiplexing in the fec framework Thread-Index: AcnHbHdaPqprgUXsS7ynhruR8YqB5gAAeYFw References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> <200904272214.47982.rem@videolan.org> From: "Ali C. Begen (abegen)" To: , X-OriginalArrivalTime: 27 Apr 2009 19:33:41.0265 (UTC) FILETIME=[11EA8810:01C9C76F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2863; t=1240860821; x=1241724821; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[MMUSIC]=20RTP=20stream=20multiplexing= 20in=20the=20fec=20framework |Sender:=20; bh=kGm6Razji0hFd0mIcGykwdRVIld9HGM7eb8rpvqS0y4=; b=HtEaMGfyOUIxTSznRm7Qt/QbYeZ5jmFIjaOWnXuaca10k8fRiI/oH/wWPn QkKqXpk6AEzQnG9g2opUmIIuYNXH8LDnS7UGg8y+kh8NeSqwopmOCfyJWK1c vcIqqC7/ln; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: fecframe@ietf.org Subject: Re: [Fecframe] [MMUSIC] RTP stream multiplexing in the fec framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 19:32:33 -0000 =20 > -----Original Message----- > From: R=E9mi Denis-Courmont [mailto:rem@videolan.org]=20 > Sent: Monday, April 27, 2009 12:15 PM > To: mmusic@ietf.org > Cc: Ali C. Begen (abegen); Watson, Mark; fecframe@ietf.org > Subject: Re: [MMUSIC] RTP stream multiplexing in the fec framework >=20 > Le vendredi 24 avril 2009 21:13:08 Ali C. Begen (abegen),=20 > vous avez =E9crit : > > > What do you think the Framework should do ? > > > > IMO, we should not restrict FEC to work only for session=20 > multiplexing > > (although I agree with you that doing so has many advantages). > > > > I see a few key reasons why people would use SSRC=20 > multiplexing, one being > > to simplify the port operations on NAT traversal. One=20 > session means one > > hole on NAT for the RTP transport (rtcp port can be the=20 > same or different). > > So, some apps may use ssrc multiplexing. >=20 > I actually do not see the point of SSRC multiplexing at all.=20 > If you want to=20 > include FEC infos on the same transport tuple as the=20 > protected media data, why=20 > don't you use a separate payload type? You mean payload-type multiplexing? Then, they will share the same SSRC = and seqnum space. The RTCP feedback including receiver reports or NACKS = will be shared, too. I guess section 5.2 of RFC 3550 provides good reasons for not doing = this. -acbegen =20 > Using a separate SSRC on the same transport tuple will break=20 > compatiblity with=20 > receivers that only accept one session per socket at a time.=20 > Worse, it could=20 > break those pseudo-randomly, which would be hell from=20 > customer support=20 > perspective. >=20 > > I am about to finalize the 4756bis draft and so far my=20 > assumption has been > > that we would only do session multiplexing and use "a=3Dgroup" for > > associations. This would not work for SSRC multiplexed=20 > streams, though. For > > that, we can use the "a=3Dssrc-group" attribute from Jonathan's = draft. > > > > > SSRC multiplexing of source and repair is possible and the > > > intention was to support this in the Framework, but if it is > > > not required we could simplify by supporting only port > > > multiplexing. Port multiplexing is more straightforwardly > > > backwards-compatible (I'm not sure what an RTP receiver does > > > if it is expecting just one SSRC and it sees two). > > > > If it has a payload that it does not understand, it will=20 > discard it. If it > > understands and knows what the stream is for, it would just=20 > use it as if > > the stream was received from a different port. >=20 > That looks like the sanest (most backward compatible and=20 > NAT-friendly) option=20 > to me. >=20 > --=20 > R=E9mi Denis-Courmont > = http://git.remlab.net/cgi-bin/gitweb.cgi?p=3Dvlc-courmisch.git;a=3Dsummar= y >=20 From csp@csperkins.org Mon Apr 27 13:52:25 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EAB528C1C5; Mon, 27 Apr 2009 13:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 NPGEd4TTdDOy; Mon, 27 Apr 2009 13:52:24 -0700 (PDT) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by core3.amsl.com (Postfix) with ESMTP id 23EA428C1C7; Mon, 27 Apr 2009 13:51:23 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=mangole.lan) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1LyXoh-0005ti-kd; Mon, 27 Apr 2009 20:52:43 +0000 Message-Id: From: Colin Perkins To: Marshall Eubanks In-Reply-To: <2FA6A311-8B9F-41FF-B9A3-04EB1E399732@americafree.tv> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 27 Apr 2009 21:52:35 +0100 References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> <8F9DD728-5AE9-4394-9BDD-4EDBFB92E4A5@csperkins.org> <2FA6A311-8B9F-41FF-B9A3-04EB1E399732@americafree.tv> X-Mailer: Apple Mail (2.930.3) Cc: mmusic@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] RTP stream multiplexing in the fec framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 20:52:25 -0000 On 27 Apr 2009, at 20:02, Marshall Eubanks wrote: > On Apr 27, 2009, at 1:53 PM, Colin Perkins wrote: >> On 24 Apr 2009, at 19:13, Ali C. Begen (abegen) wrote: ... > >>> IMO, we should not restrict FEC to work only for session >>> multiplexing (although I agree with you that doing so has many >>> advantages). >>> >>> I see a few key reasons why people would use SSRC multiplexing, >>> one being to simplify the port operations on NAT traversal. One >>> session means one hole on NAT for the RTP transport (rtcp port can >>> be the same or different). So, some apps may use ssrc multiplexing. >> >> The trend is clearly towards allowing multiplexing by RTP SSRC, to >> ease NAT traversal by reducing the number of UDP ports. By that >> argument, sending FEC data on the same port as the media it's >> protecting doesn't seem problematic. (I wouldn't want to see >> different media types on one port, but this is close enough related >> that I don't see a big issue). > > If someone wanted to use SSRC multiplexing in a audio or video > conference with multiplexing (audio) or multiple displays (video), > and then wanted to apply SSRC multiplexed FEC to that (say for > sources on lossy wireless links), isn't there a danger that non-FEC > aware receivers would not do the right thing with the FEC ? I don't think so. Non-FEC aware receivers would see an unknown payload type, which they should ignore. What's your specific concern with that scenario? -- Colin Perkins http://csperkins.org/ From csp@csperkins.org Mon Apr 27 14:01:09 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB54A3A680D; Mon, 27 Apr 2009 14:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 uqipFyW8g+TV; Mon, 27 Apr 2009 14:01:08 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by core3.amsl.com (Postfix) with ESMTP id 26A543A6A02; Mon, 27 Apr 2009 14:00:43 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=mangole.lan) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1LyXxj-0004c0-ap; Mon, 27 Apr 2009 21:02:03 +0000 Message-Id: <7D1B0D8B-BCFE-463B-B2F4-E627729A198D@csperkins.org> From: Colin Perkins To: Ali C. Begen (abegen) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C86BE@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 27 Apr 2009 22:01:47 +0100 References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> <8F9DD728-5AE9-4394-9BDD-4EDBFB92E4A5@csperkins.org> <04CAD96D4C5A3D48B1919248A8FE0D54092C86BE@xmb-sjc-215.amer.cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: mmusic@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] [MMUSIC] RTP stream multiplexing in the fec framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 21:01:09 -0000 Yes, for the purposes for grouping FEC and the original media, in cases where you're trying to reduce port usage. Colin On 27 Apr 2009, at 20:00, Ali C. Begen (abegen) wrote: > Is that a "yes" for ssrc-level grouping for FEC? > > -acbegen > >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org] >> Sent: Monday, April 27, 2009 10:54 AM >> To: Ali C. Begen (abegen) >> Cc: Watson, Mark; fecframe@ietf.org; mmusic@ietf.org >> Subject: Re: [Fecframe] RTP stream multiplexing in the fec framework >> >> On 24 Apr 2009, at 19:13, Ali C. Begen (abegen) wrote: >>> Copying MMUSIC as this is relevant to: >>> >>> >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-sour > ce-attributes-02.txt >>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic- >>> rfc4756bis-01.txt >>> >>>> -----Original Message----- >>>> From: Watson, Mark [mailto:watson@qualcomm.com] >>>> Sent: Friday, April 24, 2009 11:02 AM >>>> To: Ali C. Begen (abegen); fecframe@ietf.org >>>> Subject: Re: RTP stream multiplexing in the fec framework >>>> >>>> Ali, >>>> >>>> What do you think the Framework should do ? >>> >>> IMO, we should not restrict FEC to work only for session >>> multiplexing (although I agree with you that doing so has many >>> advantages). >>> >>> I see a few key reasons why people would use SSRC >> multiplexing, one >>> being to simplify the port operations on NAT traversal. One >> session >>> means one hole on NAT for the RTP transport (rtcp port can be the >>> same or different). So, some apps may use ssrc multiplexing. >> >> The trend is clearly towards allowing multiplexing by RTP SSRC, to >> ease NAT traversal by reducing the number of UDP ports. By that >> argument, sending FEC data on the same port as the media it's >> protecting doesn't seem problematic. (I wouldn't want to see >> different >> media types on one port, but this is close enough related >> that I don't >> see a big issue). >> >>> I am about to finalize the 4756bis draft and so far my assumption >>> has been that we would only do session multiplexing and use >>> "a=group" for associations. This would not work for SSRC >> multiplexed >>> streams, though. For that, we can use the "a=ssrc-group" attribute >>> from Jonathan's draft. >>> >>>> SSRC multiplexing of source and repair is possible and the >>>> intention was to support this in the Framework, but if it is >>>> not required we could simplify by supporting only port >>>> multiplexing. Port multiplexing is more straightforwardly >>>> backwards-compatible (I'm not sure what an RTP receiver does >>>> if it is expecting just one SSRC and it sees two). >>> >>> If it has a payload that it does not understand, it will >> discard it. >>> If it understands and knows what the stream is for, it would just >>> use it as if the stream was received from a different port. >>> >>> Are there any comments/suggestions from MMUSIC? >>> >>> -acbegen >>> >>>> ...Mark >>>> >>>> >>>> On 4/24/09 10:53 AM, "Ali C. Begen (abegen)" >>>> wrote: >>>> >>>> >>>> >>>> Mark, All, >>>> >>>> I have a question about multiplexing the source and >>>> repair streams when they are both RTP. Currently, we have the >>>> following text: >>>> >>>> (Start of section 4) >>>> >>>> The FEC Framework is described in terms of an >>>> additional layer >>>> between the transport layer (e.g. UDP or DCCP) and >>>> protocols running >>>> over this transport layer. Examples of such >>>> protocols are RTP, RTCP, >>>> etc. As such, the data path interface between the >>>> FEC Framework and >>>> both underlying and overlying layers can be thought >>>> of as being the >>>> same as the standard interface to the transport >>>> layer - i.e. the data >>>> exchanged consists of datagram payloads each >>>> associated with a single >>>> transport flow identified (in the case of UDP) by >>>> the standard >>>> 5-tuple { Source IP Address, Source Transport Port, >>>> Destination IP >>>> Address, Destination Transport Port, Transport >>>> Protocol }. In the >>>> case that RTP is used for the repair flows, the >>>> source and repair >>>> data may be multiplexed using RTP onto a single UDP >>>> flow and must >>>> consequently be demultiplexed at the receiver. >>>> There are various >>>> ways in which this multiplexing can be done, for >>>> example as described >>>> in [RFC4588]. >>>> >>>> >>>> RFC 4588 mentions two ways of multiplexing RTP streams. >>>> One is session multiplexing, where source and repair RTP >>>> streams are in different RTP sessions (different dest >>>> address/port). In this case, I don't have any issues, this >>>> works beautifully with the framework. >>>> >>>> The other one is SSRC multiplexing where the source and >>>> repair RTP streams have different SSRCs but are transmitted >>>> in the same RTP session (which is a single UDP flow). Is the >>>> text above saying that the framework also support this kind >>>> of multiplexing? In other words, is using a single UDP flow >>>> to carry source + FEC data acceptable when they have >> separate SSRCs? >>>> >>>> Not that FEC could not be used in this scenario, but as >>>> I recall the framework required different UDP flows for >>>> source and repair flows... >>>> >>>> BR, >>>> -acbegen >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Fecframe mailing list >>> Fecframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/fecframe >> >> >> >> -- >> Colin Perkins >> http://csperkins.org/ >> >> >> >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -- Colin Perkins http://csperkins.org/ From ron.even.tlv@gmail.com Mon Apr 27 14:21:24 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CB2928C1DD; Mon, 27 Apr 2009 14:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599] 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 oKwQRwejq1sY; Mon, 27 Apr 2009 14:21:17 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id 6698A3A6960; Mon, 27 Apr 2009 14:21:15 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so1189171fgb.18 for ; Mon, 27 Apr 2009 14:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=oMxqr0jp/WNFj5exXRhaCsAnqtH+G5Kqjikoi5bq/Ao=; b=c08vO+TbrA17Ve/G30r6k8DJFu96nT1KzuI26HomWgUfLDLbVUeIELjoz5tKZ/5HSS QzeyLPNIF1yXrhLF8kYjr9XX0P3O0ant1qeuwcr2TgNf+VIzXvwMmhLGVNJuvhKSTGsb 3YdH4tfGpeeabZCsJI+mVoi2RDL8RALOLTSKE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=qgGbk3jQGbLnofZyJLh6yfjGBcEZYM73mSd+6IBnKQ6NLnsYHWkkS7xGLmrip7MlQl N8/Vcy1wii/IdJS4ri0UEdbr2slNZ1FVq7aEYh+xnlinc/dqpZXWGnNtm0wOXaEA6TgU wAQkKlrojyeWGY1Q3lfBjoIlXo30JFDGwbPVA= Received: by 10.86.26.11 with SMTP id 11mr3726735fgz.45.1240867355450; Mon, 27 Apr 2009 14:22:35 -0700 (PDT) Received: from windows8d787f9 (bzq-79-182-99-139.red.bezeqint.net [79.182.99.139]) by mx.google.com with ESMTPS id l19sm1889311fgb.7.2009.04.27.14.22.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 27 Apr 2009 14:22:34 -0700 (PDT) From: "Roni Even" To: "'Colin Perkins'" , "'Ali C. Begen \(abegen\)'" References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> <8F9DD728-5AE9-4394-9BDD-4EDBFB92E4A5@csperkins.org> <04CAD96D4C5A3D48B1919248A8FE0D54092C86BE@xmb-sjc-215.amer.cisco.com> <7D1B0D8B-BCFE-463B-B2F4-E627729A198D@csperkins.org> In-Reply-To: <7D1B0D8B-BCFE-463B-B2F4-E627729A198D@csperkins.org> Date: Tue, 28 Apr 2009 00:20:46 +0300 Message-ID: <49f6221a.1358560a.5aa1.ffff8e46@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnHe5MfvPcJVLxoQt2no+euUsGaogAAgopg Content-Language: en-us Cc: mmusic@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] [MMUSIC] RTP stream multiplexing in the fec framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 21:21:24 -0000 Hi, I support Colin's view and I think this is why you also specify media of type audio, video and text for the fec stream enabling the multiplexing. I think that maybe there will be a need for a parameter that defines the relation between the original stream and the fec stream similar to the grouping or to the red in RFC 2198 Roni Even -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Colin Perkins Sent: Tuesday, April 28, 2009 12:02 AM To: Ali C. Begen (abegen) Cc: Watson, Mark; mmusic@ietf.org; fecframe@ietf.org Subject: Re: [MMUSIC] [Fecframe] RTP stream multiplexing in the fec framework Yes, for the purposes for grouping FEC and the original media, in cases where you're trying to reduce port usage. Colin On 27 Apr 2009, at 20:00, Ali C. Begen (abegen) wrote: > Is that a "yes" for ssrc-level grouping for FEC? > > -acbegen > >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org] >> Sent: Monday, April 27, 2009 10:54 AM >> To: Ali C. Begen (abegen) >> Cc: Watson, Mark; fecframe@ietf.org; mmusic@ietf.org >> Subject: Re: [Fecframe] RTP stream multiplexing in the fec framework >> >> On 24 Apr 2009, at 19:13, Ali C. Begen (abegen) wrote: >>> Copying MMUSIC as this is relevant to: >>> >>> >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-sour > ce-attributes-02.txt >>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic- >>> rfc4756bis-01.txt >>> >>>> -----Original Message----- >>>> From: Watson, Mark [mailto:watson@qualcomm.com] >>>> Sent: Friday, April 24, 2009 11:02 AM >>>> To: Ali C. Begen (abegen); fecframe@ietf.org >>>> Subject: Re: RTP stream multiplexing in the fec framework >>>> >>>> Ali, >>>> >>>> What do you think the Framework should do ? >>> >>> IMO, we should not restrict FEC to work only for session >>> multiplexing (although I agree with you that doing so has many >>> advantages). >>> >>> I see a few key reasons why people would use SSRC >> multiplexing, one >>> being to simplify the port operations on NAT traversal. One >> session >>> means one hole on NAT for the RTP transport (rtcp port can be the >>> same or different). So, some apps may use ssrc multiplexing. >> >> The trend is clearly towards allowing multiplexing by RTP SSRC, to >> ease NAT traversal by reducing the number of UDP ports. By that >> argument, sending FEC data on the same port as the media it's >> protecting doesn't seem problematic. (I wouldn't want to see >> different >> media types on one port, but this is close enough related >> that I don't >> see a big issue). >> >>> I am about to finalize the 4756bis draft and so far my assumption >>> has been that we would only do session multiplexing and use >>> "a=group" for associations. This would not work for SSRC >> multiplexed >>> streams, though. For that, we can use the "a=ssrc-group" attribute >>> from Jonathan's draft. >>> >>>> SSRC multiplexing of source and repair is possible and the >>>> intention was to support this in the Framework, but if it is >>>> not required we could simplify by supporting only port >>>> multiplexing. Port multiplexing is more straightforwardly >>>> backwards-compatible (I'm not sure what an RTP receiver does >>>> if it is expecting just one SSRC and it sees two). >>> >>> If it has a payload that it does not understand, it will >> discard it. >>> If it understands and knows what the stream is for, it would just >>> use it as if the stream was received from a different port. >>> >>> Are there any comments/suggestions from MMUSIC? >>> >>> -acbegen >>> >>>> ...Mark >>>> >>>> >>>> On 4/24/09 10:53 AM, "Ali C. Begen (abegen)" >>>> wrote: >>>> >>>> >>>> >>>> Mark, All, >>>> >>>> I have a question about multiplexing the source and >>>> repair streams when they are both RTP. Currently, we have the >>>> following text: >>>> >>>> (Start of section 4) >>>> >>>> The FEC Framework is described in terms of an >>>> additional layer >>>> between the transport layer (e.g. UDP or DCCP) and >>>> protocols running >>>> over this transport layer. Examples of such >>>> protocols are RTP, RTCP, >>>> etc. As such, the data path interface between the >>>> FEC Framework and >>>> both underlying and overlying layers can be thought >>>> of as being the >>>> same as the standard interface to the transport >>>> layer - i.e. the data >>>> exchanged consists of datagram payloads each >>>> associated with a single >>>> transport flow identified (in the case of UDP) by >>>> the standard >>>> 5-tuple { Source IP Address, Source Transport Port, >>>> Destination IP >>>> Address, Destination Transport Port, Transport >>>> Protocol }. In the >>>> case that RTP is used for the repair flows, the >>>> source and repair >>>> data may be multiplexed using RTP onto a single UDP >>>> flow and must >>>> consequently be demultiplexed at the receiver. >>>> There are various >>>> ways in which this multiplexing can be done, for >>>> example as described >>>> in [RFC4588]. >>>> >>>> >>>> RFC 4588 mentions two ways of multiplexing RTP streams. >>>> One is session multiplexing, where source and repair RTP >>>> streams are in different RTP sessions (different dest >>>> address/port). In this case, I don't have any issues, this >>>> works beautifully with the framework. >>>> >>>> The other one is SSRC multiplexing where the source and >>>> repair RTP streams have different SSRCs but are transmitted >>>> in the same RTP session (which is a single UDP flow). Is the >>>> text above saying that the framework also support this kind >>>> of multiplexing? In other words, is using a single UDP flow >>>> to carry source + FEC data acceptable when they have >> separate SSRCs? >>>> >>>> Not that FEC could not be used in this scenario, but as >>>> I recall the framework required different UDP flows for >>>> source and repair flows... >>>> >>>> BR, >>>> -acbegen >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Fecframe mailing list >>> Fecframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/fecframe >> >> >> >> -- >> Colin Perkins >> http://csperkins.org/ >> >> >> >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From tme@americafree.tv Mon Apr 27 14:22:03 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E09D628C187; Mon, 27 Apr 2009 14:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] 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 mTrDkaWzmN7u; Mon, 27 Apr 2009 14:22:03 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 6471B28C1F9; Mon, 27 Apr 2009 14:21:59 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 523DE3AEA6C6; Mon, 27 Apr 2009 17:23:19 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Colin Perkins In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 27 Apr 2009 17:23:16 -0400 References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> <8F9DD728-5AE9-4394-9BDD-4EDBFB92E4A5@csperkins.org> <2FA6A311-8B9F-41FF-B9A3-04EB1E399732@americafree.tv> X-Mailer: Apple Mail (2.930.3) Cc: mmusic@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] RTP stream multiplexing in the fec framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 21:22:04 -0000 Dear Colin; On Apr 27, 2009, at 4:52 PM, Colin Perkins wrote: > On 27 Apr 2009, at 20:02, Marshall Eubanks wrote: >> On Apr 27, 2009, at 1:53 PM, Colin Perkins wrote: >>> On 24 Apr 2009, at 19:13, Ali C. Begen (abegen) wrote: > ... >> >>>> IMO, we should not restrict FEC to work only for session >>>> multiplexing (although I agree with you that doing so has many >>>> advantages). >>>> >>>> I see a few key reasons why people would use SSRC multiplexing, >>>> one being to simplify the port operations on NAT traversal. One >>>> session means one hole on NAT for the RTP transport (rtcp port >>>> can be the same or different). So, some apps may use ssrc >>>> multiplexing. >>> >>> The trend is clearly towards allowing multiplexing by RTP SSRC, to >>> ease NAT traversal by reducing the number of UDP ports. By that >>> argument, sending FEC data on the same port as the media it's >>> protecting doesn't seem problematic. (I wouldn't want to see >>> different media types on one port, but this is close enough >>> related that I don't see a big issue). >> >> If someone wanted to use SSRC multiplexing in a audio or video >> conference with multiplexing (audio) or multiple displays (video), >> and then wanted to apply SSRC multiplexed FEC to that (say for >> sources on lossy wireless links), isn't there a danger that non-FEC >> aware receivers would not do the right thing with the FEC ? > > > I don't think so. Non-FEC aware receivers would see an unknown > payload type, which they should ignore. What's your specific concern > with that scenario? > I am trying to understand all of the worries expressed here Separate audio and video streams SHOULD NOT be carried in a single RTP session and demultiplexed based on the payload type or SSRC fields. Interleaving packets with different RTP media types but using the same SSRC would introduce several problems: Using a different SSRC for each medium but sending them in the same RTP session would avoid the first three problems but not the last two So, to be clear, what is proposed is to send the FEC repair stream with one source address and port, but a different SSRC and payload type (from the original stream) ? In that case, I am happy. Regards Marshall > -- > Colin Perkins > http://csperkins.org/ > > > > Regards Marshall Eubanks CEO / AmericaFree.TV From tme@multicasttech.com Mon Apr 27 14:29:51 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96C0F3A6DE3 for ; Mon, 27 Apr 2009 14:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.645 X-Spam-Level: X-Spam-Status: No, score=-102.645 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] 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 i4+8mwzwYLTX for ; Mon, 27 Apr 2009 14:29:50 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 299053A6C46 for ; Mon, 27 Apr 2009 14:29:50 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id B7B593AEAA66 for ; Mon, 27 Apr 2009 17:31:09 -0400 (EDT) Message-Id: <4A4DC69D-6ACC-4551-9244-16F43420CC79@multicasttech.com> From: Marshall Eubanks To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 27 Apr 2009 17:31:09 -0400 References: <20090427145627.971283A6CBC@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) Subject: [Fecframe] Fwd: 75th IETF - Working Group/BOF Scheduling X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 21:29:51 -0000 Note well Begin forwarded message: > From: IETF Agenda > Date: April 27, 2009 10:56:27 AM EDT > To: Working Group Chairs > Cc: irsg@isi.edu, bofchairs@ietf.org > Subject: 75th IETF - Working Group/BOF Scheduling > > ----------------------------------------------------------------- > 75th IETF =96 Stockholm, Sweden > Meeting Dates: July 26-31, 2009 > Host: .SE > ----------------------------------------------------------------- > IETF meetings start Monday morning and run through Friday mid-=20 > afternoon > (15:15). > > We are accepting scheduling requests for all Working Groups and BOFs > starting. The milestones and deadlines for scheduling-related =20 > activities > are as follows: > > NOTE: cutoff dates are subject to change. > > May 25, Monday - Cutoff date for requests to schedule Working Group > meetings and for preliminary BOF proposals to ADs at 17:00 PDT (24:00 > UTC/GMT). > June 8, Monday - Cutoff date for requests to Area Directors to =20 > schedule > BOFs at 17:00 PDT (24:00 UTC/GMT). > June 15, Monday - Cutoff date for Area Directors to approve BOFs at =20= > 17:00 > PDT (24:00 UTC/GMT). > June 19, Friday - Preliminary agenda published for comment. > July 1, Wednesday - Cutoff date for requests to reschedule Working =20 > Group > and BOF meetings 17:00 PDT (24:00 UTC/GMT). > July 6, Monday - Final agenda to be published. > July 15, Wednesday - Draft Working Group agendas due by 17:00 PT =20 > (24:00 > UTC/GMT). > July 20, Monday - Revised Working Group agendas due by 17:00 PT (24:00 > UTC/GMT). > > Submitting Requests for Working Group and BOF Sessions > > Please submit requests to schedule your Working Group sessions using =20= > the > "IETF Meeting Session Request Tool," a Web-based tool for submitting =20= > all > of the information that the Secretariat requires to schedule your > sessions. > > The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi > > Instructions for using the tool are available at: > > http://www.ietf.org/instructions/session_request_tool_instruction.html > > Please send requests to schedule your BOF sessions to agenda@ietf.org. > Please include the acronym of your BOF in the subject line of the =20 > message, > and include all of the information specified in item (4) of =20 > "Requesting > Meeting Sessions at IETF Meetings" in the body. (This document is > included below.) > > Submitting Session Agendas > > For the convenience of meeting attendees, we ask that you submit the > agendas for your Working Group sessions as early as possible. Draft > Working Group agendas are due Wednesday, July 15 by 17:00 PDT (24:00 > UTC/GMT). Revised Working Group agendas are due no later than Monday, > July 20 at 17:00 PDT (24:00 UTC/GMT). The proposed agenda for a BOF > session should be submitted along with your request for a session. =20= > Please > be sure to copy your Area Director on that message. > > Please submit the agendas for your Working Group sessions using the =20= > "IETF > Meeting Materials Management Tool," a Web-based tool for making your > meeting agenda, minutes, and presentation slides available to the > community before, during, and after an IETF meeting. If you are a BOF > chair, then you may use the tool to submit a revised agenda as well as > other materials for your BOF once the BOF has been approved. > > The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi > > Additional information about this tool is available at: > > http://www.ietf.org/instructions/meeting_materials_tool.html > > Agendas submitted via the tool will be available to the public on the > "IETF Meeting Materials" Web page as soon as they are submitted. > > The URL for the "IETF 75 Meeting Materials" Web page is: > > = https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D75= > > If you are a Working Group chair, then you already have accounts on =20= > the > "IETF Meeting Session Request Tool" and the "IETF Meeting Materials > Management Tool." The same User ID and password will work for both =20= > tools. > If you are a BOF chair who is not also a Working Group chair, then =20= > you > will be given an account on the "IETF Meeting Materials Management =20 > Tool" > when your BOF has been approved. If you require assistance in using > either tool, or wish to report a bug, then please send a message to: > ietf-action@ietf.org. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > For your convenience, comprehensive information on requesting meeting > sessions at IETF 75 is presented below: > > 1. Requests to schedule Working Group sessions should be submitted =20 > using > the "IETF Meeting Session Request Tool," a Web-based tool for =20 > submitting > all of the information required by the Secretariat to schedule your > sessions. The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi > > Instructions for using the tool are available at: > > http://www.ietf.org/instructions/session_request_tool_instruction.html > > If you require an account on this tool, or assistance in using it, =20 > then > please send a message to ietf-action@ietf.org. If you are unable to =20= > use > the tool, then you may send your request via e-mail to =20 > agenda@ietf.org, > with a copy to the appropriate Area Director(s). > > Requests to schedule BOF sessions must be sent to agenda@ietf.org =20 > with a > copy to the appropriate Area Director(s). > > When submitting a Working Group or BOF session request by e-mail, =20 > please > include the Working Group or BOF acronym in the Subject line. > > 2. BOFs will NOT be scheduled unless the Area Director(s) approved > request is accompanied by a BOF'S FULL NAME AND ACRONYM, AREA, =20 > CHAIR(S) > NAME(S) (given together with e-mail address(es)), AN AGENDA AND FULL > DESCRIPTION, and the information requested in (4) below. (Please =20 > read the > BOF Procedure at: http://www.ietf.org/ietf/1bof-procedures.txt before > requesting a session for a BOF.) > > 3. A Working Group may request either one or two sessions. If your > Working Group requires more than two sessions, then your request =20 > must be > approved by an Area Director. Additional sessions will be assigned, =20= > based > on availability, after Wednesday, July 1 at 17:00 PDT (24:00 UTC/=20 > GMT), the > cut-off date for requests to reschedule a session. > > 4. You MUST provide the following information before a Working Group =20= > or > BOF session will be scheduled: > > a. Working Group or BOF full name with acronym in brackets: > > b. AREA under which Working Group or BOF appears: > > c. CONFLICTS you wish to avoid, please be as specific as possible: > > d. Expected Attendance (figures from the 74th IETF meeting are > included at the end of this message): > > e. Special requests: > > f. Number of sessions: > > g. Length of session: > - 1 hour > - 1 1/2 hours > - 2 hours > - 2 1/2 hours > > For more information on scheduling Working Group and BOF sessions, =20 > please > refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and =20 > Procedures" > (http://www.ietf.org/rfc/rfc2418.txt). > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > For your convenience please find here a list of the IETF Area =20 > Directors > with their e-mail addresses: > > IETF Chair > Russ Housley > > Applications Area (app) > Lisa Dusseault > Alexey Melnikov > > Internet Area (int) > Jari Arkko > Ralph Droms > > Operations & Management Area (ops) > Ronald Bonica > Dan Romascanu > > Real-time Applications and Infrastructure Area (rai) > Cullen Jennings > Robert Sparks > > Routing Area (rtg) > Ross Callon > Adrian Farrel > > Security Area (sec) > Pasi Eronen > Tim Polk > > Transport Area (tsv) > Lars Eggert > Magnus Westerlund > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 74th IETF Meeting Attendance Number > > 6ai 189 > 6lowpan NO SHEETS > 6man 138 > alto 112 > ancp 21 > apparea 92 > atoca 77 > autoconf 34 > avt 77 > avt (2nd session) 65 > behave 150 > behave (2nd session) 116 > bliss 64 > bmwg 23 > capwap 16 > ccamp 76 > ccamp (2nd session) 55 > csi 16 > dccp 18 > dhc 50 > dime 31 > dkim 46 > dnsop 90 > drinks 69 > dtnrg 44 > ecrit 80 > emu 35 > fecframe 17 > forces 20 > geopriv 68 > grow 75 > hiprg 38 > hokey 40 > httpbis 25 > idnabis 70 > idnabis (2nd session) 41 > idr 127 > intarea 207 > ipfix 32 > ippm 46 > ipsecme 44 > isms 25 > keyprov 24 > kitten 11 > krb-wg 26 > l2vpn 149 > l3vpn 48 > ledbat 30 > lisp 176 > manet 45 > mboned 37 > mediactrl 47 > mext 96 > mif 68 > mip4 35 > mipshop 57 > mmox 77 > mmusic 75 > morg 15 > mpls 144 > mpls (2nd session) 135 > msec 30 > nea 28 > netconf 39 > netext 68 > netmod 25 > netmod (2nd session) 32 > nfsv4 22 > nsis 23 > oauth 105 > opsarea 86 > opsec 24 > ospf 34 > p2prg 99 > p2psip 71 > pce 63 > pcn 24 > pim 41 > pkix 50 > pmol 27 > pre8prob 44 > pwe3 115 > radext 19 > rtgarea 122 > rmt 12 > roll 69 > rrg 106 > rtgwg 112 > saag 116 > sasl 24 > savi 60 > shara 155 > sidr 77 > sieve 17 > simple 69 > sip 126 > sip (2nd session) 117 > sipping 92 > softwire 73 > speermint 63 > storm 14 > tcpm 33 > tcpm (2nd session) 59 > tictoc 37 > tls 44 > trill 55 > tsvarea 72 > tsvwg 47 > v6ops 126 > v6ops (second session) 65 > vcarddav 18 > xcon 48 > xmpp2 86 > yam 41 > From csp@csperkins.org Mon Apr 27 15:08:38 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D04C28C19C; Mon, 27 Apr 2009 15:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 cYrDUmv2zuIS; Mon, 27 Apr 2009 15:08:37 -0700 (PDT) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by core3.amsl.com (Postfix) with ESMTP id 4500528C168; Mon, 27 Apr 2009 15:08:37 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=mangole.lan) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1LyZ1R-00072j-XC; Mon, 27 Apr 2009 22:09:58 +0000 Message-Id: From: Colin Perkins To: Marshall Eubanks In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 27 Apr 2009 23:09:48 +0100 References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> <8F9DD728-5AE9-4394-9BDD-4EDBFB92E4A5@csperkins.org> <2FA6A311-8B9F-41FF-B9A3-04EB1E399732@americafree.tv> X-Mailer: Apple Mail (2.930.3) Cc: mmusic@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] RTP stream multiplexing in the fec framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 22:08:38 -0000 On 27 Apr 2009, at 22:23, Marshall Eubanks wrote: > On Apr 27, 2009, at 4:52 PM, Colin Perkins wrote: >> On 27 Apr 2009, at 20:02, Marshall Eubanks wrote: >>> On Apr 27, 2009, at 1:53 PM, Colin Perkins wrote: >>>> On 24 Apr 2009, at 19:13, Ali C. Begen (abegen) wrote: >> ... >>> >>>>> IMO, we should not restrict FEC to work only for session >>>>> multiplexing (although I agree with you that doing so has many >>>>> advantages). >>>>> >>>>> I see a few key reasons why people would use SSRC multiplexing, >>>>> one being to simplify the port operations on NAT traversal. One >>>>> session means one hole on NAT for the RTP transport (rtcp port >>>>> can be the same or different). So, some apps may use ssrc >>>>> multiplexing. >>>> >>>> The trend is clearly towards allowing multiplexing by RTP SSRC, >>>> to ease NAT traversal by reducing the number of UDP ports. By >>>> that argument, sending FEC data on the same port as the media >>>> it's protecting doesn't seem problematic. (I wouldn't want to see >>>> different media types on one port, but this is close enough >>>> related that I don't see a big issue). >>> >>> If someone wanted to use SSRC multiplexing in a audio or video >>> conference with multiplexing (audio) or multiple displays (video), >>> and then wanted to apply SSRC multiplexed FEC to that (say for >>> sources on lossy wireless links), isn't there a danger that non- >>> FEC aware receivers would not do the right thing with the FEC ? >> >> >> I don't think so. Non-FEC aware receivers would see an unknown >> payload type, which they should ignore. What's your specific >> concern with that scenario? > > I am trying to understand all of the worries expressed here > > > Separate audio and video streams SHOULD NOT be carried in a single > RTP session and demultiplexed based on the payload type or SSRC > fields. Interleaving packets with different RTP media types but > using the same SSRC would introduce several problems: > > Using a different SSRC for each medium but sending them in the same > RTP session would avoid the first three problems but not the last two > > > So, to be clear, what is proposed is to send the FEC repair stream > with one source address and port, but a different SSRC and payload > type (from the original stream) ? As I understand it, this is being proposed as one option for sending FEC data (with the ability to send the FEC on a separate port as the other option). In terms of the last two points in section 5.2 of RFC 3550, an RTP mixer that understands FEC can make use of the FEC data when mixing (and if it doesn't understand the FEC, the quality is degraded, but the mixer still works); and the only reason to use SSRC multiplexing here is specifically to use the same network path for the FEC and media, making the last point moot. -- Colin Perkins http://csperkins.org/ From abegen@cisco.com Mon Apr 27 15:58:36 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 704433A6F4D; Mon, 27 Apr 2009 15:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 PXRiNG5bHMIB; Mon, 27 Apr 2009 15:58:35 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 348EB3A6DFF; Mon, 27 Apr 2009 15:58:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,257,1238976000"; d="scan'208";a="157115723" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 27 Apr 2009 22:59:56 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3RMxuFT026672; Mon, 27 Apr 2009 15:59:56 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3RMxumL021790; Mon, 27 Apr 2009 22:59:56 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 15:59:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Apr 2009 15:59:48 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C88A0@xmb-sjc-215.amer.cisco.com> In-Reply-To: <7D1B0D8B-BCFE-463B-B2F4-E627729A198D@csperkins.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] [Fecframe] RTP stream multiplexing in the fec framework Thread-Index: AcnHe3o2t9udAcKdTMOM0tgu2HypagAD0Deg References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> <8F9DD728-5AE9-4394-9BDD-4EDBFB92E4A5@csperkins.org> <04CAD96D4C5A3D48B1919248A8FE0D54092C86BE@xmb-sjc-215.amer.cisco.com> <7D1B0D8B-BCFE-463B-B2F4-E627729A198D@csperkins.org> From: "Ali C. Begen (abegen)" To: "Colin Perkins" X-OriginalArrivalTime: 27 Apr 2009 22:59:56.0340 (UTC) FILETIME=[E2091F40:01C9C78B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7197; t=1240873196; x=1241737196; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[MMUSIC]=20[Fecframe]=20RTP=20stream=20 multiplexing=20in=20the=20fec=20framework |Sender:=20; bh=qYn9oNHMYjXT7k6npO/B+WY36g6fGxAgq6Ezsirs8gg=; b=VKvXNPXB1Sp9YDIhXxpbzyDz47nZLqDlzfAiO9ynyzxzbNX0uZYLV+4Ytz 6cZq3UkPgF1SIqm9nOEnEAHC+jV+GLJzNBMPmifLMpdP0HAq3/rCkNjvGb/4 +Z9FsYZRxh; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: mmusic@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] [MMUSIC] RTP stream multiplexing in the fec framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 22:58:36 -0000 Alright, looks like we need to have SSRC multiplexing for FEC, and thus, = we need grouping support for it (a=3Dssrc-group). I'll revise the = 4756bis and submit a new version for review. One more question, though. Should we allow for "a=3Dssrc-group:FEC-XR" = semantics only if SSRC multiplexing is used and mandate = "a=3Dgroup:FEC-XR" semantics for everything else (for non-RTP flows and = when session multiplexing is used)? Or, should we also allow = "a=3Dssrc-group:FEC-XR" semantics for session multiplexing as well? -acbegen > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org]=20 > Sent: Monday, April 27, 2009 2:02 PM > To: Ali C. Begen (abegen) > Cc: Watson, Mark; mmusic@ietf.org; fecframe@ietf.org > Subject: Re: [MMUSIC] [Fecframe] RTP stream multiplexing in=20 > the fec framework >=20 > Yes, for the purposes for grouping FEC and the original media, in =20 > cases where you're trying to reduce port usage. >=20 > Colin >=20 >=20 >=20 > On 27 Apr 2009, at 20:00, Ali C. Begen (abegen) wrote: > > Is that a "yes" for ssrc-level grouping for FEC? > > > > -acbegen > > > >> -----Original Message----- > >> From: Colin Perkins [mailto:csp@csperkins.org] > >> Sent: Monday, April 27, 2009 10:54 AM > >> To: Ali C. Begen (abegen) > >> Cc: Watson, Mark; fecframe@ietf.org; mmusic@ietf.org > >> Subject: Re: [Fecframe] RTP stream multiplexing in the fec=20 > framework > >> > >> On 24 Apr 2009, at 19:13, Ali C. Begen (abegen) wrote: > >>> Copying MMUSIC as this is relevant to: > >>> > >>> > >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-sour > > ce-attributes-02.txt > >>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic- > >>> rfc4756bis-01.txt > >>> > >>>> -----Original Message----- > >>>> From: Watson, Mark [mailto:watson@qualcomm.com] > >>>> Sent: Friday, April 24, 2009 11:02 AM > >>>> To: Ali C. Begen (abegen); fecframe@ietf.org > >>>> Subject: Re: RTP stream multiplexing in the fec framework > >>>> > >>>> Ali, > >>>> > >>>> What do you think the Framework should do ? > >>> > >>> IMO, we should not restrict FEC to work only for session > >>> multiplexing (although I agree with you that doing so has many > >>> advantages). > >>> > >>> I see a few key reasons why people would use SSRC > >> multiplexing, one > >>> being to simplify the port operations on NAT traversal. One > >> session > >>> means one hole on NAT for the RTP transport (rtcp port can be the > >>> same or different). So, some apps may use ssrc multiplexing. > >> > >> The trend is clearly towards allowing multiplexing by RTP SSRC, to > >> ease NAT traversal by reducing the number of UDP ports. By that > >> argument, sending FEC data on the same port as the media it's > >> protecting doesn't seem problematic. (I wouldn't want to see > >> different > >> media types on one port, but this is close enough related > >> that I don't > >> see a big issue). > >> > >>> I am about to finalize the 4756bis draft and so far my assumption > >>> has been that we would only do session multiplexing and use > >>> "a=3Dgroup" for associations. This would not work for SSRC > >> multiplexed > >>> streams, though. For that, we can use the "a=3Dssrc-group" = attribute > >>> from Jonathan's draft. > >>> > >>>> SSRC multiplexing of source and repair is possible and the > >>>> intention was to support this in the Framework, but if it is > >>>> not required we could simplify by supporting only port > >>>> multiplexing. Port multiplexing is more straightforwardly > >>>> backwards-compatible (I'm not sure what an RTP receiver does > >>>> if it is expecting just one SSRC and it sees two). > >>> > >>> If it has a payload that it does not understand, it will > >> discard it. > >>> If it understands and knows what the stream is for, it would just > >>> use it as if the stream was received from a different port. > >>> > >>> Are there any comments/suggestions from MMUSIC? > >>> > >>> -acbegen > >>> > >>>> ...Mark > >>>> > >>>> > >>>> On 4/24/09 10:53 AM, "Ali C. Begen (abegen)" > >>>> wrote: > >>>> > >>>> > >>>> > >>>> Mark, All, > >>>> =09 > >>>> I have a question about multiplexing the source and > >>>> repair streams when they are both RTP. Currently, we have the > >>>> following text: > >>>> =09 > >>>> (Start of section 4) > >>>> =09 > >>>> The FEC Framework is described in terms of an > >>>> additional layer > >>>> between the transport layer (e.g. UDP or DCCP) and > >>>> protocols running > >>>> over this transport layer. Examples of such > >>>> protocols are RTP, RTCP, > >>>> etc. As such, the data path interface between the > >>>> FEC Framework and > >>>> both underlying and overlying layers can be thought > >>>> of as being the > >>>> same as the standard interface to the transport > >>>> layer - i.e. the data > >>>> exchanged consists of datagram payloads each > >>>> associated with a single > >>>> transport flow identified (in the case of UDP) by > >>>> the standard > >>>> 5-tuple { Source IP Address, Source Transport Port, > >>>> Destination IP > >>>> Address, Destination Transport Port, Transport > >>>> Protocol }. In the > >>>> case that RTP is used for the repair flows, the > >>>> source and repair > >>>> data may be multiplexed using RTP onto a single UDP > >>>> flow and must > >>>> consequently be demultiplexed at the receiver. > >>>> There are various > >>>> ways in which this multiplexing can be done, for > >>>> example as described > >>>> in [RFC4588]. > >>>> =09 > >>>> =09 > >>>> RFC 4588 mentions two ways of multiplexing RTP streams. > >>>> One is session multiplexing, where source and repair RTP > >>>> streams are in different RTP sessions (different dest > >>>> address/port). In this case, I don't have any issues, this > >>>> works beautifully with the framework. > >>>> =09 > >>>> The other one is SSRC multiplexing where the source and > >>>> repair RTP streams have different SSRCs but are transmitted > >>>> in the same RTP session (which is a single UDP flow). Is the > >>>> text above saying that the framework also support this kind > >>>> of multiplexing? In other words, is using a single UDP flow > >>>> to carry source + FEC data acceptable when they have > >> separate SSRCs? > >>>> =09 > >>>> Not that FEC could not be used in this scenario, but as > >>>> I recall the framework required different UDP flows for > >>>> source and repair flows... > >>>> =09 > >>>> BR, > >>>> -acbegen > >>>> =09 > >>>> =09 > >>>> > >>>> > >>> _______________________________________________ > >>> Fecframe mailing list > >>> Fecframe@ietf.org > >>> https://www.ietf.org/mailman/listinfo/fecframe > >> > >> > >> > >> --=20 > >> Colin Perkins > >> http://csperkins.org/ > >> > >> > >> > >> > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic >=20 >=20 >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 >=20 From abegen@cisco.com Mon Apr 27 18:21:59 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9DB93A6F71 for ; Mon, 27 Apr 2009 18:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.344 X-Spam-Level: X-Spam-Status: No, score=-6.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 UyGxfZnmcqAY for ; Mon, 27 Apr 2009 18:21:58 -0700 (PDT) Received: from syd-iport-1.cisco.com (syd-iport-1.cisco.com [64.104.193.196]) by core3.amsl.com (Postfix) with ESMTP id 935FA3A68D5 for ; Mon, 27 Apr 2009 18:21:57 -0700 (PDT) Received: from syd-dkim-1.cisco.com ([64.104.193.116]) by syd-iport-1.cisco.com with ESMTP; 28 Apr 2009 01:23:16 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by syd-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3S1NFa6032436; Tue, 28 Apr 2009 11:23:16 +1000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3S1Mc81021941; Tue, 28 Apr 2009 01:23:15 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 18:23:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Apr 2009 18:22:50 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C893B@xmb-sjc-215.amer.cisco.com> In-Reply-To: <387DA3D4-8B91-48C8-BB08-3C0725D112F8@multicasttech.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Working Group Last Call ondraft-ietf-fecframe-config-signaling Thread-Index: AcnAUCNYynfRGSGsQD6kxc3yiHM2EQHSdwDA References: <387DA3D4-8B91-48C8-BB08-3C0725D112F8@multicasttech.com> From: "Ali C. Begen (abegen)" To: "Marshall Eubanks" , X-OriginalArrivalTime: 28 Apr 2009 01:23:12.0938 (UTC) FILETIME=[E601E0A0:01C9C79F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3322; t=1240881796; x=1241745796; c=relaxed/simple; s=syddkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[Fecframe]=20Working=20Group=20Last=20C all=20ondraft-ietf-fecframe-config-signaling |Sender:=20; bh=L5r8GPQM/M/hbLXoVSYS4+iF9I0tObQEKCELp2cyPrc=; b=VFovjDrNTC/mjZUEL/OAwfT89tUnnJ1sN97Oa93O1ihmGj2vijmHkENaZP tkyb8VS+L9emg3Lcs8/rx7GRpueUFaVOq34BCYeS/uMFSBxpUwzD3tyNat4U W9i4rI3pKge1BWRTUiKqBgTE5BR5vag7iO17XbjQKgtkL8VJBbQ+g=; Authentication-Results: syd-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/syddkim1002 verified; ); Subject: Re: [Fecframe] Working Group Last Call ondraft-ietf-fecframe-config-signaling X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 01:21:59 -0000 These are my comments for this draft. I suppose due to normative = references, this document will have to wait for the framework and SDP = drafts anyway. BR, -acbegen - Page 4: "This document does not make any assumption that the 'FEC sender and=20 receiver' functionality and the 'Media Source/Receiver' functionality = are implemented on the single device, though it may be the case." Should read: "This document does not make any assumption that the Media Sender and = FEC Sender functionalities or the Media Receiver and FEC Receiver = functionalities are implemented on the same host, although this may be = the case." - page 5: "Each instance of the FEC Framework muse use a single encoding format = to describe e.g. encode all of the configuration information=20 associated with that instance." I believe we need to make it clear that an FEC scheme can support = multiple signaling protocols but it must use a single encoding format in = a particular instance. - page 5 and beyond: "Unicasted", "multicasted" should be "unicast", "multicast". - page 10: There is an editor's note, which should be removed (the note itself = could be kept).=20 - Section 4.2.2: Is this section suggesting/assigning/registering any new RTSP = parameters? If so, is there a proper way of doing it? Any IANA = considerations that this document needs to have? - Section 4.2.3: Not sure how useful this section is. At least, the document should = provide the references for the mentioned specs. Nits: - "Configuration Information" is sometimes capitalized, sometimes not. = The document needs to be consistent.=20 - Typo in page 2: "FEC scheme specifics information". Use FSSI where = possible. - Need for plural versions at the end of Section 1, i.e., multicast = applications, unicast applications, security considerations. "section X" = should be "Section X". - Inconsistent capitalization in the numbered list on page 3. - Missing commas before and after "i.e." - Spell out "OAM" on page 4 - "provide a mean" --> "provide a means" on page 4 - The capitalization of special words like "MUST, MAY, SHOULD" be = checked as there are many occasions where the capitalized versions would = probably make more sense.=20 - Typo on page 9: "doesn't already exists" - Conclusions section can be removed. > -----Original Message----- > From: fecframe-bounces@ietf.org=20 > [mailto:fecframe-bounces@ietf.org] On Behalf Of Marshall Eubanks > Sent: Saturday, April 18, 2009 11:04 AM > To: fecframe@ietf.org > Subject: [Fecframe] Working Group Last Call=20 > ondraft-ietf-fecframe-config-signaling >=20 > I think that this document is also ready, so I would like to issue > a working group last call on=20 > draft-ietf-fecframe-config-signaling-01. =20 > This document can be > found at >=20 > http://tools.ietf.org/id/draft-ietf-fecframe-config-signaling-01.txt >=20 > I encourage everyone to read this document and comment during=20 > the last =20 > call period. >=20 > This last call will end on Monday, May 4th, 2009. >=20 > Regards > Marshall Eubanks > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe >=20 From abegen@cisco.com Mon Apr 27 21:28:40 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC8F63A68A5 for ; Mon, 27 Apr 2009 21:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.348 X-Spam-Level: X-Spam-Status: No, score=-6.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 C2u0ylTZZ5TM for ; Mon, 27 Apr 2009 21:28:40 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id ED3203A67B5 for ; Mon, 27 Apr 2009 21:28:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,258,1238976000"; d="scan'208";a="177708896" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 28 Apr 2009 04:30:01 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3S4U1LD017215; Mon, 27 Apr 2009 21:30:01 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n3S4U1Zb010322; Tue, 28 Apr 2009 04:30:01 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 21:30:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Apr 2009 21:29:22 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C8988@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49D5FF8D.8020806@inrialpes.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Review of draft-ietf-fecframe-framework-03 Thread-Index: Acm0Vu+kl9W1yEjwSgmadzdP3tevagTYZIiA References: <49D5FF8D.8020806@inrialpes.fr> From: "Ali C. Begen (abegen)" To: "Vincent Roca" , X-OriginalArrivalTime: 28 Apr 2009 04:30:01.0281 (UTC) FILETIME=[FEB34B10:01C9C7B9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1197; t=1240893001; x=1241757001; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[Fecframe]=20Review=20of=20draft-ietf-f ecframe-framework-03 |Sender:=20; bh=11iqd9n/QVaUNmh5/wof8IquiY4wdX3lKvJ91CIWEII=; b=fwHk4WIue9RykhJHBYr6BTRC4IOQoN7uWf3xLw8MDxApsjV9gLFlGCelLG Bxr/+m5aeUaFsVJe6Z2jZR1QEWG+5rrW62NjIQHZqXF+aSYWJp9Lm8fapLdK mp/qZZJ/JG; Authentication-Results: sj-dkim-4; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Fecframe] Review of draft-ietf-fecframe-framework-03 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 04:28:40 -0000 I mostly agree with Vincent's comments - he did a very detailed review. = The draft needs clarifications on the terminology and missing = definitions should be provided. Besides, based on the recent feedback from MMUSIC, I suggest we clarify = the multiplexing issues for RTP flows. Essentially, we will somewhat = recommend session multiplexing to be mostly aligned with our prior = design goals. But, we also have to support SSRC multiplexing so that we = cover the applications that use that type of multiplexing to reduce the = port usage. We should strongly discourage payload type multiplexing per = RFC 3550. I can help with the text, if needed. BR, -acbegen > -----Original Message----- > From: fecframe-bounces@ietf.org=20 > [mailto:fecframe-bounces@ietf.org] On Behalf Of Vincent Roca > Sent: Friday, April 03, 2009 5:23 AM > To: fecframe@ietf.org > Subject: [Fecframe] Review of draft-ietf-fecframe-framework-03 >=20 > Mark, everybody, >=20 > Since the goal was to start a WGLC on the framework document,=20 > I anticipated > a little bit the announce... (sorry if it creates problems). > Here are my comments. >=20 > Regards, >=20 > Vincent >=20 From ron.even.tlv@gmail.com Tue Apr 28 00:06:15 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A93C83A6947; Tue, 28 Apr 2009 00:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.685 X-Spam-Level: X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] 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 M0BGUiZwR6FP; Tue, 28 Apr 2009 00:06:14 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id 1EA613A705B; Tue, 28 Apr 2009 00:05:42 -0700 (PDT) Received: by bwz7 with SMTP id 7so346274bwz.37 for ; Tue, 28 Apr 2009 00:07:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=Gty0zKak7NF+GCouhQEFjadSL2TPpju1IP7WXqQqtig=; b=EySf1898y3qIBe5WcqQ3iY030TzfMZUJsnIYsvGZaJZeQ2JkgpL8vnotVT4CsGEvY6 DEmxIgnxBcFMmJ79b7To5s4qg3NzzdnEqv9x/KEjSyYVG6CPQLTeaZoo8tCJqZfPx0BJ xYBLlcUNh4V5p34IMXMnesfxzBrIaZYQT1+CQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=sAOGqwArG9gMAkFgeQ2BPoJMvoJVxRmsnto6wBRWwQ3q/pgvWO/YzNc+M0qKvgXGMj sttBMPFi75iQHt0y4K7j5K0auqlvBzwHOttTy/TikuKxtKrmMeJ3XNNgbpaksYgu5ghb HwpT+CafuaG7x69bLRYvFDqjpnVTWgWVvk/n0= Received: by 10.103.227.10 with SMTP id e10mr3704527mur.67.1240902423283; Tue, 28 Apr 2009 00:07:03 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-61-236.red.bezeqint.net [79.177.61.236]) by mx.google.com with ESMTPS id s10sm5203094muh.58.2009.04.28.00.07.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 28 Apr 2009 00:07:02 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , "'Colin Perkins'" References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> <8F9DD728-5AE9-4394-9BDD-4EDBFB92E4A5@csperkins.org> <04CAD96D4C5A3D48B1919248A8FE0D54092C86BE@xmb-sjc-215.amer.cisco.com> <7D1B0D8B-BCFE-463B-B2F4-E627729A198D@csperkins.org> <04CAD96D4C5A3D48B1919248A8FE0D54092C88A0@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C88A0@xmb-sjc-215.amer.cisco.com> Date: Tue, 28 Apr 2009 10:05:04 +0300 Message-ID: <49f6ab16.0af5660a.1039.5418@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnHe3o2t9udAcKdTMOM0tgu2HypagAD0DegABEeFuA= Content-Language: en-us Cc: mmusic@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] [MMUSIC] RTP stream multiplexing in the fec framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 07:06:15 -0000 Ali, I think that if you would want to use a=ssrc-group:fec-xr also for session multiplexing it will be a session level attribute duplicating the a=group and having problem with SSRC number uniqueness across RTP sessions. I think it will be best to have the a=ssrc-group as a media level attribute only Roni -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Ali C. Begen (abegen) Sent: Tuesday, April 28, 2009 2:00 AM To: Colin Perkins Cc: Watson, Mark; mmusic@ietf.org; fecframe@ietf.org Subject: Re: [MMUSIC] [Fecframe] RTP stream multiplexing in the fec framework Alright, looks like we need to have SSRC multiplexing for FEC, and thus, we need grouping support for it (a=ssrc-group). I'll revise the 4756bis and submit a new version for review. One more question, though. Should we allow for "a=ssrc-group:FEC-XR" semantics only if SSRC multiplexing is used and mandate "a=group:FEC-XR" semantics for everything else (for non-RTP flows and when session multiplexing is used)? Or, should we also allow "a=ssrc-group:FEC-XR" semantics for session multiplexing as well? -acbegen > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Monday, April 27, 2009 2:02 PM > To: Ali C. Begen (abegen) > Cc: Watson, Mark; mmusic@ietf.org; fecframe@ietf.org > Subject: Re: [MMUSIC] [Fecframe] RTP stream multiplexing in > the fec framework > > Yes, for the purposes for grouping FEC and the original media, in > cases where you're trying to reduce port usage. > > Colin > > > > On 27 Apr 2009, at 20:00, Ali C. Begen (abegen) wrote: > > Is that a "yes" for ssrc-level grouping for FEC? > > > > -acbegen > > > >> -----Original Message----- > >> From: Colin Perkins [mailto:csp@csperkins.org] > >> Sent: Monday, April 27, 2009 10:54 AM > >> To: Ali C. Begen (abegen) > >> Cc: Watson, Mark; fecframe@ietf.org; mmusic@ietf.org > >> Subject: Re: [Fecframe] RTP stream multiplexing in the fec > framework > >> > >> On 24 Apr 2009, at 19:13, Ali C. Begen (abegen) wrote: > >>> Copying MMUSIC as this is relevant to: > >>> > >>> > >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-sour > > ce-attributes-02.txt > >>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic- > >>> rfc4756bis-01.txt > >>> > >>>> -----Original Message----- > >>>> From: Watson, Mark [mailto:watson@qualcomm.com] > >>>> Sent: Friday, April 24, 2009 11:02 AM > >>>> To: Ali C. Begen (abegen); fecframe@ietf.org > >>>> Subject: Re: RTP stream multiplexing in the fec framework > >>>> > >>>> Ali, > >>>> > >>>> What do you think the Framework should do ? > >>> > >>> IMO, we should not restrict FEC to work only for session > >>> multiplexing (although I agree with you that doing so has many > >>> advantages). > >>> > >>> I see a few key reasons why people would use SSRC > >> multiplexing, one > >>> being to simplify the port operations on NAT traversal. One > >> session > >>> means one hole on NAT for the RTP transport (rtcp port can be the > >>> same or different). So, some apps may use ssrc multiplexing. > >> > >> The trend is clearly towards allowing multiplexing by RTP SSRC, to > >> ease NAT traversal by reducing the number of UDP ports. By that > >> argument, sending FEC data on the same port as the media it's > >> protecting doesn't seem problematic. (I wouldn't want to see > >> different > >> media types on one port, but this is close enough related > >> that I don't > >> see a big issue). > >> > >>> I am about to finalize the 4756bis draft and so far my assumption > >>> has been that we would only do session multiplexing and use > >>> "a=group" for associations. This would not work for SSRC > >> multiplexed > >>> streams, though. For that, we can use the "a=ssrc-group" attribute > >>> from Jonathan's draft. > >>> > >>>> SSRC multiplexing of source and repair is possible and the > >>>> intention was to support this in the Framework, but if it is > >>>> not required we could simplify by supporting only port > >>>> multiplexing. Port multiplexing is more straightforwardly > >>>> backwards-compatible (I'm not sure what an RTP receiver does > >>>> if it is expecting just one SSRC and it sees two). > >>> > >>> If it has a payload that it does not understand, it will > >> discard it. > >>> If it understands and knows what the stream is for, it would just > >>> use it as if the stream was received from a different port. > >>> > >>> Are there any comments/suggestions from MMUSIC? > >>> > >>> -acbegen > >>> > >>>> ...Mark > >>>> > >>>> > >>>> On 4/24/09 10:53 AM, "Ali C. Begen (abegen)" > >>>> wrote: > >>>> > >>>> > >>>> > >>>> Mark, All, > >>>> > >>>> I have a question about multiplexing the source and > >>>> repair streams when they are both RTP. Currently, we have the > >>>> following text: > >>>> > >>>> (Start of section 4) > >>>> > >>>> The FEC Framework is described in terms of an > >>>> additional layer > >>>> between the transport layer (e.g. UDP or DCCP) and > >>>> protocols running > >>>> over this transport layer. Examples of such > >>>> protocols are RTP, RTCP, > >>>> etc. As such, the data path interface between the > >>>> FEC Framework and > >>>> both underlying and overlying layers can be thought > >>>> of as being the > >>>> same as the standard interface to the transport > >>>> layer - i.e. the data > >>>> exchanged consists of datagram payloads each > >>>> associated with a single > >>>> transport flow identified (in the case of UDP) by > >>>> the standard > >>>> 5-tuple { Source IP Address, Source Transport Port, > >>>> Destination IP > >>>> Address, Destination Transport Port, Transport > >>>> Protocol }. In the > >>>> case that RTP is used for the repair flows, the > >>>> source and repair > >>>> data may be multiplexed using RTP onto a single UDP > >>>> flow and must > >>>> consequently be demultiplexed at the receiver. > >>>> There are various > >>>> ways in which this multiplexing can be done, for > >>>> example as described > >>>> in [RFC4588]. > >>>> > >>>> > >>>> RFC 4588 mentions two ways of multiplexing RTP streams. > >>>> One is session multiplexing, where source and repair RTP > >>>> streams are in different RTP sessions (different dest > >>>> address/port). In this case, I don't have any issues, this > >>>> works beautifully with the framework. > >>>> > >>>> The other one is SSRC multiplexing where the source and > >>>> repair RTP streams have different SSRCs but are transmitted > >>>> in the same RTP session (which is a single UDP flow). Is the > >>>> text above saying that the framework also support this kind > >>>> of multiplexing? In other words, is using a single UDP flow > >>>> to carry source + FEC data acceptable when they have > >> separate SSRCs? > >>>> > >>>> Not that FEC could not be used in this scenario, but as > >>>> I recall the framework required different UDP flows for > >>>> source and repair flows... > >>>> > >>>> BR, > >>>> -acbegen > >>>> > >>>> > >>>> > >>>> > >>> _______________________________________________ > >>> Fecframe mailing list > >>> Fecframe@ietf.org > >>> https://www.ietf.org/mailman/listinfo/fecframe > >> > >> > >> > >> -- > >> Colin Perkins > >> http://csperkins.org/ > >> > >> > >> > >> > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From abegen@cisco.com Tue Apr 28 00:57:56 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C0653A7091; Tue, 28 Apr 2009 00:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.052 X-Spam-Level: X-Spam-Status: No, score=-6.052 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] 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 MaJrFIw8ANiL; Tue, 28 Apr 2009 00:57:54 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8DE973A7088; Tue, 28 Apr 2009 00:57:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,259,1238976000"; d="scan'208,217";a="294179309" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 28 Apr 2009 07:59:14 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3S7xEdK024121; Tue, 28 Apr 2009 00:59:14 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3S7xEUW017913; Tue, 28 Apr 2009 07:59:14 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Apr 2009 00:59:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C7D7.37D1C102" Date: Tue, 28 Apr 2009 00:59:12 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54066184F9@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] [Fecframe] RTP stream multiplexing in the fec framework Thread-Index: AcnHe3o2t9udAcKdTMOM0tgu2HypagAD0DegABEeFuAAAgEQ2A== From: "Ali C. Begen (abegen)" To: , X-OriginalArrivalTime: 28 Apr 2009 07:59:13.0980 (UTC) FILETIME=[38B127C0:01C9C7D7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=29207; t=1240905554; x=1241769554; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20Re=3A=20[MMUSIC]=20[Fecframe]=20RTP=20stream=20 multiplexing=20in=20the=20fec=20framework |Sender:=20; bh=OAX+YNxAJlof6LJjSi5AvmiZnac+bkpfuZyed2yz4yc=; b=gz0hq3c9aIk1yBrlQwMrketSdoIFjoHWyEKZXx7uX97h2zxRFeLxRIBT7i zZjIFd+/8DhMvRzq7pVe3hf6WvJ3zsgK710Jydld5zmBbe7XzpcyflDXDtYp U+W9L9zUe6MmuWs0zeiyydQiqnpO7VAZ6jLw61ztaP4+c8ch/SHlw=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: mmusic@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] [MMUSIC] RTP stream multiplexing in the fec framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 07:57:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C7D7.37D1C102 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 R29vZCBwb2ludCwgSSBhZ3JlZSB3aXRoIHRoaXMgYXNzZXNzbWVudC4gDQoNCkJSLA0KDQoNCi1h Y2JlZ2VuIChCYmVycnkgY3JpcHBsZWQpDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0N CkZyb206IFJvbmkgRXZlbiA8cm9uLmV2ZW4udGx2QGdtYWlsLmNvbT4NClRvOiBBbGkgQy4gQmVn ZW4gKGFiZWdlbik7ICdDb2xpbiBQZXJraW5zJyA8Y3NwQGNzcGVya2lucy5vcmc+DQpDYzogJ1dh dHNvbiwgTWFyaycgPHdhdHNvbkBxdWFsY29tbS5jb20+OyBtbXVzaWNAaWV0Zi5vcmcgPG1tdXNp Y0BpZXRmLm9yZz47IGZlY2ZyYW1lQGlldGYub3JnIDxmZWNmcmFtZUBpZXRmLm9yZz4NClNlbnQ6 IFR1ZSBBcHIgMjggMDA6MDU6MDQgMjAwOQ0KU3ViamVjdDogUkU6IFtNTVVTSUNdIFtGZWNmcmFt ZV0gUlRQIHN0cmVhbSBtdWx0aXBsZXhpbmcgaW4gdGhlIGZlYyBmcmFtZXdvcmsNCg0KQWxpLA0K SSB0aGluayB0aGF0IGlmIHlvdSB3b3VsZCB3YW50IHRvIHVzZSBhPXNzcmMtZ3JvdXA6ZmVjLXhy IGFsc28gZm9yIHNlc3Npb24NCm11bHRpcGxleGluZyBpdCB3aWxsIGJlIGEgc2Vzc2lvbiBsZXZl bCBhdHRyaWJ1dGUgZHVwbGljYXRpbmcgdGhlIGE9Z3JvdXANCmFuZCBoYXZpbmcgcHJvYmxlbSB3 aXRoIFNTUkMgbnVtYmVyIHVuaXF1ZW5lc3MgYWNyb3NzIFJUUCBzZXNzaW9ucy4gSSB0aGluaw0K aXQgd2lsbCBiZSBiZXN0IHRvIGhhdmUgdGhlIGE9c3NyYy1ncm91cCBhcyBhIG1lZGlhIGxldmVs IGF0dHJpYnV0ZSBvbmx5DQpSb25pDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBtbXVzaWMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YNCkFsaSBDLiBCZWdlbiAoYWJlZ2VuKQ0KU2VudDogVHVlc2RheSwgQXBy aWwgMjgsIDIwMDkgMjowMCBBTQ0KVG86IENvbGluIFBlcmtpbnMNCkNjOiBXYXRzb24sIE1hcms7 IG1tdXNpY0BpZXRmLm9yZzsgZmVjZnJhbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTU1VU0lD XSBbRmVjZnJhbWVdIFJUUCBzdHJlYW0gbXVsdGlwbGV4aW5nIGluIHRoZSBmZWMNCmZyYW1ld29y aw0KDQpBbHJpZ2h0LCBsb29rcyBsaWtlIHdlIG5lZWQgdG8gaGF2ZSBTU1JDIG11bHRpcGxleGlu ZyBmb3IgRkVDLCBhbmQgdGh1cywgd2UNCm5lZWQgZ3JvdXBpbmcgc3VwcG9ydCBmb3IgaXQgKGE9 c3NyYy1ncm91cCkuIEknbGwgcmV2aXNlIHRoZSA0NzU2YmlzIGFuZA0Kc3VibWl0IGEgbmV3IHZl cnNpb24gZm9yIHJldmlldy4NCg0KT25lIG1vcmUgcXVlc3Rpb24sIHRob3VnaC4gU2hvdWxkIHdl IGFsbG93IGZvciAiYT1zc3JjLWdyb3VwOkZFQy1YUiINCnNlbWFudGljcyBvbmx5IGlmIFNTUkMg bXVsdGlwbGV4aW5nIGlzIHVzZWQgYW5kIG1hbmRhdGUgImE9Z3JvdXA6RkVDLVhSIg0Kc2VtYW50 aWNzIGZvciBldmVyeXRoaW5nIGVsc2UgKGZvciBub24tUlRQIGZsb3dzIGFuZCB3aGVuIHNlc3Np b24NCm11bHRpcGxleGluZyBpcyB1c2VkKT8gT3IsIHNob3VsZCB3ZSBhbHNvIGFsbG93ICJhPXNz cmMtZ3JvdXA6RkVDLVhSIg0Kc2VtYW50aWNzIGZvciBzZXNzaW9uIG11bHRpcGxleGluZyBhcyB3 ZWxsPw0KDQotYWNiZWdlbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IENvbGluIFBlcmtpbnMgW21haWx0bzpjc3BAY3NwZXJraW5zLm9yZ10gDQo+IFNlbnQ6IE1vbmRh eSwgQXByaWwgMjcsIDIwMDkgMjowMiBQTQ0KPiBUbzogQWxpIEMuIEJlZ2VuIChhYmVnZW4pDQo+ IENjOiBXYXRzb24sIE1hcms7IG1tdXNpY0BpZXRmLm9yZzsgZmVjZnJhbWVAaWV0Zi5vcmcNCj4g U3ViamVjdDogUmU6IFtNTVVTSUNdIFtGZWNmcmFtZV0gUlRQIHN0cmVhbSBtdWx0aXBsZXhpbmcg aW4gDQo+IHRoZSBmZWMgZnJhbWV3b3JrDQo+IA0KPiBZZXMsIGZvciB0aGUgcHVycG9zZXMgZm9y IGdyb3VwaW5nIEZFQyBhbmQgdGhlIG9yaWdpbmFsIG1lZGlhLCBpbiAgDQo+IGNhc2VzIHdoZXJl IHlvdSdyZSB0cnlpbmcgdG8gcmVkdWNlIHBvcnQgdXNhZ2UuDQo+IA0KPiBDb2xpbg0KPiANCj4g DQo+IA0KPiBPbiAyNyBBcHIgMjAwOSwgYXQgMjA6MDAsIEFsaSBDLiBCZWdlbiAoYWJlZ2VuKSB3 cm90ZToNCj4gPiBJcyB0aGF0IGEgInllcyIgZm9yIHNzcmMtbGV2ZWwgZ3JvdXBpbmcgZm9yIEZF Qz8NCj4gPg0KPiA+IC1hY2JlZ2VuDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gPj4gRnJvbTogQ29saW4gUGVya2lucyBbbWFpbHRvOmNzcEBjc3BlcmtpbnMub3JnXQ0K PiA+PiBTZW50OiBNb25kYXksIEFwcmlsIDI3LCAyMDA5IDEwOjU0IEFNDQo+ID4+IFRvOiBBbGkg Qy4gQmVnZW4gKGFiZWdlbikNCj4gPj4gQ2M6IFdhdHNvbiwgTWFyazsgZmVjZnJhbWVAaWV0Zi5v cmc7IG1tdXNpY0BpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW0ZlY2ZyYW1lXSBSVFAgc3Ry ZWFtIG11bHRpcGxleGluZyBpbiB0aGUgZmVjIA0KPiBmcmFtZXdvcmsNCj4gPj4NCj4gPj4gT24g MjQgQXByIDIwMDksIGF0IDE5OjEzLCBBbGkgQy4gQmVnZW4gKGFiZWdlbikgd3JvdGU6DQo+ID4+ PiBDb3B5aW5nIE1NVVNJQyBhcyB0aGlzIGlzIHJlbGV2YW50IHRvOg0KPiA+Pj4NCj4gPj4+DQo+ ID4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbW11c2lj LXNkcC1zb3VyDQo+ID4gY2UtYXR0cmlidXRlcy0wMi50eHQNCj4gPj4+IGh0dHA6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbW11c2ljLQ0KPiA+Pj4gcmZjNDc1NmJp cy0wMS50eHQNCj4gPj4+DQo+ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+ PiBGcm9tOiBXYXRzb24sIE1hcmsgW21haWx0bzp3YXRzb25AcXVhbGNvbW0uY29tXQ0KPiA+Pj4+ IFNlbnQ6IEZyaWRheSwgQXByaWwgMjQsIDIwMDkgMTE6MDIgQU0NCj4gPj4+PiBUbzogQWxpIEMu IEJlZ2VuIChhYmVnZW4pOyBmZWNmcmFtZUBpZXRmLm9yZw0KPiA+Pj4+IFN1YmplY3Q6IFJlOiBS VFAgc3RyZWFtIG11bHRpcGxleGluZyBpbiB0aGUgZmVjIGZyYW1ld29yaw0KPiA+Pj4+DQo+ID4+ Pj4gQWxpLA0KPiA+Pj4+DQo+ID4+Pj4gV2hhdCBkbyB5b3UgdGhpbmsgdGhlIEZyYW1ld29yayBz aG91bGQgZG8gPw0KPiA+Pj4NCj4gPj4+IElNTywgd2Ugc2hvdWxkIG5vdCByZXN0cmljdCBGRUMg dG8gd29yayBvbmx5IGZvciBzZXNzaW9uDQo+ID4+PiBtdWx0aXBsZXhpbmcgKGFsdGhvdWdoIEkg YWdyZWUgd2l0aCB5b3UgdGhhdCBkb2luZyBzbyBoYXMgbWFueQ0KPiA+Pj4gYWR2YW50YWdlcyku DQo+ID4+Pg0KPiA+Pj4gSSBzZWUgYSBmZXcga2V5IHJlYXNvbnMgd2h5IHBlb3BsZSB3b3VsZCB1 c2UgU1NSQw0KPiA+PiBtdWx0aXBsZXhpbmcsIG9uZQ0KPiA+Pj4gYmVpbmcgdG8gc2ltcGxpZnkg dGhlIHBvcnQgb3BlcmF0aW9ucyBvbiBOQVQgdHJhdmVyc2FsLiBPbmUNCj4gPj4gc2Vzc2lvbg0K PiA+Pj4gbWVhbnMgb25lIGhvbGUgb24gTkFUIGZvciB0aGUgUlRQIHRyYW5zcG9ydCAocnRjcCBw b3J0IGNhbiBiZSB0aGUNCj4gPj4+IHNhbWUgb3IgZGlmZmVyZW50KS4gU28sIHNvbWUgYXBwcyBt YXkgdXNlIHNzcmMgbXVsdGlwbGV4aW5nLg0KPiA+Pg0KPiA+PiBUaGUgdHJlbmQgaXMgY2xlYXJs eSB0b3dhcmRzIGFsbG93aW5nIG11bHRpcGxleGluZyBieSBSVFAgU1NSQywgdG8NCj4gPj4gZWFz ZSBOQVQgdHJhdmVyc2FsIGJ5IHJlZHVjaW5nIHRoZSBudW1iZXIgb2YgVURQIHBvcnRzLiBCeSB0 aGF0DQo+ID4+IGFyZ3VtZW50LCBzZW5kaW5nIEZFQyBkYXRhIG9uIHRoZSBzYW1lIHBvcnQgYXMg dGhlIG1lZGlhIGl0J3MNCj4gPj4gcHJvdGVjdGluZyBkb2Vzbid0IHNlZW0gcHJvYmxlbWF0aWMu IChJIHdvdWxkbid0IHdhbnQgdG8gc2VlDQo+ID4+IGRpZmZlcmVudA0KPiA+PiBtZWRpYSB0eXBl cyBvbiBvbmUgcG9ydCwgYnV0IHRoaXMgaXMgY2xvc2UgZW5vdWdoIHJlbGF0ZWQNCj4gPj4gdGhh dCBJIGRvbid0DQo+ID4+IHNlZSBhIGJpZyBpc3N1ZSkuDQo+ID4+DQo+ID4+PiBJIGFtIGFib3V0 IHRvIGZpbmFsaXplIHRoZSA0NzU2YmlzIGRyYWZ0IGFuZCBzbyBmYXIgbXkgYXNzdW1wdGlvbg0K PiA+Pj4gaGFzIGJlZW4gdGhhdCB3ZSB3b3VsZCBvbmx5IGRvIHNlc3Npb24gbXVsdGlwbGV4aW5n IGFuZCB1c2UNCj4gPj4+ICJhPWdyb3VwIiBmb3IgYXNzb2NpYXRpb25zLiBUaGlzIHdvdWxkIG5v dCB3b3JrIGZvciBTU1JDDQo+ID4+IG11bHRpcGxleGVkDQo+ID4+PiBzdHJlYW1zLCB0aG91Z2gu IEZvciB0aGF0LCB3ZSBjYW4gdXNlIHRoZSAiYT1zc3JjLWdyb3VwIiBhdHRyaWJ1dGUNCj4gPj4+ IGZyb20gSm9uYXRoYW4ncyBkcmFmdC4NCj4gPj4+DQo+ID4+Pj4gU1NSQyBtdWx0aXBsZXhpbmcg b2Ygc291cmNlIGFuZCByZXBhaXIgaXMgcG9zc2libGUgYW5kIHRoZQ0KPiA+Pj4+IGludGVudGlv biB3YXMgdG8gc3VwcG9ydCB0aGlzIGluIHRoZSBGcmFtZXdvcmssIGJ1dCBpZiBpdCBpcw0KPiA+ Pj4+IG5vdCByZXF1aXJlZCB3ZSBjb3VsZCBzaW1wbGlmeSBieSBzdXBwb3J0aW5nIG9ubHkgcG9y dA0KPiA+Pj4+IG11bHRpcGxleGluZy4gUG9ydCBtdWx0aXBsZXhpbmcgaXMgbW9yZSBzdHJhaWdo dGZvcndhcmRseQ0KPiA+Pj4+IGJhY2t3YXJkcy1jb21wYXRpYmxlIChJJ20gbm90IHN1cmUgd2hh dCBhbiBSVFAgcmVjZWl2ZXIgZG9lcw0KPiA+Pj4+IGlmIGl0IGlzIGV4cGVjdGluZyBqdXN0IG9u ZSBTU1JDIGFuZCBpdCBzZWVzIHR3bykuDQo+ID4+Pg0KPiA+Pj4gSWYgaXQgaGFzIGEgcGF5bG9h ZCB0aGF0IGl0IGRvZXMgbm90IHVuZGVyc3RhbmQsIGl0IHdpbGwNCj4gPj4gZGlzY2FyZCBpdC4N Cj4gPj4+IElmIGl0IHVuZGVyc3RhbmRzIGFuZCBrbm93cyB3aGF0IHRoZSBzdHJlYW0gaXMgZm9y LCBpdCB3b3VsZCBqdXN0DQo+ID4+PiB1c2UgaXQgYXMgaWYgdGhlIHN0cmVhbSB3YXMgcmVjZWl2 ZWQgZnJvbSBhIGRpZmZlcmVudCBwb3J0Lg0KPiA+Pj4NCj4gPj4+IEFyZSB0aGVyZSBhbnkgY29t bWVudHMvc3VnZ2VzdGlvbnMgZnJvbSBNTVVTSUM/DQo+ID4+Pg0KPiA+Pj4gLWFjYmVnZW4NCj4g Pj4+DQo+ID4+Pj4gLi4uTWFyaw0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiBPbiA0LzI0LzA5IDEw OjUzIEFNLCAiQWxpIEMuIEJlZ2VuIChhYmVnZW4pIiA8YWJlZ2VuQGNpc2NvLmNvbT4NCj4gPj4+ PiB3cm90ZToNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiAJTWFyaywgQWxsLA0KPiA+ Pj4+IAkNCj4gPj4+PiAJSSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQgbXVsdGlwbGV4aW5nIHRoZSBz b3VyY2UgYW5kDQo+ID4+Pj4gcmVwYWlyIHN0cmVhbXMgd2hlbiB0aGV5IGFyZSBib3RoIFJUUC4g Q3VycmVudGx5LCB3ZSBoYXZlIHRoZQ0KPiA+Pj4+IGZvbGxvd2luZyB0ZXh0Og0KPiA+Pj4+IAkN Cj4gPj4+PiAJKFN0YXJ0IG9mIHNlY3Rpb24gNCkNCj4gPj4+PiAJDQo+ID4+Pj4gCSAgIFRoZSBG RUMgRnJhbWV3b3JrIGlzIGRlc2NyaWJlZCBpbiB0ZXJtcyBvZiBhbg0KPiA+Pj4+IGFkZGl0aW9u YWwgbGF5ZXINCj4gPj4+PiAJICAgYmV0d2VlbiB0aGUgdHJhbnNwb3J0IGxheWVyIChlLmcuICBV RFAgb3IgRENDUCkgYW5kDQo+ID4+Pj4gcHJvdG9jb2xzIHJ1bm5pbmcNCj4gPj4+PiAJICAgb3Zl ciB0aGlzIHRyYW5zcG9ydCBsYXllci4gIEV4YW1wbGVzIG9mIHN1Y2gNCj4gPj4+PiBwcm90b2Nv bHMgYXJlIFJUUCwgUlRDUCwNCj4gPj4+PiAJICAgZXRjLiAgQXMgc3VjaCwgdGhlIGRhdGEgcGF0 aCBpbnRlcmZhY2UgYmV0d2VlbiB0aGUNCj4gPj4+PiBGRUMgRnJhbWV3b3JrIGFuZA0KPiA+Pj4+ IAkgICBib3RoIHVuZGVybHlpbmcgYW5kIG92ZXJseWluZyBsYXllcnMgY2FuIGJlIHRob3VnaHQN Cj4gPj4+PiBvZiBhcyBiZWluZyB0aGUNCj4gPj4+PiAJICAgc2FtZSBhcyB0aGUgc3RhbmRhcmQg aW50ZXJmYWNlIHRvIHRoZSB0cmFuc3BvcnQNCj4gPj4+PiBsYXllciAtIGkuZS4gdGhlIGRhdGEN Cj4gPj4+PiAJICAgZXhjaGFuZ2VkIGNvbnNpc3RzIG9mIGRhdGFncmFtIHBheWxvYWRzIGVhY2gN Cj4gPj4+PiBhc3NvY2lhdGVkIHdpdGggYSBzaW5nbGUNCj4gPj4+PiAJICAgdHJhbnNwb3J0IGZs b3cgaWRlbnRpZmllZCAoaW4gdGhlIGNhc2Ugb2YgVURQKSBieQ0KPiA+Pj4+IHRoZSBzdGFuZGFy ZA0KPiA+Pj4+IAkgICA1LXR1cGxlIHsgU291cmNlIElQIEFkZHJlc3MsIFNvdXJjZSBUcmFuc3Bv cnQgUG9ydCwNCj4gPj4+PiBEZXN0aW5hdGlvbiBJUA0KPiA+Pj4+IAkgICBBZGRyZXNzLCBEZXN0 aW5hdGlvbiBUcmFuc3BvcnQgUG9ydCwgVHJhbnNwb3J0DQo+ID4+Pj4gUHJvdG9jb2wgfS4gIElu IHRoZQ0KPiA+Pj4+IAkgICBjYXNlIHRoYXQgUlRQIGlzIHVzZWQgZm9yIHRoZSByZXBhaXIgZmxv d3MsIHRoZQ0KPiA+Pj4+IHNvdXJjZSBhbmQgcmVwYWlyDQo+ID4+Pj4gCSAgIGRhdGEgbWF5IGJl IG11bHRpcGxleGVkIHVzaW5nIFJUUCBvbnRvIGEgc2luZ2xlIFVEUA0KPiA+Pj4+IGZsb3cgYW5k IG11c3QNCj4gPj4+PiAJICAgY29uc2VxdWVudGx5IGJlIGRlbXVsdGlwbGV4ZWQgYXQgdGhlIHJl Y2VpdmVyLg0KPiA+Pj4+IFRoZXJlIGFyZSB2YXJpb3VzDQo+ID4+Pj4gCSAgIHdheXMgaW4gd2hp Y2ggdGhpcyBtdWx0aXBsZXhpbmcgY2FuIGJlIGRvbmUsIGZvcg0KPiA+Pj4+IGV4YW1wbGUgYXMg ZGVzY3JpYmVkDQo+ID4+Pj4gCSAgIGluIFtSRkM0NTg4XS4NCj4gPj4+PiAJDQo+ID4+Pj4gCQ0K PiA+Pj4+IAlSRkMgNDU4OCBtZW50aW9ucyB0d28gd2F5cyBvZiBtdWx0aXBsZXhpbmcgUlRQIHN0 cmVhbXMuDQo+ID4+Pj4gT25lIGlzIHNlc3Npb24gbXVsdGlwbGV4aW5nLCB3aGVyZSBzb3VyY2Ug YW5kIHJlcGFpciBSVFANCj4gPj4+PiBzdHJlYW1zIGFyZSBpbiBkaWZmZXJlbnQgUlRQIHNlc3Np b25zIChkaWZmZXJlbnQgZGVzdA0KPiA+Pj4+IGFkZHJlc3MvcG9ydCkuIEluIHRoaXMgY2FzZSwg SSBkb24ndCBoYXZlIGFueSBpc3N1ZXMsIHRoaXMNCj4gPj4+PiB3b3JrcyBiZWF1dGlmdWxseSB3 aXRoIHRoZSBmcmFtZXdvcmsuDQo+ID4+Pj4gCQ0KPiA+Pj4+IAlUaGUgb3RoZXIgb25lIGlzIFNT UkMgbXVsdGlwbGV4aW5nIHdoZXJlIHRoZSBzb3VyY2UgYW5kDQo+ID4+Pj4gcmVwYWlyIFJUUCBz dHJlYW1zIGhhdmUgZGlmZmVyZW50IFNTUkNzIGJ1dCBhcmUgdHJhbnNtaXR0ZWQNCj4gPj4+PiBp biB0aGUgc2FtZSBSVFAgc2Vzc2lvbiAod2hpY2ggaXMgYSBzaW5nbGUgVURQIGZsb3cpLiBJcyB0 aGUNCj4gPj4+PiB0ZXh0IGFib3ZlIHNheWluZyB0aGF0IHRoZSBmcmFtZXdvcmsgYWxzbyBzdXBw b3J0IHRoaXMga2luZA0KPiA+Pj4+IG9mIG11bHRpcGxleGluZz8gSW4gb3RoZXIgd29yZHMsIGlz IHVzaW5nIGEgc2luZ2xlIFVEUCBmbG93DQo+ID4+Pj4gdG8gY2Fycnkgc291cmNlICsgRkVDIGRh dGEgYWNjZXB0YWJsZSB3aGVuIHRoZXkgaGF2ZQ0KPiA+PiBzZXBhcmF0ZSBTU1JDcz8NCj4gPj4+ PiAJDQo+ID4+Pj4gCU5vdCB0aGF0IEZFQyBjb3VsZCBub3QgYmUgdXNlZCBpbiB0aGlzIHNjZW5h cmlvLCBidXQgYXMNCj4gPj4+PiBJIHJlY2FsbCB0aGUgZnJhbWV3b3JrIHJlcXVpcmVkIGRpZmZl cmVudCBVRFAgZmxvd3MgZm9yDQo+ID4+Pj4gc291cmNlIGFuZCByZXBhaXIgZmxvd3MuLi4NCj4g Pj4+PiAJDQo+ID4+Pj4gCUJSLA0KPiA+Pj4+IAktYWNiZWdlbg0KPiA+Pj4+IAkNCj4gPj4+PiAJ DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPj4+IEZlY2ZyYW1lIG1haWxpbmcgbGlzdA0KPiA+Pj4gRmVjZnJh bWVAaWV0Zi5vcmcNCj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZmVjZnJhbWUNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gLS0gDQo+ID4+IENvbGluIFBlcmtpbnMN Cj4gPj4gaHR0cDovL2NzcGVya2lucy5vcmcvDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBtbXVz aWMgbWFpbGluZyBsaXN0DQo+ID4gbW11c2ljQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCj4gDQo+IA0KPiANCj4gLS0gDQo+IENvbGlu IFBlcmtpbnMNCj4gaHR0cDovL2NzcGVya2lucy5vcmcvDQo+IA0KPiANCj4gDQo+IA0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5n IGxpc3QNCm1tdXNpY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tbXVzaWMNCg0K ------_=_NextPart_001_01C9C7D7.37D1C102 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2NTQuMTIiPg0KPFRJVExFPlJlOiBbTU1VU0lD XSBbRmVjZnJhbWVdIFJUUCBzdHJlYW0gbXVsdGlwbGV4aW5nIGluIHRoZSBmZWMgZnJhbWV3b3Jr PC9USVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KPCEtLSBDb252ZXJ0ZWQgZnJvbSB0ZXh0L3BsYWlu IGZvcm1hdCAtLT4NCg0KPFA+PEZPTlQgU0laRT0yPkdvb2QgcG9pbnQsIEkgYWdyZWUgd2l0aCB0 aGlzIGFzc2Vzc21lbnQuPEJSPg0KPEJSPg0KQlIsPEJSPg0KPEJSPg0KPEJSPg0KLWFjYmVnZW4g KEJiZXJyeSBjcmlwcGxlZCk8QlI+DQo8QlI+DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t PEJSPg0KRnJvbTogUm9uaSBFdmVuICZsdDtyb24uZXZlbi50bHZAZ21haWwuY29tJmd0OzxCUj4N ClRvOiBBbGkgQy4gQmVnZW4gKGFiZWdlbik7ICdDb2xpbiBQZXJraW5zJyAmbHQ7Y3NwQGNzcGVy a2lucy5vcmcmZ3Q7PEJSPg0KQ2M6ICdXYXRzb24sIE1hcmsnICZsdDt3YXRzb25AcXVhbGNvbW0u Y29tJmd0OzsgbW11c2ljQGlldGYub3JnICZsdDttbXVzaWNAaWV0Zi5vcmcmZ3Q7OyBmZWNmcmFt ZUBpZXRmLm9yZyAmbHQ7ZmVjZnJhbWVAaWV0Zi5vcmcmZ3Q7PEJSPg0KU2VudDogVHVlIEFwciAy OCAwMDowNTowNCAyMDA5PEJSPg0KU3ViamVjdDogUkU6IFtNTVVTSUNdIFtGZWNmcmFtZV0gUlRQ IHN0cmVhbSBtdWx0aXBsZXhpbmcgaW4gdGhlIGZlYyBmcmFtZXdvcms8QlI+DQo8QlI+DQpBbGks PEJSPg0KSSB0aGluayB0aGF0IGlmIHlvdSB3b3VsZCB3YW50IHRvIHVzZSBhPXNzcmMtZ3JvdXA6 ZmVjLXhyIGFsc28gZm9yIHNlc3Npb248QlI+DQptdWx0aXBsZXhpbmcgaXQgd2lsbCBiZSBhIHNl c3Npb24gbGV2ZWwgYXR0cmlidXRlIGR1cGxpY2F0aW5nIHRoZSBhPWdyb3VwPEJSPg0KYW5kIGhh dmluZyBwcm9ibGVtIHdpdGggU1NSQyBudW1iZXIgdW5pcXVlbmVzcyBhY3Jvc3MgUlRQIHNlc3Np b25zLiBJIHRoaW5rPEJSPg0KaXQgd2lsbCBiZSBiZXN0IHRvIGhhdmUgdGhlIGE9c3NyYy1ncm91 cCBhcyBhIG1lZGlhIGxldmVsIGF0dHJpYnV0ZSBvbmx5PEJSPg0KUm9uaTxCUj4NCjxCUj4NCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPg0KRnJvbTogbW11c2ljLWJvdW5jZXNAaWV0Zi5v cmcgWzxBIEhSRUY9Im1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm1tdXNp Yy1ib3VuY2VzQGlldGYub3JnPC9BPl0gT24gQmVoYWxmIE9mPEJSPg0KQWxpIEMuIEJlZ2VuIChh YmVnZW4pPEJSPg0KU2VudDogVHVlc2RheSwgQXByaWwgMjgsIDIwMDkgMjowMCBBTTxCUj4NClRv OiBDb2xpbiBQZXJraW5zPEJSPg0KQ2M6IFdhdHNvbiwgTWFyazsgbW11c2ljQGlldGYub3JnOyBm ZWNmcmFtZUBpZXRmLm9yZzxCUj4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBbRmVjZnJhbWVdIFJU UCBzdHJlYW0gbXVsdGlwbGV4aW5nIGluIHRoZSBmZWM8QlI+DQpmcmFtZXdvcms8QlI+DQo8QlI+ DQpBbHJpZ2h0LCBsb29rcyBsaWtlIHdlIG5lZWQgdG8gaGF2ZSBTU1JDIG11bHRpcGxleGluZyBm b3IgRkVDLCBhbmQgdGh1cywgd2U8QlI+DQpuZWVkIGdyb3VwaW5nIHN1cHBvcnQgZm9yIGl0IChh PXNzcmMtZ3JvdXApLiBJJ2xsIHJldmlzZSB0aGUgNDc1NmJpcyBhbmQ8QlI+DQpzdWJtaXQgYSBu ZXcgdmVyc2lvbiBmb3IgcmV2aWV3LjxCUj4NCjxCUj4NCk9uZSBtb3JlIHF1ZXN0aW9uLCB0aG91 Z2guIFNob3VsZCB3ZSBhbGxvdyBmb3IgJnF1b3Q7YT1zc3JjLWdyb3VwOkZFQy1YUiZxdW90OzxC Uj4NCnNlbWFudGljcyBvbmx5IGlmIFNTUkMgbXVsdGlwbGV4aW5nIGlzIHVzZWQgYW5kIG1hbmRh dGUgJnF1b3Q7YT1ncm91cDpGRUMtWFImcXVvdDs8QlI+DQpzZW1hbnRpY3MgZm9yIGV2ZXJ5dGhp bmcgZWxzZSAoZm9yIG5vbi1SVFAgZmxvd3MgYW5kIHdoZW4gc2Vzc2lvbjxCUj4NCm11bHRpcGxl eGluZyBpcyB1c2VkKT8gT3IsIHNob3VsZCB3ZSBhbHNvIGFsbG93ICZxdW90O2E9c3NyYy1ncm91 cDpGRUMtWFImcXVvdDs8QlI+DQpzZW1hbnRpY3MgZm9yIHNlc3Npb24gbXVsdGlwbGV4aW5nIGFz IHdlbGw/PEJSPg0KPEJSPg0KLWFjYmVnZW48QlI+DQo8QlI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPEJSPg0KJmd0OyBGcm9tOiBDb2xpbiBQZXJraW5zIFs8QSBIUkVGPSJtYWls dG86Y3NwQGNzcGVya2lucy5vcmciPm1haWx0bzpjc3BAY3NwZXJraW5zLm9yZzwvQT5dPEJSPg0K Jmd0OyBTZW50OiBNb25kYXksIEFwcmlsIDI3LCAyMDA5IDI6MDIgUE08QlI+DQomZ3Q7IFRvOiBB bGkgQy4gQmVnZW4gKGFiZWdlbik8QlI+DQomZ3Q7IENjOiBXYXRzb24sIE1hcms7IG1tdXNpY0Bp ZXRmLm9yZzsgZmVjZnJhbWVAaWV0Zi5vcmc8QlI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbTU1VU0lD XSBbRmVjZnJhbWVdIFJUUCBzdHJlYW0gbXVsdGlwbGV4aW5nIGluPEJSPg0KJmd0OyB0aGUgZmVj IGZyYW1ld29yazxCUj4NCiZndDs8QlI+DQomZ3Q7IFllcywgZm9yIHRoZSBwdXJwb3NlcyBmb3Ig Z3JvdXBpbmcgRkVDIGFuZCB0aGUgb3JpZ2luYWwgbWVkaWEsIGluJm5ic3A7PEJSPg0KJmd0OyBj YXNlcyB3aGVyZSB5b3UncmUgdHJ5aW5nIHRvIHJlZHVjZSBwb3J0IHVzYWdlLjxCUj4NCiZndDs8 QlI+DQomZ3Q7IENvbGluPEJSPg0KJmd0OzxCUj4NCiZndDs8QlI+DQomZ3Q7PEJSPg0KJmd0OyBP biAyNyBBcHIgMjAwOSwgYXQgMjA6MDAsIEFsaSBDLiBCZWdlbiAoYWJlZ2VuKSB3cm90ZTo8QlI+ DQomZ3Q7ICZndDsgSXMgdGhhdCBhICZxdW90O3llcyZxdW90OyBmb3Igc3NyYy1sZXZlbCBncm91 cGluZyBmb3IgRkVDPzxCUj4NCiZndDsgJmd0OzxCUj4NCiZndDsgJmd0OyAtYWNiZWdlbjxCUj4N CiZndDsgJmd0OzxCUj4NCiZndDsgJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 QlI+DQomZ3Q7ICZndDsmZ3Q7IEZyb206IENvbGluIFBlcmtpbnMgWzxBIEhSRUY9Im1haWx0bzpj c3BAY3NwZXJraW5zLm9yZyI+bWFpbHRvOmNzcEBjc3BlcmtpbnMub3JnPC9BPl08QlI+DQomZ3Q7 ICZndDsmZ3Q7IFNlbnQ6IE1vbmRheSwgQXByaWwgMjcsIDIwMDkgMTA6NTQgQU08QlI+DQomZ3Q7 ICZndDsmZ3Q7IFRvOiBBbGkgQy4gQmVnZW4gKGFiZWdlbik8QlI+DQomZ3Q7ICZndDsmZ3Q7IENj OiBXYXRzb24sIE1hcms7IGZlY2ZyYW1lQGlldGYub3JnOyBtbXVzaWNAaWV0Zi5vcmc8QlI+DQom Z3Q7ICZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbRmVjZnJhbWVdIFJUUCBzdHJlYW0gbXVsdGlwbGV4 aW5nIGluIHRoZSBmZWM8QlI+DQomZ3Q7IGZyYW1ld29yazxCUj4NCiZndDsgJmd0OyZndDs8QlI+ DQomZ3Q7ICZndDsmZ3Q7IE9uIDI0IEFwciAyMDA5LCBhdCAxOToxMywgQWxpIEMuIEJlZ2VuIChh YmVnZW4pIHdyb3RlOjxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7IENvcHlpbmcgTU1VU0lDIGFzIHRo aXMgaXMgcmVsZXZhbnQgdG86PEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8QlI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OzxCUj4NCiZndDsgJmd0OyZndDsgPEEgSFJFRj0iaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNvdXIiPmh0dHA6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1zb3VyPC9BPjxCUj4N CiZndDsgJmd0OyBjZS1hdHRyaWJ1dGVzLTAyLnR4dDxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7IDxB IEhSRUY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbW11 c2ljLSI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tbXVz aWMtPC9BPjxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7IHJmYzQ3NTZiaXMtMDEudHh0PEJSPg0KJmd0 OyAmZ3Q7Jmd0OyZndDs8QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS08QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgRnJvbTogV2F0c29uLCBNYXJr IFs8QSBIUkVGPSJtYWlsdG86d2F0c29uQHF1YWxjb21tLmNvbSI+bWFpbHRvOndhdHNvbkBxdWFs Y29tbS5jb208L0E+XTxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBTZW50OiBGcmlkYXksIEFw cmlsIDI0LCAyMDA5IDExOjAyIEFNPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFRvOiBBbGkg Qy4gQmVnZW4gKGFiZWdlbik7IGZlY2ZyYW1lQGlldGYub3JnPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IFN1YmplY3Q6IFJlOiBSVFAgc3RyZWFtIG11bHRpcGxleGluZyBpbiB0aGUgZmVjIGZy YW1ld29yazxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyBBbGksPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IFdoYXQgZG8geW91IHRoaW5rIHRoZSBGcmFtZXdvcmsgc2hvdWxkIGRvID88QlI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7IElNTywgd2Ugc2hvdWxkIG5v dCByZXN0cmljdCBGRUMgdG8gd29yayBvbmx5IGZvciBzZXNzaW9uPEJSPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsgbXVsdGlwbGV4aW5nIChhbHRob3VnaCBJIGFncmVlIHdpdGggeW91IHRoYXQgZG9pbmcg c28gaGFzIG1hbnk8QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBhZHZhbnRhZ2VzKS48QlI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7IEkgc2VlIGEgZmV3IGtleSByZWFz b25zIHdoeSBwZW9wbGUgd291bGQgdXNlIFNTUkM8QlI+DQomZ3Q7ICZndDsmZ3Q7IG11bHRpcGxl eGluZywgb25lPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgYmVpbmcgdG8gc2ltcGxpZnkgdGhlIHBv cnQgb3BlcmF0aW9ucyBvbiBOQVQgdHJhdmVyc2FsLiBPbmU8QlI+DQomZ3Q7ICZndDsmZ3Q7IHNl c3Npb248QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBtZWFucyBvbmUgaG9sZSBvbiBOQVQgZm9yIHRo ZSBSVFAgdHJhbnNwb3J0IChydGNwIHBvcnQgY2FuIGJlIHRoZTxCUj4NCiZndDsgJmd0OyZndDsm Z3Q7IHNhbWUgb3IgZGlmZmVyZW50KS4gU28sIHNvbWUgYXBwcyBtYXkgdXNlIHNzcmMgbXVsdGlw bGV4aW5nLjxCUj4NCiZndDsgJmd0OyZndDs8QlI+DQomZ3Q7ICZndDsmZ3Q7IFRoZSB0cmVuZCBp cyBjbGVhcmx5IHRvd2FyZHMgYWxsb3dpbmcgbXVsdGlwbGV4aW5nIGJ5IFJUUCBTU1JDLCB0bzxC Uj4NCiZndDsgJmd0OyZndDsgZWFzZSBOQVQgdHJhdmVyc2FsIGJ5IHJlZHVjaW5nIHRoZSBudW1i ZXIgb2YgVURQIHBvcnRzLiBCeSB0aGF0PEJSPg0KJmd0OyAmZ3Q7Jmd0OyBhcmd1bWVudCwgc2Vu ZGluZyBGRUMgZGF0YSBvbiB0aGUgc2FtZSBwb3J0IGFzIHRoZSBtZWRpYSBpdCdzPEJSPg0KJmd0 OyAmZ3Q7Jmd0OyBwcm90ZWN0aW5nIGRvZXNuJ3Qgc2VlbSBwcm9ibGVtYXRpYy4gKEkgd291bGRu J3Qgd2FudCB0byBzZWU8QlI+DQomZ3Q7ICZndDsmZ3Q7IGRpZmZlcmVudDxCUj4NCiZndDsgJmd0 OyZndDsgbWVkaWEgdHlwZXMgb24gb25lIHBvcnQsIGJ1dCB0aGlzIGlzIGNsb3NlIGVub3VnaCBy ZWxhdGVkPEJSPg0KJmd0OyAmZ3Q7Jmd0OyB0aGF0IEkgZG9uJ3Q8QlI+DQomZ3Q7ICZndDsmZ3Q7 IHNlZSBhIGJpZyBpc3N1ZSkuPEJSPg0KJmd0OyAmZ3Q7Jmd0OzxCUj4NCiZndDsgJmd0OyZndDsm Z3Q7IEkgYW0gYWJvdXQgdG8gZmluYWxpemUgdGhlIDQ3NTZiaXMgZHJhZnQgYW5kIHNvIGZhciBt eSBhc3N1bXB0aW9uPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgaGFzIGJlZW4gdGhhdCB3ZSB3b3Vs ZCBvbmx5IGRvIHNlc3Npb24gbXVsdGlwbGV4aW5nIGFuZCB1c2U8QlI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyAmcXVvdDthPWdyb3VwJnF1b3Q7IGZvciBhc3NvY2lhdGlvbnMuIFRoaXMgd291bGQgbm90 IHdvcmsgZm9yIFNTUkM8QlI+DQomZ3Q7ICZndDsmZ3Q7IG11bHRpcGxleGVkPEJSPg0KJmd0OyAm Z3Q7Jmd0OyZndDsgc3RyZWFtcywgdGhvdWdoLiBGb3IgdGhhdCwgd2UgY2FuIHVzZSB0aGUgJnF1 b3Q7YT1zc3JjLWdyb3VwJnF1b3Q7IGF0dHJpYnV0ZTxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7IGZy b20gSm9uYXRoYW4ncyBkcmFmdC48QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyBTU1JDIG11bHRpcGxleGluZyBvZiBzb3VyY2UgYW5kIHJlcGFpciBpcyBw b3NzaWJsZSBhbmQgdGhlPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGludGVudGlvbiB3YXMg dG8gc3VwcG9ydCB0aGlzIGluIHRoZSBGcmFtZXdvcmssIGJ1dCBpZiBpdCBpczxCUj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyBub3QgcmVxdWlyZWQgd2UgY291bGQgc2ltcGxpZnkgYnkgc3VwcG9y dGluZyBvbmx5IHBvcnQ8QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgbXVsdGlwbGV4aW5nLiBQ b3J0IG11bHRpcGxleGluZyBpcyBtb3JlIHN0cmFpZ2h0Zm9yd2FyZGx5PEJSPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7IGJhY2t3YXJkcy1jb21wYXRpYmxlIChJJ20gbm90IHN1cmUgd2hhdCBhbiBS VFAgcmVjZWl2ZXIgZG9lczxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBpZiBpdCBpcyBleHBl Y3RpbmcganVzdCBvbmUgU1NSQyBhbmQgaXQgc2VlcyB0d28pLjxCUj4NCiZndDsgJmd0OyZndDsm Z3Q7PEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgSWYgaXQgaGFzIGEgcGF5bG9hZCB0aGF0IGl0IGRv ZXMgbm90IHVuZGVyc3RhbmQsIGl0IHdpbGw8QlI+DQomZ3Q7ICZndDsmZ3Q7IGRpc2NhcmQgaXQu PEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgSWYgaXQgdW5kZXJzdGFuZHMgYW5kIGtub3dzIHdoYXQg dGhlIHN0cmVhbSBpcyBmb3IsIGl0IHdvdWxkIGp1c3Q8QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyB1 c2UgaXQgYXMgaWYgdGhlIHN0cmVhbSB3YXMgcmVjZWl2ZWQgZnJvbSBhIGRpZmZlcmVudCBwb3J0 LjxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgQXJlIHRoZXJl IGFueSBjb21tZW50cy9zdWdnZXN0aW9ucyBmcm9tIE1NVVNJQz88QlI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7IC1hY2JlZ2VuPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZn dDs8QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgLi4uTWFyazxCUj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyBPbiA0LzI0LzA5IDEwOjUzIEFNLCAmcXVvdDtBbGkgQy4gQmVnZW4gKGFiZWdlbikmcXVv dDsgJmx0O2FiZWdlbkBjaXNjby5jb20mZ3Q7PEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHdy b3RlOjxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyBNYXJrLCBBbGwsPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PEJSPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IEkgaGF2ZSBhIHF1ZXN0aW9uIGFib3V0IG11bHRpcGxl eGluZyB0aGUgc291cmNlIGFuZDxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyByZXBhaXIgc3Ry ZWFtcyB3aGVuIHRoZXkgYXJlIGJvdGggUlRQLiBDdXJyZW50bHksIHdlIGhhdmUgdGhlPEJSPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGZvbGxvd2luZyB0ZXh0OjxCUj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAoU3RhcnQgb2Yg c2VjdGlvbiA0KTxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxCUj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgVGhlIEZFQyBGcmFtZXdvcmsgaXMgZGVz Y3JpYmVkIGluIHRlcm1zIG9mIGFuPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGFkZGl0aW9u YWwgbGF5ZXI8QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IGJl dHdlZW4gdGhlIHRyYW5zcG9ydCBsYXllciAoZS5nLiZuYnNwOyBVRFAgb3IgRENDUCkgYW5kPEJS Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHByb3RvY29scyBydW5uaW5nPEJSPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBvdmVyIHRoaXMgdHJhbnNwb3J0IGxheWVy LiZuYnNwOyBFeGFtcGxlcyBvZiBzdWNoPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHByb3Rv Y29scyBhcmUgUlRQLCBSVENQLDxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJz cDsmbmJzcDsgZXRjLiZuYnNwOyBBcyBzdWNoLCB0aGUgZGF0YSBwYXRoIGludGVyZmFjZSBiZXR3 ZWVuIHRoZTxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBGRUMgRnJhbWV3b3JrIGFuZDxCUj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgYm90aCB1bmRlcmx5aW5n IGFuZCBvdmVybHlpbmcgbGF5ZXJzIGNhbiBiZSB0aG91Z2h0PEJSPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IG9mIGFzIGJlaW5nIHRoZTxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAm bmJzcDsmbmJzcDsgc2FtZSBhcyB0aGUgc3RhbmRhcmQgaW50ZXJmYWNlIHRvIHRoZSB0cmFuc3Bv cnQ8QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgbGF5ZXIgLSBpLmUuIHRoZSBkYXRhPEJSPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBleGNoYW5nZWQgY29uc2lz dHMgb2YgZGF0YWdyYW0gcGF5bG9hZHMgZWFjaDxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBh c3NvY2lhdGVkIHdpdGggYSBzaW5nbGU8QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsg Jm5ic3A7Jm5ic3A7IHRyYW5zcG9ydCBmbG93IGlkZW50aWZpZWQgKGluIHRoZSBjYXNlIG9mIFVE UCkgYnk8QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgdGhlIHN0YW5kYXJkPEJSPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyA1LXR1cGxlIHsgU291cmNlIElQIEFk ZHJlc3MsIFNvdXJjZSBUcmFuc3BvcnQgUG9ydCw8QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg RGVzdGluYXRpb24gSVA8QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7Jm5i c3A7IEFkZHJlc3MsIERlc3RpbmF0aW9uIFRyYW5zcG9ydCBQb3J0LCBUcmFuc3BvcnQ8QlI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgUHJvdG9jb2wgfS4mbmJzcDsgSW4gdGhlPEJSPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBjYXNlIHRoYXQgUlRQIGlzIHVzZWQg Zm9yIHRoZSByZXBhaXIgZmxvd3MsIHRoZTxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBzb3Vy Y2UgYW5kIHJlcGFpcjxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsmbmJz cDsgZGF0YSBtYXkgYmUgbXVsdGlwbGV4ZWQgdXNpbmcgUlRQIG9udG8gYSBzaW5nbGUgVURQPEJS Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGZsb3cgYW5kIG11c3Q8QlI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IGNvbnNlcXVlbnRseSBiZSBkZW11bHRpcGxleGVk IGF0IHRoZSByZWNlaXZlci48QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgVGhlcmUgYXJlIHZh cmlvdXM8QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IHdheXMg aW4gd2hpY2ggdGhpcyBtdWx0aXBsZXhpbmcgY2FuIGJlIGRvbmUsIGZvcjxCUj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyBleGFtcGxlIGFzIGRlc2NyaWJlZDxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgaW4gW1JGQzQ1ODhdLjxCUj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxCUj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyBSRkMgNDU4OCBtZW50aW9ucyB0d28gd2F5cyBvZiBtdWx0 aXBsZXhpbmcgUlRQIHN0cmVhbXMuPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IE9uZSBpcyBz ZXNzaW9uIG11bHRpcGxleGluZywgd2hlcmUgc291cmNlIGFuZCByZXBhaXIgUlRQPEJSPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHN0cmVhbXMgYXJlIGluIGRpZmZlcmVudCBSVFAgc2Vzc2lvbnMg KGRpZmZlcmVudCBkZXN0PEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGFkZHJlc3MvcG9ydCku IEluIHRoaXMgY2FzZSwgSSBkb24ndCBoYXZlIGFueSBpc3N1ZXMsIHRoaXM8QlI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgd29ya3MgYmVhdXRpZnVsbHkgd2l0aCB0aGUgZnJhbWV3b3JrLjxCUj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyBUaGUgb3RoZXIgb25lIGlzIFNTUkMgbXVsdGlwbGV4aW5nIHdoZXJlIHRoZSBzb3VyY2Ug YW5kPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHJlcGFpciBSVFAgc3RyZWFtcyBoYXZlIGRp ZmZlcmVudCBTU1JDcyBidXQgYXJlIHRyYW5zbWl0dGVkPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IGluIHRoZSBzYW1lIFJUUCBzZXNzaW9uICh3aGljaCBpcyBhIHNpbmdsZSBVRFAgZmxvdyku IElzIHRoZTxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyB0ZXh0IGFib3ZlIHNheWluZyB0aGF0 IHRoZSBmcmFtZXdvcmsgYWxzbyBzdXBwb3J0IHRoaXMga2luZDxCUj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyBvZiBtdWx0aXBsZXhpbmc/IEluIG90aGVyIHdvcmRzLCBpcyB1c2luZyBhIHNpbmds ZSBVRFAgZmxvdzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyB0byBjYXJyeSBzb3VyY2UgKyBG RUMgZGF0YSBhY2NlcHRhYmxlIHdoZW4gdGhleSBoYXZlPEJSPg0KJmd0OyAmZ3Q7Jmd0OyBzZXBh cmF0ZSBTU1JDcz88QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8QlI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsgTm90IHRoYXQgRkVDIGNvdWxkIG5vdCBiZSB1c2VkIGluIHRo aXMgc2NlbmFyaW8sIGJ1dCBhczxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBJIHJlY2FsbCB0 aGUgZnJhbWV3b3JrIHJlcXVpcmVkIGRpZmZlcmVudCBVRFAgZmxvd3MgZm9yPEJSPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7IHNvdXJjZSBhbmQgcmVwYWlyIGZsb3dzLi4uPEJSPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7PEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IEJSLDxC Uj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAtYWNiZWdlbjxCUj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwOzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxCUj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsg Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgRmVjZnJhbWUgbWFpbGluZyBsaXN0PEJSPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsgRmVjZnJhbWVAaWV0Zi5vcmc8QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyA8 QSBIUkVGPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZlY2ZyYW1lIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZlY2ZyYW1lPC9BPjxCUj4NCiZn dDsgJmd0OyZndDs8QlI+DQomZ3Q7ICZndDsmZ3Q7PEJSPg0KJmd0OyAmZ3Q7Jmd0OzxCUj4NCiZn dDsgJmd0OyZndDsgLS08QlI+DQomZ3Q7ICZndDsmZ3Q7IENvbGluIFBlcmtpbnM8QlI+DQomZ3Q7 ICZndDsmZ3Q7IDxBIEhSRUY9Imh0dHA6Ly9jc3BlcmtpbnMub3JnLyI+aHR0cDovL2NzcGVya2lu cy5vcmcvPC9BPjxCUj4NCiZndDsgJmd0OyZndDs8QlI+DQomZ3Q7ICZndDsmZ3Q7PEJSPg0KJmd0 OyAmZ3Q7Jmd0OzxCUj4NCiZndDsgJmd0OyZndDs8QlI+DQomZ3Q7ICZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+DQomZ3Q7ICZndDsgbW11c2lj IG1haWxpbmcgbGlzdDxCUj4NCiZndDsgJmd0OyBtbXVzaWNAaWV0Zi5vcmc8QlI+DQomZ3Q7ICZn dDsgPEEgSFJFRj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9BPjxCUj4NCiZn dDs8QlI+DQomZ3Q7PEJSPg0KJmd0OzxCUj4NCiZndDsgLS08QlI+DQomZ3Q7IENvbGluIFBlcmtp bnM8QlI+DQomZ3Q7IDxBIEhSRUY9Imh0dHA6Ly9jc3BlcmtpbnMub3JnLyI+aHR0cDovL2NzcGVy a2lucy5vcmcvPC9BPjxCUj4NCiZndDs8QlI+DQomZ3Q7PEJSPg0KJmd0OzxCUj4NCiZndDs8QlI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4NCm1t dXNpYyBtYWlsaW5nIGxpc3Q8QlI+DQptbXVzaWNAaWV0Zi5vcmc8QlI+DQo8QSBIUkVGPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYyI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWM8L0E+PEJSPg0KPEJSPg0KPC9GT05UPg0KPC9Q Pg0KDQo8L0JPRFk+DQo8L0hUTUw+ ------_=_NextPart_001_01C9C7D7.37D1C102-- From tme@multicasttech.com Tue Apr 28 02:11:56 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AAD63A6924; Tue, 28 Apr 2009 02:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.942 X-Spam-Level: X-Spam-Status: No, score=-102.942 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 xBZRsCYRALEW; Tue, 28 Apr 2009 02:11:55 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 00BE63A6910; Tue, 28 Apr 2009 02:11:55 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 170FE3AFAB2D; Tue, 28 Apr 2009 05:13:14 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Colin Perkins In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 28 Apr 2009 05:13:13 -0400 References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> <8F9DD728-5AE9-4394-9BDD-4EDBFB92E4A5@csperkins.org> <2FA6A311-8B9F-41FF-B9A3-04EB1E399732@americafree.tv> X-Mailer: Apple Mail (2.930.3) Cc: mmusic@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] RTP stream multiplexing in the fec framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 09:11:56 -0000 On Apr 27, 2009, at 6:09 PM, Colin Perkins wrote: > On 27 Apr 2009, at 22:23, Marshall Eubanks wrote: >> On Apr 27, 2009, at 4:52 PM, Colin Perkins wrote: >>> On 27 Apr 2009, at 20:02, Marshall Eubanks wrote: >>>> On Apr 27, 2009, at 1:53 PM, Colin Perkins wrote: >>>>> On 24 Apr 2009, at 19:13, Ali C. Begen (abegen) wrote: >>> ... >>>> >>>>>> IMO, we should not restrict FEC to work only for session >>>>>> multiplexing (although I agree with you that doing so has many >>>>>> advantages). >>>>>> >>>>>> I see a few key reasons why people would use SSRC multiplexing, >>>>>> one being to simplify the port operations on NAT traversal. One >>>>>> session means one hole on NAT for the RTP transport (rtcp port >>>>>> can be the same or different). So, some apps may use ssrc >>>>>> multiplexing. >>>>> >>>>> The trend is clearly towards allowing multiplexing by RTP SSRC, >>>>> to ease NAT traversal by reducing the number of UDP ports. By >>>>> that argument, sending FEC data on the same port as the media >>>>> it's protecting doesn't seem problematic. (I wouldn't want to >>>>> see different media types on one port, but this is close enough >>>>> related that I don't see a big issue). >>>> >>>> If someone wanted to use SSRC multiplexing in a audio or video >>>> conference with multiplexing (audio) or multiple displays >>>> (video), and then wanted to apply SSRC multiplexed FEC to that >>>> (say for sources on lossy wireless links), isn't there a danger >>>> that non-FEC aware receivers would not do the right thing with >>>> the FEC ? >>> >>> >>> I don't think so. Non-FEC aware receivers would see an unknown >>> payload type, which they should ignore. What's your specific >>> concern with that scenario? >> >> I am trying to understand all of the worries expressed here >> >> >> Separate audio and video streams SHOULD NOT be carried in a single >> RTP session and demultiplexed based on the payload type or SSRC >> fields. Interleaving packets with different RTP media types but >> using the same SSRC would introduce several problems: >> >> Using a different SSRC for each medium but sending them in the same >> RTP session would avoid the first three problems but not the last two >> >> >> So, to be clear, what is proposed is to send the FEC repair stream >> with one source address and port, but a different SSRC and payload >> type (from the original stream) ? > > As I understand it, this is being proposed as one option for sending > FEC data (with the ability to send the FEC on a separate port as the > other option). In terms of the last two points in section 5.2 of RFC > 3550, an RTP mixer that understands FEC can make use of the FEC data > when mixing (and if it doesn't understand the FEC, the quality is > degraded, but the mixer still works); and the only reason to use > SSRC multiplexing here is specifically to use the same network path > for the FEC and media, making the last point moot. > OK, this works for me if this aligns with Ali's thinking. Marshall > -- > Colin Perkins > http://csperkins.org/ > > > > From jonathan@vidyo.com Tue Apr 28 07:19:27 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2F773A70C8; Tue, 28 Apr 2009 07:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 v1F4-nAIWF87; Tue, 28 Apr 2009 07:19:26 -0700 (PDT) Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by core3.amsl.com (Postfix) with ESMTP id 748E23A684E; Tue, 28 Apr 2009 07:19:26 -0700 (PDT) Received: from be150.mail.lan ([10.110.20.150]) by mx1.myoutlookonline.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 10:20:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Apr 2009 10:19:35 -0400 Message-ID: <6B55710E7F51AD4B93F336052113B85F8C7899@be150.mail.lan> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C88A0@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] [Fecframe] RTP stream multiplexing in the fec framework Thread-Index: AcnHe3o2t9udAcKdTMOM0tgu2HypagAD0DegACBgO0A= References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com><04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com><8F9DD728-5AE9-4394-9BDD-4EDBFB92E4A5@csperkins.org><04CAD96D4C5A3D48B1919248A8FE0D54092C86BE@xmb-sjc-215.amer.cisco.com><7D1B0D8B-BCFE-463B-B2F4-E627729A198D@csperkins.org> <04CAD96D4C5A3D48B1919248A8FE0D54092C88A0@xmb-sjc-215.amer.cisco.com> From: "Jonathan Lennox" To: "Ali C. Begen (abegen)" , "Colin Perkins" X-OriginalArrivalTime: 28 Apr 2009 14:20:47.0277 (UTC) FILETIME=[86290DD0:01C9C80C] X-Mailman-Approved-At: Tue, 28 Apr 2009 08:12:33 -0700 Cc: mmusic@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] [MMUSIC] RTP stream multiplexing in the fec framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 14:19:28 -0000 In the source-attributes draft, ssrc-group: semantics are only defined within a given RTP session. To associate multiple RTP sessions sessions you need to use group: semantics instead. So, yes, the former. --=20 Jonathan Lennox Vidyo, Inc jonathan@vidyo.com > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Monday, April 27, 2009 7:00 PM > To: Colin Perkins > Cc: Watson, Mark; mmusic@ietf.org; fecframe@ietf.org > Subject: Re: [MMUSIC] [Fecframe] RTP stream multiplexing in the fec > framework >=20 > Alright, looks like we need to have SSRC multiplexing for FEC, and > thus, we need grouping support for it (a=3Dssrc-group). I'll revise = the > 4756bis and submit a new version for review. >=20 > One more question, though. Should we allow for "a=3Dssrc-group:FEC-XR" > semantics only if SSRC multiplexing is used and mandate = "a=3Dgroup:FEC- > XR" semantics for everything else (for non-RTP flows and when session > multiplexing is used)? Or, should we also allow = "a=3Dssrc-group:FEC-XR" > semantics for session multiplexing as well? >=20 > -acbegen >=20 > > -----Original Message----- > > From: Colin Perkins [mailto:csp@csperkins.org] > > Sent: Monday, April 27, 2009 2:02 PM > > To: Ali C. Begen (abegen) > > Cc: Watson, Mark; mmusic@ietf.org; fecframe@ietf.org > > Subject: Re: [MMUSIC] [Fecframe] RTP stream multiplexing in > > the fec framework > > > > Yes, for the purposes for grouping FEC and the original media, in > > cases where you're trying to reduce port usage. > > > > Colin > > > > > > > > On 27 Apr 2009, at 20:00, Ali C. Begen (abegen) wrote: > > > Is that a "yes" for ssrc-level grouping for FEC? > > > > > > -acbegen > > > > > >> -----Original Message----- > > >> From: Colin Perkins [mailto:csp@csperkins.org] > > >> Sent: Monday, April 27, 2009 10:54 AM > > >> To: Ali C. Begen (abegen) > > >> Cc: Watson, Mark; fecframe@ietf.org; mmusic@ietf.org > > >> Subject: Re: [Fecframe] RTP stream multiplexing in the fec > > framework > > >> > > >> On 24 Apr 2009, at 19:13, Ali C. Begen (abegen) wrote: > > >>> Copying MMUSIC as this is relevant to: > > >>> > > >>> > > >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-sour > > > ce-attributes-02.txt > > >>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic- > > >>> rfc4756bis-01.txt > > >>> > > >>>> -----Original Message----- > > >>>> From: Watson, Mark [mailto:watson@qualcomm.com] > > >>>> Sent: Friday, April 24, 2009 11:02 AM > > >>>> To: Ali C. Begen (abegen); fecframe@ietf.org > > >>>> Subject: Re: RTP stream multiplexing in the fec framework > > >>>> > > >>>> Ali, > > >>>> > > >>>> What do you think the Framework should do ? > > >>> > > >>> IMO, we should not restrict FEC to work only for session > > >>> multiplexing (although I agree with you that doing so has many > > >>> advantages). > > >>> > > >>> I see a few key reasons why people would use SSRC > > >> multiplexing, one > > >>> being to simplify the port operations on NAT traversal. One > > >> session > > >>> means one hole on NAT for the RTP transport (rtcp port can be the > > >>> same or different). So, some apps may use ssrc multiplexing. > > >> > > >> The trend is clearly towards allowing multiplexing by RTP SSRC, to > > >> ease NAT traversal by reducing the number of UDP ports. By that > > >> argument, sending FEC data on the same port as the media it's > > >> protecting doesn't seem problematic. (I wouldn't want to see > > >> different > > >> media types on one port, but this is close enough related > > >> that I don't > > >> see a big issue). > > >> > > >>> I am about to finalize the 4756bis draft and so far my assumption > > >>> has been that we would only do session multiplexing and use > > >>> "a=3Dgroup" for associations. This would not work for SSRC > > >> multiplexed > > >>> streams, though. For that, we can use the "a=3Dssrc-group" > attribute > > >>> from Jonathan's draft. > > >>> > > >>>> SSRC multiplexing of source and repair is possible and the > > >>>> intention was to support this in the Framework, but if it is > > >>>> not required we could simplify by supporting only port > > >>>> multiplexing. Port multiplexing is more straightforwardly > > >>>> backwards-compatible (I'm not sure what an RTP receiver does > > >>>> if it is expecting just one SSRC and it sees two). > > >>> > > >>> If it has a payload that it does not understand, it will > > >> discard it. > > >>> If it understands and knows what the stream is for, it would just > > >>> use it as if the stream was received from a different port. > > >>> > > >>> Are there any comments/suggestions from MMUSIC? > > >>> > > >>> -acbegen > > >>> > > >>>> ...Mark > > >>>> > > >>>> > > >>>> On 4/24/09 10:53 AM, "Ali C. Begen (abegen)" > > >>>> wrote: > > >>>> > > >>>> > > >>>> > > >>>> Mark, All, > > >>>> > > >>>> I have a question about multiplexing the source and > > >>>> repair streams when they are both RTP. Currently, we have the > > >>>> following text: > > >>>> > > >>>> (Start of section 4) > > >>>> > > >>>> The FEC Framework is described in terms of an > > >>>> additional layer > > >>>> between the transport layer (e.g. UDP or DCCP) and > > >>>> protocols running > > >>>> over this transport layer. Examples of such > > >>>> protocols are RTP, RTCP, > > >>>> etc. As such, the data path interface between the > > >>>> FEC Framework and > > >>>> both underlying and overlying layers can be thought > > >>>> of as being the > > >>>> same as the standard interface to the transport > > >>>> layer - i.e. the data > > >>>> exchanged consists of datagram payloads each > > >>>> associated with a single > > >>>> transport flow identified (in the case of UDP) by > > >>>> the standard > > >>>> 5-tuple { Source IP Address, Source Transport Port, > > >>>> Destination IP > > >>>> Address, Destination Transport Port, Transport > > >>>> Protocol }. In the > > >>>> case that RTP is used for the repair flows, the > > >>>> source and repair > > >>>> data may be multiplexed using RTP onto a single UDP > > >>>> flow and must > > >>>> consequently be demultiplexed at the receiver. > > >>>> There are various > > >>>> ways in which this multiplexing can be done, for > > >>>> example as described > > >>>> in [RFC4588]. > > >>>> > > >>>> > > >>>> RFC 4588 mentions two ways of multiplexing RTP streams. > > >>>> One is session multiplexing, where source and repair RTP > > >>>> streams are in different RTP sessions (different dest > > >>>> address/port). In this case, I don't have any issues, this > > >>>> works beautifully with the framework. > > >>>> > > >>>> The other one is SSRC multiplexing where the source and > > >>>> repair RTP streams have different SSRCs but are transmitted > > >>>> in the same RTP session (which is a single UDP flow). Is the > > >>>> text above saying that the framework also support this kind > > >>>> of multiplexing? In other words, is using a single UDP flow > > >>>> to carry source + FEC data acceptable when they have > > >> separate SSRCs? > > >>>> > > >>>> Not that FEC could not be used in this scenario, but as > > >>>> I recall the framework required different UDP flows for > > >>>> source and repair flows... > > >>>> > > >>>> BR, > > >>>> -acbegen > > >>>> > > >>>> > > >>>> > > >>>> > > >>> _______________________________________________ > > >>> Fecframe mailing list > > >>> Fecframe@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/fecframe > > >> > > >> > > >> > > >> -- > > >> Colin Perkins > > >> http://csperkins.org/ > > >> > > >> > > >> > > >> > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www.ietf.org/mailman/listinfo/mmusic > > > > > > > > -- > > Colin Perkins > > http://csperkins.org/ > > > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From vincent.roca@inrialpes.fr Wed Apr 29 00:10:19 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F34A3A6E1F for ; Wed, 29 Apr 2009 00:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.7 X-Spam-Level: X-Spam-Status: No, score=-5.7 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] 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 QGos2OfKodJJ for ; Wed, 29 Apr 2009 00:10:12 -0700 (PDT) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id 1B7B03A6DDD for ; Wed, 29 Apr 2009 00:10:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,265,1238968800"; d="eml'208?scan'208,208";a="39192770" Received: from ornon.inrialpes.fr (HELO [194.199.24.115]) ([194.199.24.115]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2009 09:11:32 +0200 Message-ID: <49F7FDA3.80306@inrialpes.fr> Date: Wed, 29 Apr 2009 09:11:31 +0200 From: Vincent Roca User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: fecframe@ietf.org X-Enigmail-Version: 0.95.0 Content-Type: multipart/mixed; boundary="------------070407010107090505000603" Subject: [Fecframe] [Fwd: [Rmt] RFC 5510 on Reed-Solomon Forward Error Correction (FEC) Schemes] X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 07:10:19 -0000 This is a multi-part message in MIME format. --------------070407010107090505000603 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello everybody, FYI, the RFC specifying the Reed-Solomon Schemes that I mentioned during the previous meeting is now available (see mail below). It's for file transfer-like applications (RMT), but it also defines the underlying code. In order to answer (partially) to a question asked during this meeting, you'll find a complexity analysis in sections: 8.2.2. Encoding Complexity 8.3.2. Decoding Complexity But of course, the way it's implemented matters a lot in the actual encoding/decoding speed that can be achieved. In any case, you can download the open-source codec and test by yourself. Regards, Vincent (on behalf of the authors) --------------070407010107090505000603 Content-Type: message/rfc822; name="[Rmt] RFC 5510 on Reed-Solomon Forward Error Correction (FEC) Schemes.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="[Rmt] RFC 5510 on Reed-Solomon Forward Error Correction (FEC"; filename*1=") Schemes.eml" Return-Path: Received: from murder ([unix socket]) by dwimmerlaik.inrialpes.fr (Cyrus v2.2.12) with LMTPA; Wed, 29 Apr 2009 01:58:09 +0200 X-Sieve: CMU Sieve 2.2 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by dwimmerlaik.inrialpes.fr (8.13.6/8.11.3/ImagV2) with ESMTP id n3SNw8Ef020793; Wed, 29 Apr 2009 01:58:08 +0200 (MEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwAADM090lAqmIgjmdsb2JhbACVc3sBAQEBCQsICQ8Ht16DcwU X-IronPort-AV: E=Sophos;i="4.40,263,1238968800"; d="scan'208";a="39182117" Received: from mail.ietf.org ([64.170.98.32]) by mail4-smtp-sop.national.inria.fr with ESMTP; 29 Apr 2009 01:58:01 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 978CE3A6CEB; Tue, 28 Apr 2009 16:56:12 -0700 (PDT) X-Original-To: rmt@core3.amsl.com Delivered-To: rmt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCEAC3A6BA6; Tue, 28 Apr 2009 16:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.923 X-Spam-Level: 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 0KaBUGd5ax6e; Tue, 28 Apr 2009 16:56:10 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 82E2B3A6C7F; Tue, 28 Apr 2009 16:56:03 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id CEB7A293E4C; Tue, 28 Apr 2009 16:54:39 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090428235439.CEB7A293E4C@bosco.isi.edu> Date: Tue, 28 Apr 2009 16:54:39 -0700 (PDT) Cc: rmt@ietf.org, rfc-editor@rfc-editor.org Subject: [Rmt] RFC 5510 on Reed-Solomon Forward Error Correction (FEC) Schemes X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rmt-bounces@ietf.org Errors-To: rmt-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5510 Title: Reed-Solomon Forward Error Correction (FEC) Schemes Author: J. Lacan, V. Roca, J. Peltotalo, S. Peltotalo Status: Standards Track Date: April 2009 Mailbox: jerome.lacan@isae.fr, vincent.roca@inria.fr, jani.peltotalo@tut.fi, sami.peltotalo@tut.fi Pages: 28 Characters: 57493 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-rmt-bb-fec-rs-05.txt URL: http://www.rfc-editor.org/rfc/rfc5510.txt This document describes a Fully-Specified Forward Error Correction (FEC) Scheme for the Reed-Solomon FEC codes over GF(2^^m), where m is in {2..16}, and its application to the reliable delivery of data objects on the packet erasure channel (i.e., a communication path where packets are either received without any corruption or discarded during transmission). This document also describes a Fully-Specified FEC Scheme for the special case of Reed-Solomon codes over GF(2^^8) when there is no encoding symbol group. Finally, in the context of the Under-Specified Small Block Systematic FEC Scheme (FEC Encoding ID 129), this document assigns an FEC Instance ID to the special case of Reed-Solomon codes over GF(2^^8). Reed-Solomon codes belong to the class of Maximum Distance Separable (MDS) codes, i.e., they enable a receiver to recover the k source symbols from any set of k received symbols. The schemes described here are compatible with the implementation from Luigi Rizzo. [STANDARDS TRACK] This document is a product of the Reliable Multicast Transport Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute _______________________________________________ Rmt mailing list Rmt@ietf.org https://www.ietf.org/mailman/listinfo/rmt --------------070407010107090505000603-- From vincent.roca@inrialpes.fr Wed Apr 29 02:24:35 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 748D028B797 for ; Wed, 29 Apr 2009 02:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.991 X-Spam-Level: X-Spam-Status: No, score=-6.991 tagged_above=-999 required=5 tests=[AWL=1.258, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 dVxtslXO-3LK for ; Wed, 29 Apr 2009 02:24:34 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id 57D9E3A709F for ; Wed, 29 Apr 2009 02:24:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,265,1238968800"; d="txt'?scan'208";a="25347400" Received: from ornon.inrialpes.fr (HELO [194.199.24.115]) ([194.199.24.115]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2009 11:25:52 +0200 Message-ID: <49F81D20.6090402@inrialpes.fr> Date: Wed, 29 Apr 2009 11:25:52 +0200 From: Vincent Roca User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Marshall Eubanks References: <387DA3D4-8B91-48C8-BB08-3C0725D112F8@multicasttech.com> In-Reply-To: <387DA3D4-8B91-48C8-BB08-3C0725D112F8@multicasttech.com> X-Enigmail-Version: 0.95.0 Content-Type: multipart/mixed; boundary="------------010109020408040804050309" Cc: fecframe@ietf.org Subject: Re: [Fecframe] Working Group Last Call on draft-ietf-fecframe-config-signaling X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 09:24:35 -0000 This is a multi-part message in MIME format. --------------010109020408040804050309 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, Here is my review of the fecframe-config-signaling I-D. I didn't look at Ali's comments, so this is a totally independent review. Regards, Vincent --------------010109020408040804050309 Content-Type: text/plain; name="fecframe-config-signaling-01_comments.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fecframe-config-signaling-01_comments.txt" Comments to draft-ietf-fecframe-config-signaling-01.txt Vincent - April 29th, 2009 ------------------------------------------------------- For discussion... I- Main comments ---------------- 1/ Sections 4.1.1 and 4.1.2: administrative scoping with multiple FecFrame sessions ----------------------------------------------------------------------------------- In case IPv4 administrative scope is selected, the target multicast address must be set to 239.16.33.254 (section 4.1.1 and 4.1.2). What happens if two senders in the same LAN need different non overlapping administrative scoping regions? As I understand, scoping is configured per address, and since there's a single address, the associated scoping region must be in that example the union of the two disjoint scoping regions. Not very effective... Additionally, why this magic value of 239.16.33.254? Is there any good reason for choosing this value and not a different one? If the choice is arbitrary, it should be mentioned. Same remark for 239.16.33.254. 2/ Sections 4.1.1 "Sender procedure": stopping the FEC Framework Instance ------------------------------------------------------------------------- It is said: The sender must periodically send the 'SAP announcement' message. This is required so that the receiver doesn't purge the cached entry(s) from the database and doesn't trigger the deletion of FEC Framework configuration information. I don't understand why a receiver who correctly obtained the FEC Framework Config Info should stop its FEC Framework Instance, just because he doesn't receive any SAP announcement for this instance any more. What matters most is the fact the receiver still receives the source/repair packets for this instance. I suggest to keep the two aspects separate rather than creating implicit relationships between them. 3/ Sections 4.1.1 "Sender procedure": 'time interval' ----------------------------------------------------- It is said: Additionally, the 'time interval' should be signaled within the FEC Framework configuration Information. There is no such requirement in the FEC Framework I-D. This "time interval" is specific to the use of SAP and has nothing to do with the FEC Framework. More generally, if SAP defines a "very sophisticated but complex formula" (as said in the I-D) to define the time interval, there are probably good reasons. I'm not convinced by the explanation provided to justify the use of a fixed value, especially when the conclusion consists in saying that: "The SAP implementation should provide the flexibility to the operator to choose the complex method over the simpler method..." What should be done? We need guidelines here. 4/ Section 4.1: On the use of SAP --------------------------------- More generally, the use of SAP as the technical transport mechanism for multicast session descriptions should be discussed. It's available, standardized, simple, which is good. But there are also major limitations that should not be ignored. FYI, with Hitoshi, we tried to clarify them in the following I-D: http://tools.ietf.org/id/draft-ietf-mboned-session-announcement-req-01.txt I'm not saying that SAP should not be used, but its limitations should be mentioned. 5/ Section 4.1.2 "Receiver Procedure": max timer value ------------------------------------------------------- It is said: ...the timer of the corresponding entry should be reset to the three times the time-interval value that is signaled by the sender or one hour, whichever is greater. The consequence is that an entry is kept at least 1 hour. I don't understand the motivation, especially if we consider that the default "time interval" is 60 seconds (previous section), which means that "three times the time-interval value" defaults to 3 minutes... There is a huge gap! 6/ Section 5. "Security considerations" --------------------------------------- Are you really sure that: "There is no additional security consideration other than what's already covered in RFC2974 for SAP, RFC2326 for RTSP, RFC3261 for SIP etc. " And please, remove the final "etc." ;-) II- Sentences to clarify ------------------------ ** p2, Introduction: It is said: "This document describes how to use various signaling protocols to determine and communicate the Configuration information between sender and receiver(s)." I don't understand "determine". Do you mean "provide a way for the receiver(s) to determine the FEC Framework Conf Info? This sentence seems ambiguous to me. ** p3: the following paragraph: "Content Delivery Protocol (CDP) is defined as a complete (suite of)... [...] as defined in the FEC Framework document [FECARCH]." can probably be improved. ** p3 and p4, Terminology/Abbreviations: I suggest to append "(s)" to the "flow", to the "FEC stream" and to the "media receiver" since there can be several of them. ** p5, section 3.1 "Encoding format". It is said: "Whatever encoding format is selected for a particular FEC framework instance, it must be known by the signaling protocol. " I don't like "it must be known by..." which could be interpreted as "the signaling protocol must be able to analyze the encoding format" which is probably not the intent. I suggest: "The FEC Framework instance MUST communicate the encoding format used to the signaling protocol." ** p6, section 4. It is said: "It is important to note that there may be either only one receiver needing the FEC Framework configuration information to FEC protect a "unicasted multimedia stream"..." I don't like the whole sentence. I suggest: Sometimes, the multimedia stream is unicast to a single receiver (e.g., with Video On Demand) and the FEC Framework Configuration Information MUST be communicated only this receiver. In other situations, the multimedia stream is multicast to several receivers (e.g., with Broadcast TV or IPTV) and the FEC Framework Configuration Information MUST be communicated to all of them. ** p8: Rather than saying: "...MAY be subjected to the cryptography." I suggest "...MAY be encrypted." Later on, after the Figure, it is said: "While the RFC2974 includes explanation for each field, it is worth discussing the 'Payload' and 'Payload Type' field. This field must be..." Two comments: - "fields." and not "field." in the first sentence. - "The 'Payload' field must be used... in the second sentence. ** p 9, section 4.1.1. "Sender Procedure" It is said: "This is the preferred method, though the other method may be to aggregate more than one SAP (announcement) messages in a single UDP datagram as long as the resulting UDP datagram length is less than the IP MTU of the outgoing interface." I suggest: - to split it into two sentences. "This is the preferred method. Another..." - to clarify that in the second method, there is one SAP announcement message per FEC Framework instance. - And finally, a third solution could be to send the SAP announcement messages separately... It's still possible and could make sense if each instance is managed separately, in a different OS process. It should also be mentioned. ** p9, section 4.1.1: IPv6 compatibility Signaling protocols can work on both IPv4 and IPv6. However, the text should not be restricted to IPv4 field names, as is the case in section 4.1.1: "The default IP TTL value should be 255, ..." TTL in IPv4 => "Hop Limit" in IPv6 ** p10, section 4.1.1: It is said: "The sender may choose to delete the announced FEC framework configuration information by sending a 'SAP deletion' message. This may be used if the sender no longer desires to send any FEC streams." I have the feeling that "no longer desires to send any FEC streams" is too strong. He can just want to close a stream, no matter whether he will define and send new streams in the future. In any case the comment I-2/ above applies here. ** p 11, section 4.2: I suggest to simplify... "the node acting as the offerer" => "the sender" "the node acting as the answerer" => "the receiver" if I understood correctly. ** p13, section 4.2.2: It is said: "The requesting node (Node1) may then send either the SETUP message without using the Require: header, if the remote node didn't support the "FEC protection", or a new SETUP message to request the selected FEC protection streams." This paragraph follows the exchange depicted in the figure, if I understand correctly. So the use of FEC Protection is already accepted and there is no reason to mention the case where FEC protection is not supported. I think the paragraph needs to be reorganized so that the two situations (200 versus 551) are considered. Additionally, I suggest that in the 200 OK response, the example mentions several FEC Framework instances, so that the need of the second SETUP message be more obvious. III- Additional comments ------------------------ ** p2, "Conventions used in this document" Why is this section here, before the Table of Contents? BTW, "C:" and "B:" are specified, however this is never used in the document! Remove it. ** Whole document: The use of upper case letters in "FEC Framework Configuration Information" is not consistent in the document. Please make sure that this specified term is always capitalized. ** Whole document: I see several occurrences where "must" is not written in lower case whereas it should be understood as "MUST". There is also a "must NOT" in section 4.1.1. Same remark for "should". ** Whole document: Using of "etc." is a very bad practice. In an enumeration, you must either provide the exhaustive list or say "for instance, ..." and provide a few examples. ** Whole document: On several occasions it is written: "the FEC Framework instance i.e. FEC scheme, ..." (also "Scheme") => three times on p5, then once on p11. I don't agree, a FEC Framework Instance is much more than simply a FEC scheme. There are many framing/blocking/configuration/recovery mechanisms in addition to the FEC codec. I suggest to remove "i.e. FEC scheme". ** Fig. 1: What is the added value of "MPLS network"? I suggest to remove it. IV- Typos --------- ** p3: "how are source blocks are constructed" -> "how source blocks are constructed" ** p3: remove "" ** p3: remove: " Copyright (C) The IETF Trust (2008). This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices." ** p6: Missing " " (space) in the following sentence: "sender),the receiver(s)" ** p6: Remove "describing using" in sentence: "Such diversity necessitates describing using at least two types of..." ** whole document: "multicasted" and "unicasted" do not exist => "unicast" and "multicast" ** p7: remove the final "s" to "obtains" in: " enables the receiver to receive the SAP message(s) and obtains the" ** p12: "SIP already uses offer/answer model" => "SIP already uses an offer/answer model" ** remove "section 7. Conclusions" --------------010109020408040804050309-- From mathieu.cunche@inrialpes.fr Wed Apr 29 05:08:23 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ADF93A6781 for ; Wed, 29 Apr 2009 05:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 SbYkOSow8kMM for ; Wed, 29 Apr 2009 05:08:22 -0700 (PDT) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id E9CA33A6963 for ; Wed, 29 Apr 2009 05:08:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,266,1238968800"; d="scan'208";a="39209663" Received: from denver.inrialpes.fr (HELO [194.199.24.123]) ([194.199.24.123]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2009 14:09:42 +0200 Message-ID: <49F8438F.3090307@inrialpes.fr> Date: Wed, 29 Apr 2009 14:09:51 +0200 From: Mathieu Cunche User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: alice.albano@inrialpes.fr Subject: [Fecframe] Remark on the textual representation of FSSI fields X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 12:08:23 -0000 Hello everybody, We have a remark on the the way the FSSI (FEC Scheme-Specific Information) and the SS-FSSI (Sender-Side FSSI) binary fields are converted into a character string for SDP. In fact we haven't found any specification in the various FECFRAME I-Ds on the way this conversion should be done. >From RFC4566 "Session Description Protocol", p.33: "Encoding considerations: SDP files are primarily UTF-8 format text. The "a=charset:" attribute may be used to signal the presence of other character sets in certain parts of an SDP file (see Section 6 of RFC 4566 ). Arbitrary binary content cannot be directly represented in SDP." We are typically in the case where we need a textual encoding of the binary SS-FSSI/FSSI "octet string". In the SDP example provided in draft-ietf-fecframe-raptor-00 (section 10) it seems that the encoding used is Base64. However this is never explicitly said (!), neither in this I-D nor in any other I-D (see extracts at the end of the email). ----------- [...] a=fec-repair-flow: scheme-id=0; ss-fssi=5hu= ------------ (BTW: the above SDP description is erroneous, since SS-FSSI is never defined elsewhere in this I-D and on the opposite the FSSI is missing) Base64 seems to be the best solution (more compact than an hexadecimal string). Should this encoding be definitively adopted? And in this case, where should it be specified? Our feeling is that: - it should be clarified in each FEC scheme document (as is the case with RFC 5170/4.2.4.2 (LDPC) and RFC 5510/4.2.4.2 (Reed-Solomon)), when a textual encoding is needed for the "octet string"; - it should be specified in the sdp-elements I-D, section 3.3. as well. Regards, Mathieu, Alice and Vincent NB: here are the I-D extracts that mention SS-FSSI and FSSI: ------------ * SDP Elements for FEC Framework (draft-ietf-fecframe-sdp-elements-02): - page 6: "The variable-length opaque SS-FSSI and FSSI containers transmit the information in the form of an octet string. The FEC schemes define the structure of this octet string, which may contain multiple distinct elements." - page 10: " The OPTIONAL parameters 'ss-fssi' and 'fssi' are opaque containers to convey the FEC-Scheme-Specific Information (FSSI) that includes the information that is specific to the FEC scheme used by the CDP and is necessary for proper FEC encoding and decoding operations. The FSSI required only by the sender (called Sender-Side FSSI) MUST be communicated in the container specified by the parameter 'ss-fssi'. Any other FSSI MUST be communicated in the container specified by the parameter 'fssi'. In both containers, FSSI is transmitted in the form of an octet string. The FEC schemes define the structure of this octet string, which MAY contain multiple distinct elements. If the FEC scheme does not require any specific information, the 'ss-fssi' and 'fssi' parameters MAY be null and ignored." MC => this text should be fixed since "transmitting the FSSI in the form of an octet string" is not possible. * Methods to convey FEC Framework Configuration Information (draft-ietf-fecframe-config-signaling-01.txt) - page 5: "Additionally, the encoding format for each FEC Framework configuration parameter must be defined in terms of a sequence of octets that can be embedded within the payload of the signaling protocol message(s). The length of the encoding format MUST either be fixed, or derived by examining the encoded octets themselves. For example, the initial octets may include some kind of length indication. [...]The reader may refer to the SDP elements document [FECSDP], which describes the usage of 'SDP' encoding format as an example encoding format for FEC framework configuration information." MC => with Base64 encoding, there is no need to add any "initial octet to include a length indication". It's the goal of the final "=" or "==" characters. * Raptor FEC Schemes for FECFRAME (draft-ietf-fecframe-raptor-00) - page 8: "The scheme-specific elements of the FEC Framework Configuration information for this scheme are as follows: Maximum Source Block Length A non-negative integer less than 213, in units of symbols Encoding Symbol Size A non-negative integer less than 216, in units of bytes An encoding format for this information in a 4 octet field is defined as follows: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Symbol Size (T) | Max. Source Block Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: FEC Scheme Specific Information MC => the "encoding format" here refers to the binary encoding, not the final encoding to be used when this binary encoding must be carried in SDP or any textual representation. * And of course, we need to fix our Reed-Solomon I-D too... From abegen@cisco.com Wed Apr 29 14:12:15 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F3F028C2C5 for ; Wed, 29 Apr 2009 14:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.352 X-Spam-Level: X-Spam-Status: No, score=-6.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 qawyuXhE8WpJ for ; Wed, 29 Apr 2009 14:12:13 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C5F6D3A6DE8 for ; Wed, 29 Apr 2009 14:12:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,268,1238976000"; d="scan'208";a="178716006" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 29 Apr 2009 21:13:36 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3TLDaau025762; Wed, 29 Apr 2009 14:13:36 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3TLDaVS014172; Wed, 29 Apr 2009 21:13:36 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 14:13:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Apr 2009 14:12:35 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5409348D62@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49F8438F.3090307@inrialpes.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Remark on the textual representation of FSSI fields Thread-Index: AcnIw2T7Ie4FMJM7QSy19m99eJsTvwAQhkbg References: <49F8438F.3090307@inrialpes.fr> From: "Ali C. Begen (abegen)" To: "Mathieu Cunche" , X-OriginalArrivalTime: 29 Apr 2009 21:13:36.0259 (UTC) FILETIME=[5C098530:01C9C90F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7548; t=1241039616; x=1241903616; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[Fecframe]=20Remark=20on=20the=20textua l=20representation=20of=20FSSI=20fields |Sender:=20; bh=MGI8b/kzlK3lPUbyFsYI9FjGltL9H4Nov7Zwe9EP6qI=; b=SyI9eL99Hjw1DACO6mvt0LkBQLuJ18rBOf3eR5/clLTYahIuSK8ZDDKYqJ NJIHhfrFyv5Rbo247etb3ZgFogtntPSScNds7fKblkkhldfCgik2ZFuw/Slg jvc+FgVIBW0cLHbBmuja04N1wkI3qdwPXboa+UpwUmQ+k/j+H+QAw=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: alice.albano@inrialpes.fr Subject: Re: [Fecframe] Remark on the textual representation of FSSI fields X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 21:12:15 -0000 Hi Mathieu, Thanks for bringing this up. My feeling is that the FEC scheme drafts = should define the content of the FSSI information (i.e., what needs to = go in there) but they do not normally need to define how the FSSI should = be encoded in the SDP since FEC schemes may use other ways to convey the = configuration information. However, if a scheme uses RTP, we clearly = need the SDP encodings for that scheme as RTP will imply using SDP. For the encoding in SDP, we could use base64 as the default format. = However, this has the disadvantage of not being human-readable. When we = consider RTCP instrumentation in the middle boxes in the network, the = opaque data is not a good idea, either. Just because it saves some bits = won't make it an ideal encoding format. So, personally I prefer ascii. = And when I look at most other formatting parameters (like the ones for = RTP), they are all ascii. There are certain semantics that are not scheme specific, and they = should be in ascii format in the SDP (like a=3Drepair-window) anyway. We had a similar discussion in 2007. Look at the archives here: http://www.ietf.org/mail-archive/web/fecframe-proto/current/mail7.html Comments? -acbegen > -----Original Message----- > From: fecframe-bounces@ietf.org=20 > [mailto:fecframe-bounces@ietf.org] On Behalf Of Mathieu Cunche > Sent: Wednesday, April 29, 2009 5:10 AM > To: fecframe@ietf.org > Cc: alice.albano@inrialpes.fr > Subject: [Fecframe] Remark on the textual representation of=20 > FSSI fields >=20 > Hello everybody, >=20 > We have a remark on the the way the FSSI (FEC Scheme-Specific > Information) and the SS-FSSI (Sender-Side FSSI) binary fields > are converted into a character string for SDP. > In fact we haven't found any specification in the various > FECFRAME I-Ds on the way this conversion should be done. >=20 > From RFC4566 "Session Description Protocol", p.33: > "Encoding considerations: > SDP files are primarily UTF-8 format text. The "a=3Dcharset:" > attribute may be used to signal the presence of other > character sets in certain parts of an SDP file (see > Section 6 of RFC 4566 > ). Arbitrary > binary content cannot be directly represented in SDP." >=20 > We are typically in the case where we need a textual encoding > of the binary SS-FSSI/FSSI "octet string". >=20 > In the SDP example provided in draft-ietf-fecframe-raptor-00 > (section 10) it seems that the encoding used is Base64. However > this is never explicitly said (!), neither in this I-D nor in > any other I-D (see extracts at the end of the email). > ----------- > [...] > a=3Dfec-repair-flow: scheme-id=3D0; ss-fssi=3D5hu=3D > ------------ > (BTW: the above SDP description is erroneous, since SS-FSSI > is never defined elsewhere in this I-D and on the opposite > the FSSI is missing) >=20 >=20 > Base64 seems to be the best solution (more compact than > an hexadecimal string). Should this encoding be definitively > adopted? And in this case, where should it be specified? >=20 > Our feeling is that: > - it should be clarified in each FEC scheme document (as > is the case with RFC 5170/4.2.4.2 (LDPC) and > RFC 5510/4.2.4.2 (Reed-Solomon)), when a textual encoding > is needed for the "octet string"; >=20 > - it should be specified in the sdp-elements I-D, section 3.3. > as well. >=20 > Regards, >=20 >=20 > Mathieu, Alice and Vincent >=20 > NB: here are the I-D extracts that mention SS-FSSI and FSSI: >=20 > ------------ >=20 >=20 > * SDP Elements for FEC Framework=20 > (draft-ietf-fecframe-sdp-elements-02): >=20 > - page 6: "The variable-length opaque SS-FSSI and FSSI containers > transmit the information in the form of an octet string. The FEC > schemes define the structure of this octet string, which=20 > may contain > multiple distinct elements." >=20 > - page 10: " The OPTIONAL parameters 'ss-fssi' and 'fssi'=20 > are opaque > containers to convey the FEC-Scheme-Specific Information=20 > (FSSI) that > includes the information that is specific to the FEC=20 > scheme used by > the CDP and is necessary for proper FEC encoding and decoding > operations. The FSSI required only by the sender (called > Sender-Side FSSI) MUST be communicated in the container=20 > specified by > the parameter 'ss-fssi'. Any other FSSI MUST be=20 > communicated in the > container specified by the parameter 'fssi'. In both containers, > FSSI is transmitted in the form of an octet string. The=20 > FEC schemes > define the structure of this octet string, which MAY contain > multiple distinct elements. If the FEC scheme does not=20 > require any > specific information, the 'ss-fssi' and 'fssi' parameters MAY be > null and ignored." >=20 > MC =3D> this text should be fixed since "transmitting the FSSI=20 > in the form > of an octet string" is not possible. >=20 >=20 > * Methods to convey FEC Framework Configuration Information > (draft-ietf-fecframe-config-signaling-01.txt) >=20 > - page 5: "Additionally, the encoding format for each FEC=20 > Framework > configuration parameter must be defined in terms of a sequence of > octets that can be embedded within the payload of the signaling > protocol message(s). The length of the encoding format=20 > MUST either > be fixed, or derived by examining the encoded octets themselves. > For example, the initial octets may include some kind of length > indication. [...]The reader may refer to the SDP elements document > [FECSDP], which describes the usage of 'SDP' encoding format as an > example encoding format for FEC framework configuration=20 > information." >=20 > MC =3D> with Base64 encoding, there is no need to add any "initial = octet > to include a length indication". It's the goal of the final = "=3D" > or "=3D=3D" characters. >=20 >=20 > * Raptor FEC Schemes for FECFRAME (draft-ietf-fecframe-raptor-00) >=20 > - page 8: "The scheme-specific elements of the FEC Framework > Configuration information for this scheme are as follows: > Maximum Source Block Length A non-negative integer less than 213, > in units of symbols > Encoding Symbol Size A non-negative integer less than 216, in > units of bytes > An encoding format for this information in a 4 octet field is > defined as follows: >=20 > 1 2 =20 > 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4=20 > 5 6 7 8 9 0 1 > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Symbol Size (T) | Max. Source=20 > Block Length | > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Figure 1: FEC Scheme Specific Information >=20 > MC =3D> the "encoding format" here refers to the binary encoding, not > the final encoding to be used when this binary encoding must > be carried in SDP or any textual representation. >=20 >=20 > * And of course, we need to fix our Reed-Solomon I-D too... >=20 >=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe >=20 From abegen@cisco.com Wed Apr 29 14:59:20 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1118D3A6E42; Wed, 29 Apr 2009 14:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.356 X-Spam-Level: X-Spam-Status: No, score=-6.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Z6+6u90DyxvT; Wed, 29 Apr 2009 14:59:19 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 184523A6DFD; Wed, 29 Apr 2009 14:59:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,268,1238976000"; d="scan'208";a="157792158" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 29 Apr 2009 22:00:38 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3TM0cm8023378; Wed, 29 Apr 2009 15:00:38 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3TLxpSK028029; Wed, 29 Apr 2009 22:00:38 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 15:00:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Wed, 29 Apr 2009 15:00:16 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5409348DA0@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 Thread-Index: AcnJFZBSN2BsQsK8Rtu0PIlBx+ZGHQAABYCg From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 29 Apr 2009 22:00:19.0500 (UTC) FILETIME=[E2E626C0:01C9C915] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2246; t=1241042438; x=1241906438; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20FW=3A=20New=20Version=20Notification=20for=20=2 0=20=20=20=20=20=20=20=20draft-ietf-fecframe-interleaved-fec -scheme-04=20 |Sender:=20; bh=ubUrvvjORw5256T5Rfe7C93jCZfjUgRJZt6jBIBfFto=; b=KwvW3Y3nvLPevec+KQhCL8F7h7VoHc9tc0G0rWnbT+0s2TLDD9xTBsuWEt 7921xWgW5o2OOoo0o+KEPGR8WYf54V/OLAYgAwyA4UBcEXQBBCXOx+Qg1VaF C+KslyVoDQ; Authentication-Results: sj-dkim-3; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: avt@ietf.org Subject: [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 21:59:20 -0000 VGhpcyB2ZXJzaW9uIGFkZHJlc3NlcyB0aGUgY29tbWVudHMgcmVjZWl2ZWQgZnJvbSBmZWNmcmFt ZSBhbmQgYXZ0IHNvIGZhci4gDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUtMDQudHh0DQoNCg0KRmVj ZnJhbWUgY2hhaXJzLA0KDQpDb3VsZCB3ZSBwcm9jZWVkIGFuZCBmaW5hbGl6ZSBXR0xDPw0KDQot YWNiZWdlbg0KIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSUVURiBJLUQg U3VibWlzc2lvbiBUb29sIFttYWlsdG86aWRzdWJtaXNzaW9uQGlldGYub3JnXSANClNlbnQ6IFdl ZG5lc2RheSwgQXByaWwgMjksIDIwMDkgMjo1NiBQTQ0KVG86IEFsaSBDLiBCZWdlbiAoYWJlZ2Vu KQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWZlY2Zy YW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUtMDQgDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LWlldGYtZmVjZnJhbWUtaW50ZXJsZWF2ZWQtZmVjLXNjaGVtZS0wNC50eHQgaGFzIGJl ZW4gc3VjY2Vzc2Z1bHkgc3VibWl0dGVkIGJ5IEFsaSBCZWdlbiBhbmQgcG9zdGVkIHRvIHRoZSBJ RVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtaWV0Zi1mZWNmcmFtZS1pbnRlcmxl YXZlZC1mZWMtc2NoZW1lDQpSZXZpc2lvbjoJIDA0DQpUaXRsZToJCSBSVFAgUGF5bG9hZCBGb3Jt YXQgZm9yIDEtRCBJbnRlcmxlYXZlZCBQYXJpdHkgRkVDDQpDcmVhdGlvbl9kYXRlOgkgMjAwOS0w NC0yOQ0KV0cgSUQ6CQkgZmVjZnJhbWUNCk51bWJlcl9vZl9wYWdlczogMzENCg0KQWJzdHJhY3Q6 DQpUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBuZXcgUlRQIHBheWxvYWQgZm9ybWF0IGZvciB0aGUg Rm9yd2FyZCBFcnJvcg0KQ29ycmVjdGlvbiAoRkVDKSB0aGF0IGlzIGdlbmVyYXRlZCBieSB0aGUg MS1EIGludGVybGVhdmVkIHBhcml0eSBjb2RlDQpmcm9tIGEgc291cmNlIG1lZGlhIGVuY2Fwc3Vs YXRlZCBpbiBSVFAuICBUaGUgMS1EIGludGVybGVhdmVkIHBhcml0eQ0KY29kZSBpcyBhIHN5c3Rl bWF0aWMgY29kZSwgd2hlcmUgYSBudW1iZXIgb2YgcmVwYWlyIHN5bWJvbHMgYXJlDQpnZW5lcmF0 ZWQgZnJvbSBhIHNldCBvZiBzb3VyY2Ugc3ltYm9scyBhbmQgc2VudCBpbiBhIHJlcGFpciBmbG93 DQpzZXBhcmF0ZSBmcm9tIHRoZSBzb3VyY2UgZmxvdyB0aGF0IGNhcnJpZXMgdGhlIHNvdXJjZSBz eW1ib2xzLiAgVGhlDQoxLUQgaW50ZXJsZWF2ZWQgcGFyaXR5IGNvZGUgb2ZmZXJzIGEgZ29vZCBw cm90ZWN0aW9uIGFnYWluc3QgYnVyc3R5DQpwYWNrZXQgbG9zc2VzIGF0IGEgY29zdCBvZiBkZWNl bnQgY29tcGxleGl0eS4gIFRoZSBuZXcgcGF5bG9hZCBmb3JtYXQNCmRlZmluZWQgaW4gdGhpcyBk b2N1bWVudCBpcyB1c2VkICh3aXRoIHNvbWUgZXhjZXB0aW9ucykgYXMgYSBwYXJ0IG9mDQp0aGUg RFZCIEFwcGxpY2F0aW9uLWxheWVyIEZFQyBzcGVjaWZpY2F0aW9uLg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0Lg0KDQoNCg== From root@core3.amsl.com Wed Apr 29 15:00:01 2009 Return-Path: X-Original-To: fecframe@ietf.org Delivered-To: fecframe@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EE1813A717C; Wed, 29 Apr 2009 15:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090429220001.EE1813A717C@core3.amsl.com> Date: Wed, 29 Apr 2009 15:00:01 -0700 (PDT) Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-interleaved-fec-scheme-04.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 22:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the FEC Framework Working Group of the IETF. Title : RTP Payload Format for 1-D Interleaved Parity FEC Author(s) : A. Begen Filename : draft-ietf-fecframe-interleaved-fec-scheme-04.txt Pages : 31 Date : 2009-04-29 This document defines a new RTP payload format for the Forward Error Correction (FEC) that is generated by the 1-D interleaved parity code from a source media encapsulated in RTP. The 1-D interleaved parity code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The 1-D interleaved parity code offers a good protection against bursty packet losses at a cost of decent complexity. The new payload format defined in this document is used (with some exceptions) as a part of the DVB Application-layer FEC specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interleaved-fec-scheme-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-fecframe-interleaved-fec-scheme-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-29145549.I-D@ietf.org> --NextPart-- From vincent.roca@inrialpes.fr Thu Apr 30 03:57:15 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E606C3A6ACF; Thu, 30 Apr 2009 03:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.171 X-Spam-Level: X-Spam-Status: No, score=-6.171 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 7tAaEXQQZ7ir; Thu, 30 Apr 2009 03:57:15 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id 702CE3A68CB; Thu, 30 Apr 2009 03:57:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,272,1238968800"; d="scan'208";a="25420782" Received: from ornon.inrialpes.fr (HELO [194.199.24.115]) ([194.199.24.115]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2009 12:58:35 +0200 Message-ID: <49F9845B.1090704@inrialpes.fr> Date: Thu, 30 Apr 2009 12:58:35 +0200 From: Vincent Roca User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <04CAD96D4C5A3D48B1919248A8FE0D5409348DA0@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5409348DA0@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 10:57:16 -0000 Hello Ali, I'm not in favor of finalizing the WGLC for this document. IMHO we must, first of all, finalize the framework document itself. For instance, the terminology used by the interleaved-fec-scheme I-D (section 3.1.) is not in line with the terminology used by the fecframe-framework-03 I-D (Section 2): "Source Flow" vs. "Source data flow" "Repair Flow" vs. "Repair data flow" "Source Symbol" vs. nothing "Repair Symbol" vs. nothing "Source Packet" vs. nothing "Repair Packet" vs. nothing And as I said before, IMHO the terminology proposed in the framework I-D should be discussed too. So let's do things in the right order, especially as the framework WGLC finishes soon. Additionally, I may have some comments for the interleaved-fec-scheme-04 I-D. Since I missed the WGLC deadline, you have the right to blame me ;-) and I apologize in advance. Regards, Vincent Ali C. Begen (abegen) wrote: > This version addresses the comments received from fecframe and avt so far. > http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interleaved-fec-scheme-04.txt > > > Fecframe chairs, > > Could we proceed and finalize WGLC? > > -acbegen > > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Wednesday, April 29, 2009 2:56 PM > To: Ali C. Begen (abegen) > Subject: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 > > > A new version of I-D, draft-ietf-fecframe-interleaved-fec-scheme-04.txt has been successfuly submitted by Ali Begen and posted to the IETF repository. > > Filename: draft-ietf-fecframe-interleaved-fec-scheme > Revision: 04 > Title: RTP Payload Format for 1-D Interleaved Parity FEC > Creation_date: 2009-04-29 > WG ID: fecframe > Number_of_pages: 31 > > Abstract: > This document defines a new RTP payload format for the Forward Error > Correction (FEC) that is generated by the 1-D interleaved parity code > from a source media encapsulated in RTP. The 1-D interleaved parity > code is a systematic code, where a number of repair symbols are > generated from a set of source symbols and sent in a repair flow > separate from the source flow that carries the source symbols. The > 1-D interleaved parity code offers a good protection against bursty > packet losses at a cost of decent complexity. The new payload format > defined in this document is used (with some exceptions) as a part of > the DVB Application-layer FEC specification. > > > > The IETF Secretariat. > > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From abegen@cisco.com Thu Apr 30 05:52:17 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A3C73A6848; Thu, 30 Apr 2009 05:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 QMFWJTbpv46f; Thu, 30 Apr 2009 05:52:16 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 4252F3A6841; Thu, 30 Apr 2009 05:52:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,273,1238976000"; d="scan'208,217";a="157926833" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 30 Apr 2009 12:53:39 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3UCrdwC019392; Thu, 30 Apr 2009 05:53:39 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3UCrdRv003008; Thu, 30 Apr 2009 12:53:39 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 05:53:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C992.AE5F6E58" Date: Thu, 30 Apr 2009 05:53:38 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 Thread-Index: AcnJgq+DQP1j7cRATQa6PC9zcfp8gAAD/6re From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 30 Apr 2009 12:53:39.0251 (UTC) FILETIME=[AED71830:01C9C992] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12695; t=1241096019; x=1241960019; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20Re=3A=20[Fecframe]=20FW=3A=20New=20Version=20No tification=20for=09draft-ietf-fecframe-interleaved-fec-schem e-04 |Sender:=20; bh=I9OYEh3aDGm9iJVQYShMapXmuYpTSJlGqZ9numi8C0A=; b=tTJr6V/B3SEZU+hrYiVtDfS3eF+VAVpEirh98OzmwbBn3JP3YmWP89FBp+ g3MBVcSzMKv1m7OAMQxeL32hzCvN5L3r5MSc2tQxJ+hVpa7fMARy5DQCl5wv E7sY/jJWrf; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 12:52:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C992.AE5F6E58 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgVmluY2VudA0KDQpUaGlzIGRyYWZ0IGlzIG5vdCBhbiBmZWMgc2NoZW1lIHNvIGl0IGlzIG5v dCByZWxhdGVkIHRvIGZlYyBmcmFtZXdvcmsuIEl0IGlzIGFuIHJ0cCBwYXlsb2FkIGZvcm1hdCBk cmFmdC4gVGhlIHdnbGMgaGFzIGJlZW4gcnVubmluZyBhbG1vc3QgYSBtb250aCBub3cuIElmIHlv dSBoYXZlIGNvbW1lbnRzIGluIHRoaXMgcGVyc3BlY3RpdmUsIHBscyBzdWJtaXQgdGhlbSBzb29u LiANCg0KDQoNCg0KLWFjYmVnZW4NCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJv bTogVmluY2VudCBSb2NhIDx2aW5jZW50LnJvY2FAaW5yaWFscGVzLmZyPg0KVG86IEFsaSBDLiBC ZWdlbiAoYWJlZ2VuKQ0KQ2M6IGZlY2ZyYW1lQGlldGYub3JnIDxmZWNmcmFtZUBpZXRmLm9yZz47 IGF2dEBpZXRmLm9yZyA8YXZ0QGlldGYub3JnPg0KU2VudDogVGh1IEFwciAzMCAwMzo1ODozNSAy MDA5DQpTdWJqZWN0OiBSZTogW0ZlY2ZyYW1lXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvcglkcmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUtMDQNCg0KSGVs bG8gQWxpLA0KDQpJJ20gbm90IGluIGZhdm9yIG9mIGZpbmFsaXppbmcgdGhlIFdHTEMgZm9yIHRo aXMgZG9jdW1lbnQuIElNSE8gd2UgbXVzdCwNCmZpcnN0IG9mIGFsbCwgZmluYWxpemUgdGhlIGZy YW1ld29yayBkb2N1bWVudCBpdHNlbGYuDQoNCkZvciBpbnN0YW5jZSwgdGhlIHRlcm1pbm9sb2d5 IHVzZWQgYnkgdGhlIGludGVybGVhdmVkLWZlYy1zY2hlbWUgSS1EDQooc2VjdGlvbiAzLjEuKSBp cyBub3QgaW4gbGluZSB3aXRoIHRoZSB0ZXJtaW5vbG9neSB1c2VkIGJ5IHRoZQ0KZmVjZnJhbWUt ZnJhbWV3b3JrLTAzIEktRCAoU2VjdGlvbiAyKToNCgkiU291cmNlIEZsb3ciICAgdnMuICJTb3Vy Y2UgZGF0YSBmbG93Ig0KCSJSZXBhaXIgRmxvdyIgICB2cy4gIlJlcGFpciBkYXRhIGZsb3ciDQoJ IlNvdXJjZSBTeW1ib2wiIHZzLiBub3RoaW5nDQoJIlJlcGFpciBTeW1ib2wiIHZzLiBub3RoaW5n DQoJIlNvdXJjZSBQYWNrZXQiIHZzLiBub3RoaW5nDQoJIlJlcGFpciBQYWNrZXQiIHZzLiBub3Ro aW5nDQpBbmQgYXMgSSBzYWlkIGJlZm9yZSwgSU1ITyB0aGUgdGVybWlub2xvZ3kgcHJvcG9zZWQg aW4gdGhlIGZyYW1ld29yaw0KSS1EIHNob3VsZCBiZSBkaXNjdXNzZWQgdG9vLg0KDQpTbyBsZXQn cyBkbyB0aGluZ3MgaW4gdGhlIHJpZ2h0IG9yZGVyLCBlc3BlY2lhbGx5IGFzIHRoZSBmcmFtZXdv cmsNCldHTEMgZmluaXNoZXMgc29vbi4NCg0KQWRkaXRpb25hbGx5LCBJIG1heSBoYXZlIHNvbWUg Y29tbWVudHMgZm9yIHRoZSBpbnRlcmxlYXZlZC1mZWMtc2NoZW1lLTA0DQpJLUQuIFNpbmNlIEkg bWlzc2VkIHRoZSBXR0xDIGRlYWRsaW5lLCB5b3UgaGF2ZSB0aGUgcmlnaHQgdG8gYmxhbWUgbWUg Oy0pDQphbmQgSSBhcG9sb2dpemUgaW4gYWR2YW5jZS4NCg0KUmVnYXJkcywNCg0KICBWaW5jZW50 DQoNCg0KQWxpIEMuIEJlZ2VuIChhYmVnZW4pIHdyb3RlOg0KPiBUaGlzIHZlcnNpb24gYWRkcmVz c2VzIHRoZSBjb21tZW50cyByZWNlaXZlZCBmcm9tIGZlY2ZyYW1lIGFuZCBhdnQgc28gZmFyLiAN Cj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1mZWNmcmFt ZS1pbnRlcmxlYXZlZC1mZWMtc2NoZW1lLTA0LnR4dA0KPiANCj4gDQo+IEZlY2ZyYW1lIGNoYWly cywNCj4gDQo+IENvdWxkIHdlIHByb2NlZWQgYW5kIGZpbmFsaXplIFdHTEM/DQo+IA0KPiAtYWNi ZWdlbg0KPiAgDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBJRVRG IEktRCBTdWJtaXNzaW9uIFRvb2wgW21haWx0bzppZHN1Ym1pc3Npb25AaWV0Zi5vcmddIA0KPiBT ZW50OiBXZWRuZXNkYXksIEFwcmlsIDI5LCAyMDA5IDI6NTYgUE0NCj4gVG86IEFsaSBDLiBCZWdl biAoYWJlZ2VuKQ0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWlldGYtZmVjZnJhbWUtaW50ZXJsZWF2ZWQtZmVjLXNjaGVtZS0wNCANCj4gDQo+IA0KPiBBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1mZWNmcmFtZS1pbnRlcmxlYXZlZC1mZWMtc2No ZW1lLTA0LnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVseSBzdWJtaXR0ZWQgYnkgQWxpIEJlZ2VuIGFu ZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IEZpbGVuYW1lOgkgZHJhZnQt aWV0Zi1mZWNmcmFtZS1pbnRlcmxlYXZlZC1mZWMtc2NoZW1lDQo+IFJldmlzaW9uOgkgMDQNCj4g VGl0bGU6CQkgUlRQIFBheWxvYWQgRm9ybWF0IGZvciAxLUQgSW50ZXJsZWF2ZWQgUGFyaXR5IEZF Qw0KPiBDcmVhdGlvbl9kYXRlOgkgMjAwOS0wNC0yOQ0KPiBXRyBJRDoJCSBmZWNmcmFtZQ0KPiBO dW1iZXJfb2ZfcGFnZXM6IDMxDQo+IA0KPiBBYnN0cmFjdDoNCj4gVGhpcyBkb2N1bWVudCBkZWZp bmVzIGEgbmV3IFJUUCBwYXlsb2FkIGZvcm1hdCBmb3IgdGhlIEZvcndhcmQgRXJyb3INCj4gQ29y cmVjdGlvbiAoRkVDKSB0aGF0IGlzIGdlbmVyYXRlZCBieSB0aGUgMS1EIGludGVybGVhdmVkIHBh cml0eSBjb2RlDQo+IGZyb20gYSBzb3VyY2UgbWVkaWEgZW5jYXBzdWxhdGVkIGluIFJUUC4gIFRo ZSAxLUQgaW50ZXJsZWF2ZWQgcGFyaXR5DQo+IGNvZGUgaXMgYSBzeXN0ZW1hdGljIGNvZGUsIHdo ZXJlIGEgbnVtYmVyIG9mIHJlcGFpciBzeW1ib2xzIGFyZQ0KPiBnZW5lcmF0ZWQgZnJvbSBhIHNl dCBvZiBzb3VyY2Ugc3ltYm9scyBhbmQgc2VudCBpbiBhIHJlcGFpciBmbG93DQo+IHNlcGFyYXRl IGZyb20gdGhlIHNvdXJjZSBmbG93IHRoYXQgY2FycmllcyB0aGUgc291cmNlIHN5bWJvbHMuICBU aGUNCj4gMS1EIGludGVybGVhdmVkIHBhcml0eSBjb2RlIG9mZmVycyBhIGdvb2QgcHJvdGVjdGlv biBhZ2FpbnN0IGJ1cnN0eQ0KPiBwYWNrZXQgbG9zc2VzIGF0IGEgY29zdCBvZiBkZWNlbnQgY29t cGxleGl0eS4gIFRoZSBuZXcgcGF5bG9hZCBmb3JtYXQNCj4gZGVmaW5lZCBpbiB0aGlzIGRvY3Vt ZW50IGlzIHVzZWQgKHdpdGggc29tZSBleGNlcHRpb25zKSBhcyBhIHBhcnQgb2YNCj4gdGhlIERW QiBBcHBsaWNhdGlvbi1sYXllciBGRUMgc3BlY2lmaWNhdGlvbi4NCj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KPiANCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0Lg0KPiANCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEZlY2ZyYW1l IG1haWxpbmcgbGlzdA0KPiBGZWNmcmFtZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2ZlY2ZyYW1lDQoNCg== ------_=_NextPart_001_01C9C992.AE5F6E58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2NTQuMTIiPg0KPFRJVExFPlJlOiBbRmVjZnJh bWVdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yCWRyYWZ0LWlldGYtZmVjZnJhbWUt aW50ZXJsZWF2ZWQtZmVjLXNjaGVtZS0wNDwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCjwhLS0g Q29udmVydGVkIGZyb20gdGV4dC9wbGFpbiBmb3JtYXQgLS0+DQoNCjxQPjxGT05UIFNJWkU9Mj5I aSBWaW5jZW50PEJSPg0KPEJSPg0KVGhpcyBkcmFmdCBpcyBub3QgYW4gZmVjIHNjaGVtZSBzbyBp dCBpcyBub3QgcmVsYXRlZCB0byBmZWMgZnJhbWV3b3JrLiBJdCBpcyBhbiBydHAgcGF5bG9hZCBm b3JtYXQgZHJhZnQuIFRoZSB3Z2xjIGhhcyBiZWVuIHJ1bm5pbmcgYWxtb3N0IGEgbW9udGggbm93 LiBJZiB5b3UgaGF2ZSBjb21tZW50cyBpbiB0aGlzIHBlcnNwZWN0aXZlLCBwbHMgc3VibWl0IHRo ZW0gc29vbi48QlI+DQo8QlI+DQo8QlI+DQo8QlI+DQo8QlI+DQotYWNiZWdlbjxCUj4NCjxCUj4N Ci0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS08QlI+DQpGcm9tOiBWaW5jZW50IFJvY2EgJmx0 O3ZpbmNlbnQucm9jYUBpbnJpYWxwZXMuZnImZ3Q7PEJSPg0KVG86IEFsaSBDLiBCZWdlbiAoYWJl Z2VuKTxCUj4NCkNjOiBmZWNmcmFtZUBpZXRmLm9yZyAmbHQ7ZmVjZnJhbWVAaWV0Zi5vcmcmZ3Q7 OyBhdnRAaWV0Zi5vcmcgJmx0O2F2dEBpZXRmLm9yZyZndDs8QlI+DQpTZW50OiBUaHUgQXByIDMw IDAzOjU4OjM1IDIwMDk8QlI+DQpTdWJqZWN0OiBSZTogW0ZlY2ZyYW1lXSBGVzogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBkcmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUtMDQ8QlI+DQo8 QlI+DQpIZWxsbyBBbGksPEJSPg0KPEJSPg0KSSdtIG5vdCBpbiBmYXZvciBvZiBmaW5hbGl6aW5n IHRoZSBXR0xDIGZvciB0aGlzIGRvY3VtZW50LiBJTUhPIHdlIG11c3QsPEJSPg0KZmlyc3Qgb2Yg YWxsLCBmaW5hbGl6ZSB0aGUgZnJhbWV3b3JrIGRvY3VtZW50IGl0c2VsZi48QlI+DQo8QlI+DQpG b3IgaW5zdGFuY2UsIHRoZSB0ZXJtaW5vbG9neSB1c2VkIGJ5IHRoZSBpbnRlcmxlYXZlZC1mZWMt c2NoZW1lIEktRDxCUj4NCihzZWN0aW9uIDMuMS4pIGlzIG5vdCBpbiBsaW5lIHdpdGggdGhlIHRl cm1pbm9sb2d5IHVzZWQgYnkgdGhlPEJSPg0KZmVjZnJhbWUtZnJhbWV3b3JrLTAzIEktRCAoU2Vj dGlvbiAyKTo8QlI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg JnF1b3Q7U291cmNlIEZsb3cmcXVvdDsmbmJzcDsmbmJzcDsgdnMuICZxdW90O1NvdXJjZSBkYXRh IGZsb3cmcXVvdDs8QlI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJnF1b3Q7UmVwYWlyIEZsb3cmcXVvdDsmbmJzcDsmbmJzcDsgdnMuICZxdW90O1JlcGFpciBk YXRhIGZsb3cmcXVvdDs8QlI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJnF1b3Q7U291cmNlIFN5bWJvbCZxdW90OyB2cy4gbm90aGluZzxCUj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtSZXBhaXIgU3ltYm9sJnF1 b3Q7IHZzLiBub3RoaW5nPEJSPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZxdW90O1NvdXJjZSBQYWNrZXQmcXVvdDsgdnMuIG5vdGhpbmc8QlI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7UmVwYWlyIFBhY2tldCZx dW90OyB2cy4gbm90aGluZzxCUj4NCkFuZCBhcyBJIHNhaWQgYmVmb3JlLCBJTUhPIHRoZSB0ZXJt aW5vbG9neSBwcm9wb3NlZCBpbiB0aGUgZnJhbWV3b3JrPEJSPg0KSS1EIHNob3VsZCBiZSBkaXNj dXNzZWQgdG9vLjxCUj4NCjxCUj4NClNvIGxldCdzIGRvIHRoaW5ncyBpbiB0aGUgcmlnaHQgb3Jk ZXIsIGVzcGVjaWFsbHkgYXMgdGhlIGZyYW1ld29yazxCUj4NCldHTEMgZmluaXNoZXMgc29vbi48 QlI+DQo8QlI+DQpBZGRpdGlvbmFsbHksIEkgbWF5IGhhdmUgc29tZSBjb21tZW50cyBmb3IgdGhl IGludGVybGVhdmVkLWZlYy1zY2hlbWUtMDQ8QlI+DQpJLUQuIFNpbmNlIEkgbWlzc2VkIHRoZSBX R0xDIGRlYWRsaW5lLCB5b3UgaGF2ZSB0aGUgcmlnaHQgdG8gYmxhbWUgbWUgOy0pPEJSPg0KYW5k IEkgYXBvbG9naXplIGluIGFkdmFuY2UuPEJSPg0KPEJSPg0KUmVnYXJkcyw8QlI+DQo8QlI+DQom bmJzcDsgVmluY2VudDxCUj4NCjxCUj4NCjxCUj4NCkFsaSBDLiBCZWdlbiAoYWJlZ2VuKSB3cm90 ZTo8QlI+DQomZ3Q7IFRoaXMgdmVyc2lvbiBhZGRyZXNzZXMgdGhlIGNvbW1lbnRzIHJlY2VpdmVk IGZyb20gZmVjZnJhbWUgYW5kIGF2dCBzbyBmYXIuPEJSPg0KJmd0OyA8QSBIUkVGPSJodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybGVh dmVkLWZlYy1zY2hlbWUtMDQudHh0Ij5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUtMDQudHh0PC9BPjxC Uj4NCiZndDs8QlI+DQomZ3Q7PEJSPg0KJmd0OyBGZWNmcmFtZSBjaGFpcnMsPEJSPg0KJmd0OzxC Uj4NCiZndDsgQ291bGQgd2UgcHJvY2VlZCBhbmQgZmluYWxpemUgV0dMQz88QlI+DQomZ3Q7PEJS Pg0KJmd0OyAtYWNiZWdlbjxCUj4NCiZndDsmbmJzcDs8QlI+DQomZ3Q7PEJSPg0KJmd0OyAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj4NCiZndDsgRnJvbTogSUVURiBJLUQgU3VibWlzc2lv biBUb29sIFs8QSBIUkVGPSJtYWlsdG86aWRzdWJtaXNzaW9uQGlldGYub3JnIj5tYWlsdG86aWRz dWJtaXNzaW9uQGlldGYub3JnPC9BPl08QlI+DQomZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwg MjksIDIwMDkgMjo1NiBQTTxCUj4NCiZndDsgVG86IEFsaSBDLiBCZWdlbiAoYWJlZ2VuKTxCUj4N CiZndDsgU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWZl Y2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUtMDQ8QlI+DQomZ3Q7PEJSPg0KJmd0OzxCUj4N CiZndDsgQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtZmVjZnJhbWUtaW50ZXJsZWF2 ZWQtZmVjLXNjaGVtZS0wNC50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bHkgc3VibWl0dGVkIGJ5IEFs aSBCZWdlbiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuPEJSPg0KJmd0OzxCUj4N CiZndDsgRmlsZW5hbWU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LWlldGYt ZmVjZnJhbWUtaW50ZXJsZWF2ZWQtZmVjLXNjaGVtZTxCUj4NCiZndDsgUmV2aXNpb246Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDA0PEJSPg0KJmd0OyBUaXRsZTombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJUUCBQYXlsb2FkIEZvcm1hdCBmb3IgMS1EIEludGVybGVh dmVkIFBhcml0eSBGRUM8QlI+DQomZ3Q7IENyZWF0aW9uX2RhdGU6Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIwMDktMDQtMjk8QlI+DQomZ3Q7IFdHIElE OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZmVjZnJhbWU8QlI+DQomZ3Q7IE51 bWJlcl9vZl9wYWdlczogMzE8QlI+DQomZ3Q7PEJSPg0KJmd0OyBBYnN0cmFjdDo8QlI+DQomZ3Q7 IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBSVFAgcGF5bG9hZCBmb3JtYXQgZm9yIHRoZSBG b3J3YXJkIEVycm9yPEJSPg0KJmd0OyBDb3JyZWN0aW9uIChGRUMpIHRoYXQgaXMgZ2VuZXJhdGVk IGJ5IHRoZSAxLUQgaW50ZXJsZWF2ZWQgcGFyaXR5IGNvZGU8QlI+DQomZ3Q7IGZyb20gYSBzb3Vy Y2UgbWVkaWEgZW5jYXBzdWxhdGVkIGluIFJUUC4mbmJzcDsgVGhlIDEtRCBpbnRlcmxlYXZlZCBw YXJpdHk8QlI+DQomZ3Q7IGNvZGUgaXMgYSBzeXN0ZW1hdGljIGNvZGUsIHdoZXJlIGEgbnVtYmVy IG9mIHJlcGFpciBzeW1ib2xzIGFyZTxCUj4NCiZndDsgZ2VuZXJhdGVkIGZyb20gYSBzZXQgb2Yg c291cmNlIHN5bWJvbHMgYW5kIHNlbnQgaW4gYSByZXBhaXIgZmxvdzxCUj4NCiZndDsgc2VwYXJh dGUgZnJvbSB0aGUgc291cmNlIGZsb3cgdGhhdCBjYXJyaWVzIHRoZSBzb3VyY2Ugc3ltYm9scy4m bmJzcDsgVGhlPEJSPg0KJmd0OyAxLUQgaW50ZXJsZWF2ZWQgcGFyaXR5IGNvZGUgb2ZmZXJzIGEg Z29vZCBwcm90ZWN0aW9uIGFnYWluc3QgYnVyc3R5PEJSPg0KJmd0OyBwYWNrZXQgbG9zc2VzIGF0 IGEgY29zdCBvZiBkZWNlbnQgY29tcGxleGl0eS4mbmJzcDsgVGhlIG5ldyBwYXlsb2FkIGZvcm1h dDxCUj4NCiZndDsgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGlzIHVzZWQgKHdpdGggc29tZSBl eGNlcHRpb25zKSBhcyBhIHBhcnQgb2Y8QlI+DQomZ3Q7IHRoZSBEVkIgQXBwbGljYXRpb24tbGF5 ZXIgRkVDIHNwZWNpZmljYXRpb24uPEJSPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxCUj4NCiZndDs8QlI+DQomZ3Q7PEJSPg0KJmd0OyBUaGUgSUVURiBTZWNyZXRh cmlhdC48QlI+DQomZ3Q7PEJSPg0KJmd0OzxCUj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188QlI+DQomZ3Q7IEZlY2ZyYW1lIG1haWxpbmcgbGlz dDxCUj4NCiZndDsgRmVjZnJhbWVAaWV0Zi5vcmc8QlI+DQomZ3Q7IDxBIEhSRUY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZmVjZnJhbWUiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZmVjZnJhbWU8L0E+PEJSPg0KPEJSPg0KPC9GT05UPg0KPC9Q Pg0KDQo8L0JPRFk+DQo8L0hUTUw+ ------_=_NextPart_001_01C9C992.AE5F6E58-- From tme@americafree.tv Thu Apr 30 06:44:50 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 537563A7217; Thu, 30 Apr 2009 06:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599] 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 myW3Rytzr5ZV; Thu, 30 Apr 2009 06:44:49 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id E1EE73A6B33; Thu, 30 Apr 2009 06:44:48 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id ABA943B3849F; Thu, 30 Apr 2009 09:46:11 -0400 (EDT) Message-Id: <4DBD8549-69B5-440B-8ED3-71B7469BFAAD@americafree.tv> From: Marshall Eubanks To: "Ali C. Begen (abegen)" In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 30 Apr 2009 09:46:10 -0400 References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: fecframe@ietf.org, avt@ietf.org Subject: Re: [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 13:44:50 -0000 On Apr 30, 2009, at 8:53 AM, Ali C. Begen (abegen) wrote: > Hi Vincent > > This draft is not an fec scheme so it is not related to fec > framework. It is an rtp payload format draft. The wglc has been > running almost a month now. If you have comments in this > perspective, pls submit them soon. > > I was about to close this WGLC, but we can wait a short while for new comments. Marshall > > > > -acbegen > > ----- Original Message ----- > From: Vincent Roca > To: Ali C. Begen (abegen) > Cc: fecframe@ietf.org ; avt@ietf.org > Sent: Thu Apr 30 03:58:35 2009 > Subject: Re: [Fecframe] FW: New Version Notification for > draft-ietf-fecframe-interleaved-fec-scheme-04 > > Hello Ali, > > I'm not in favor of finalizing the WGLC for this document. IMHO we > must, > first of all, finalize the framework document itself. > > For instance, the terminology used by the interleaved-fec-scheme I-D > (section 3.1.) is not in line with the terminology used by the > fecframe-framework-03 I-D (Section 2): > "Source Flow" vs. "Source data flow" > "Repair Flow" vs. "Repair data flow" > "Source Symbol" vs. nothing > "Repair Symbol" vs. nothing > "Source Packet" vs. nothing > "Repair Packet" vs. nothing > And as I said before, IMHO the terminology proposed in the framework > I-D should be discussed too. > > So let's do things in the right order, especially as the framework > WGLC finishes soon. > > Additionally, I may have some comments for the interleaved-fec- > scheme-04 > I-D. Since I missed the WGLC deadline, you have the right to blame > me ;-) > and I apologize in advance. > > Regards, > > Vincent > > > Ali C. Begen (abegen) wrote: > > This version addresses the comments received from fecframe and avt > so far. > > http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interleaved-fec-scheme-04.txt > > > > > > Fecframe chairs, > > > > Could we proceed and finalize WGLC? > > > > -acbegen > > > > > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > Sent: Wednesday, April 29, 2009 2:56 PM > > To: Ali C. Begen (abegen) > > Subject: New Version Notification for draft-ietf-fecframe- > interleaved-fec-scheme-04 > > > > > > A new version of I-D, draft-ietf-fecframe-interleaved-fec- > scheme-04.txt has been successfuly submitted by Ali Begen and posted > to the IETF repository. > > > > Filename: draft-ietf-fecframe-interleaved-fec-scheme > > Revision: 04 > > Title: RTP Payload Format for 1-D Interleaved > Parity FEC > > Creation_date: 2009-04-29 > > WG ID: fecframe > > Number_of_pages: 31 > > > > Abstract: > > This document defines a new RTP payload format for the Forward Error > > Correction (FEC) that is generated by the 1-D interleaved parity > code > > from a source media encapsulated in RTP. The 1-D interleaved parity > > code is a systematic code, where a number of repair symbols are > > generated from a set of source symbols and sent in a repair flow > > separate from the source flow that carries the source symbols. The > > 1-D interleaved parity code offers a good protection against bursty > > packet losses at a cost of decent complexity. The new payload > format > > defined in this document is used (with some exceptions) as a part of > > the DVB Application-layer FEC specification. > > > > > > > > The IETF Secretariat. > > > > > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe Regards Marshall Eubanks CEO / AmericaFree.TV From tme@multicasttech.com Thu Apr 30 06:50:40 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A67C3A6E09; Thu, 30 Apr 2009 06:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.939 X-Spam-Level: X-Spam-Status: No, score=-102.939 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 aVeqJKxHLJ7H; Thu, 30 Apr 2009 06:50:37 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id AFC3C3A6F55; Thu, 30 Apr 2009 06:50:36 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 6DB1F3B38776; Thu, 30 Apr 2009 09:51:59 -0400 (EDT) Message-Id: From: Marshall Eubanks To: "Ali C. Begen (abegen)" In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 30 Apr 2009 09:51:59 -0400 References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: fecframe@ietf.org, avt@ietf.org Subject: Re: [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 13:50:40 -0000 On Apr 30, 2009, at 8:53 AM, Ali C. Begen (abegen) wrote: > Hi Vincent > > This draft is not an fec scheme so it is not related to fec > framework. It is an rtp payload format draft. The wglc has been > running almost a month now. If you have comments in this > perspective, pls submit them soon. > > I was about to close this WGLC, but we can wait a short while for new comments. Marshall > > > > -acbegen > > ----- Original Message ----- > From: Vincent Roca > To: Ali C. Begen (abegen) > Cc: fecframe@ietf.org ; avt@ietf.org > Sent: Thu Apr 30 03:58:35 2009 > Subject: Re: [Fecframe] FW: New Version Notification for > draft-ietf-fecframe-interleaved-fec-scheme-04 > > Hello Ali, > > I'm not in favor of finalizing the WGLC for this document. IMHO we > must, > first of all, finalize the framework document itself. > > For instance, the terminology used by the interleaved-fec-scheme I-D > (section 3.1.) is not in line with the terminology used by the > fecframe-framework-03 I-D (Section 2): > "Source Flow" vs. "Source data flow" > "Repair Flow" vs. "Repair data flow" > "Source Symbol" vs. nothing > "Repair Symbol" vs. nothing > "Source Packet" vs. nothing > "Repair Packet" vs. nothing > And as I said before, IMHO the terminology proposed in the framework > I-D should be discussed too. > > So let's do things in the right order, especially as the framework > WGLC finishes soon. > > Additionally, I may have some comments for the interleaved-fec- > scheme-04 > I-D. Since I missed the WGLC deadline, you have the right to blame > me ;-) > and I apologize in advance. > > Regards, > > Vincent > > > Ali C. Begen (abegen) wrote: > > This version addresses the comments received from fecframe and avt > so far. > > http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interleaved-fec-scheme-04.txt > > > > > > Fecframe chairs, > > > > Could we proceed and finalize WGLC? > > > > -acbegen > > > > > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > Sent: Wednesday, April 29, 2009 2:56 PM > > To: Ali C. Begen (abegen) > > Subject: New Version Notification for draft-ietf-fecframe- > interleaved-fec-scheme-04 > > > > > > A new version of I-D, draft-ietf-fecframe-interleaved-fec- > scheme-04.txt has been successfuly submitted by Ali Begen and posted > to the IETF repository. > > > > Filename: draft-ietf-fecframe-interleaved-fec-scheme > > Revision: 04 > > Title: RTP Payload Format for 1-D Interleaved > Parity FEC > > Creation_date: 2009-04-29 > > WG ID: fecframe > > Number_of_pages: 31 > > > > Abstract: > > This document defines a new RTP payload format for the Forward Error > > Correction (FEC) that is generated by the 1-D interleaved parity > code > > from a source media encapsulated in RTP. The 1-D interleaved parity > > code is a systematic code, where a number of repair symbols are > > generated from a set of source symbols and sent in a repair flow > > separate from the source flow that carries the source symbols. The > > 1-D interleaved parity code offers a good protection against bursty > > packet losses at a cost of decent complexity. The new payload > format > > defined in this document is used (with some exceptions) as a part of > > the DVB Application-layer FEC specification. > > > > > > > > The IETF Secretariat. > > > > > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe Regards Marshall Eubanks CEO / AmericaFree.TV From mathieu.cunche@inrialpes.fr Thu Apr 30 07:43:45 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BF033A6F97 for ; Thu, 30 Apr 2009 07:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 YI60kwyGxjqr for ; Thu, 30 Apr 2009 07:43:43 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id 49FC03A7179 for ; Thu, 30 Apr 2009 07:43:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,431,1233529200"; d="scan'208";a="28552748" Received: from denver.inrialpes.fr (HELO [194.199.24.123]) ([194.199.24.123]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2009 16:45:04 +0200 Message-ID: <49F9B97B.6050705@inrialpes.fr> Date: Thu, 30 Apr 2009 16:45:15 +0200 From: Mathieu Cunche User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <49F8438F.3090307@inrialpes.fr> <04CAD96D4C5A3D48B1919248A8FE0D5409348D62@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5409348D62@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: alice.albano@inrialpes.fr, fecframe@ietf.org Subject: Re: [Fecframe] Remark on the textual representation of FSSI fields X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 14:43:45 -0000 Hi Ali, Thanks for the link. To summarize this 2007 discussion, there are basically two issues: - Does the FSSI need to be encoded into human-readable form or not? Compactness is not an issue. We agree. Having a human readable encoding can ease debugging. We agree. SDP is only one possible way of carrying the FSSI, and we must not restrict the kind of signaling mechanism. We agree. - Where should this encoding be specified? Quoting Mark: "It is the responsibility of the FEC Scheme specification to define the contents of the Scheme-specific information and the responsibility of the CDP specification to specify how it is carried in a protocol." However, there is no clear conclusion on this point. (Don't hesitate to correct us if we missed/misunderstood something) In any case, the issue must be fixed, since: - arbitrary binary content (like FSSI) cannot be directly represented in SDP - current I-Ds already use different assumptions - none of them specifies what should be done, worse they contradict one another More specifically: SDP elem => "octet string", without precision, and examples are provided: ss-fssi=1Q2A3Z; fssi=4W5S6X raptor => not specified, but the example: ss-fssi=5hu= suggests Base64 is used Concerning point 1, we have several possibilities: - use base64: its compactness is not an asset in this case, but it remains simple and well known. - use hexadecimal: it's much more user friendly than base64 encoding, especially with a structured FSSI. - use an ASCII encoding of the whole FSSI value: for instance, with an FSSI composed of two 16bit fields, containing 10 and 8 respectively, the whole FSSI value is: 00001010 00001000 (bin) = 2568 (dec), encoded as the ASCII string "fssi=2568" This is a bit tricky however! - another ASCII alternative is to carry the ASCII string for each FSSI internal field, separated by a comma (for instance). With the above example: "fssi=10,8" Simple, human readable, but no longer opaque and rather tricky! One open question: does SDP have any mechanism to specify, within the SDP file itself, the encoding used for the binary->textual transformation. Eg., a way to say that what follows is in hexadecimal or is base64 encoded? If this is permitted, this encoding can be left unspecified with SDP. In case of another protocol, an explicit rule can be defined if need be. Concerning point 2, our feeling is that the encoding of the FSSI should be defined in the SDP Element, i.e., where it is used. Regards, Mathieu, Alice and Vincent Ali C. Begen (abegen) wrote: > Hi Mathieu, > > Thanks for bringing this up. My feeling is that the FEC scheme drafts should define the content of the FSSI information (i.e., what needs to go in there) but they do not normally need to define how the FSSI should be encoded in the SDP since FEC schemes may use other ways to convey the configuration information. However, if a scheme uses RTP, we clearly need the SDP encodings for that scheme as RTP will imply using SDP. > > For the encoding in SDP, we could use base64 as the default format. However, this has the disadvantage of not being human-readable. When we consider RTCP instrumentation in the middle boxes in the network, the opaque data is not a good idea, either. Just because it saves some bits won't make it an ideal encoding format. So, personally I prefer ascii. And when I look at most other formatting parameters (like the ones for RTP), they are all ascii. > > There are certain semantics that are not scheme specific, and they should be in ascii format in the SDP (like a=repair-window) anyway. > > We had a similar discussion in 2007. Look at the archives here: > http://www.ietf.org/mail-archive/web/fecframe-proto/current/mail7.html > > Comments? > > -acbegen > > >> -----Original Message----- >> From: fecframe-bounces@ietf.org >> [mailto:fecframe-bounces@ietf.org] On Behalf Of Mathieu Cunche >> Sent: Wednesday, April 29, 2009 5:10 AM >> To: fecframe@ietf.org >> Cc: alice.albano@inrialpes.fr >> Subject: [Fecframe] Remark on the textual representation of >> FSSI fields >> >> Hello everybody, >> >> We have a remark on the the way the FSSI (FEC Scheme-Specific >> Information) and the SS-FSSI (Sender-Side FSSI) binary fields >> are converted into a character string for SDP. >> In fact we haven't found any specification in the various >> FECFRAME I-Ds on the way this conversion should be done. >> >> From RFC4566 "Session Description Protocol", p.33: >> "Encoding considerations: >> SDP files are primarily UTF-8 format text. The "a=charset:" >> attribute may be used to signal the presence of other >> character sets in certain parts of an SDP file (see >> Section 6 of RFC 4566 >> ). Arbitrary >> binary content cannot be directly represented in SDP." >> >> We are typically in the case where we need a textual encoding >> of the binary SS-FSSI/FSSI "octet string". >> >> In the SDP example provided in draft-ietf-fecframe-raptor-00 >> (section 10) it seems that the encoding used is Base64. However >> this is never explicitly said (!), neither in this I-D nor in >> any other I-D (see extracts at the end of the email). >> ----------- >> [...] >> a=fec-repair-flow: scheme-id=0; ss-fssi=5hu= >> ------------ >> (BTW: the above SDP description is erroneous, since SS-FSSI >> is never defined elsewhere in this I-D and on the opposite >> the FSSI is missing) >> >> >> Base64 seems to be the best solution (more compact than >> an hexadecimal string). Should this encoding be definitively >> adopted? And in this case, where should it be specified? >> >> Our feeling is that: >> - it should be clarified in each FEC scheme document (as >> is the case with RFC 5170/4.2.4.2 (LDPC) and >> RFC 5510/4.2.4.2 (Reed-Solomon)), when a textual encoding >> is needed for the "octet string"; >> >> - it should be specified in the sdp-elements I-D, section 3.3. >> as well. >> >> Regards, >> >> >> Mathieu, Alice and Vincent >> >> NB: here are the I-D extracts that mention SS-FSSI and FSSI: >> >> ------------ >> >> >> * SDP Elements for FEC Framework >> (draft-ietf-fecframe-sdp-elements-02): >> >> - page 6: "The variable-length opaque SS-FSSI and FSSI containers >> transmit the information in the form of an octet string. The FEC >> schemes define the structure of this octet string, which >> may contain >> multiple distinct elements." >> >> - page 10: " The OPTIONAL parameters 'ss-fssi' and 'fssi' >> are opaque >> containers to convey the FEC-Scheme-Specific Information >> (FSSI) that >> includes the information that is specific to the FEC >> scheme used by >> the CDP and is necessary for proper FEC encoding and decoding >> operations. The FSSI required only by the sender (called >> Sender-Side FSSI) MUST be communicated in the container >> specified by >> the parameter 'ss-fssi'. Any other FSSI MUST be >> communicated in the >> container specified by the parameter 'fssi'. In both containers, >> FSSI is transmitted in the form of an octet string. The >> FEC schemes >> define the structure of this octet string, which MAY contain >> multiple distinct elements. If the FEC scheme does not >> require any >> specific information, the 'ss-fssi' and 'fssi' parameters MAY be >> null and ignored." >> >> MC => this text should be fixed since "transmitting the FSSI >> in the form >> of an octet string" is not possible. >> >> >> * Methods to convey FEC Framework Configuration Information >> (draft-ietf-fecframe-config-signaling-01.txt) >> >> - page 5: "Additionally, the encoding format for each FEC >> Framework >> configuration parameter must be defined in terms of a sequence of >> octets that can be embedded within the payload of the signaling >> protocol message(s). The length of the encoding format >> MUST either >> be fixed, or derived by examining the encoded octets themselves. >> For example, the initial octets may include some kind of length >> indication. [...]The reader may refer to the SDP elements document >> [FECSDP], which describes the usage of 'SDP' encoding format as an >> example encoding format for FEC framework configuration >> information." >> >> MC => with Base64 encoding, there is no need to add any "initial octet >> to include a length indication". It's the goal of the final "=" >> or "==" characters. >> >> >> * Raptor FEC Schemes for FECFRAME (draft-ietf-fecframe-raptor-00) >> >> - page 8: "The scheme-specific elements of the FEC Framework >> Configuration information for this scheme are as follows: >> Maximum Source Block Length A non-negative integer less than 213, >> in units of symbols >> Encoding Symbol Size A non-negative integer less than 216, in >> units of bytes >> An encoding format for this information in a 4 octet field is >> defined as follows: >> >> 1 2 >> 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 >> 5 6 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Symbol Size (T) | Max. Source >> Block Length | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure 1: FEC Scheme Specific Information >> >> MC => the "encoding format" here refers to the binary encoding, not >> the final encoding to be used when this binary encoding must >> be carried in SDP or any textual representation. >> >> >> * And of course, we need to fix our Reed-Solomon I-D too... >> >> >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe >> >> > > > From abegen@cisco.com Thu Apr 30 09:45:16 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 116663A68AF for ; Thu, 30 Apr 2009 09:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.364 X-Spam-Level: X-Spam-Status: No, score=-6.364 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 lnZ4PytyblDs for ; Thu, 30 Apr 2009 09:45:14 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4C9073A6917 for ; Thu, 30 Apr 2009 09:45:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,273,1238976000"; d="scan'208";a="295950589" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 30 Apr 2009 16:46:37 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3UGkbst014498; Thu, 30 Apr 2009 09:46:37 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3UGkbij025195; Thu, 30 Apr 2009 16:46:37 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 09:46:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Apr 2009 09:44:40 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540934902C@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49F9B97B.6050705@inrialpes.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Remark on the textual representation of FSSI fields Thread-Index: AcnJokSIKRDNxVJDTu6vOjdfjR0DWgAD5SmA References: <49F8438F.3090307@inrialpes.fr> <04CAD96D4C5A3D48B1919248A8FE0D5409348D62@xmb-sjc-215.amer.cisco.com> <49F9B97B.6050705@inrialpes.fr> From: "Ali C. Begen (abegen)" To: "Mathieu Cunche" X-OriginalArrivalTime: 30 Apr 2009 16:46:37.0131 (UTC) FILETIME=[3A4E51B0:01C9C9B3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11867; t=1241109997; x=1241973997; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[Fecframe]=20Remark=20on=20the=20textua l=20representation=20of=20FSSI=20fields |Sender:=20; bh=U4Ro7QfC1CoIjft4FE/NnwL+gLw+PQVwy6x5siUAxew=; b=nip2QVLQaalFUq15bBp0E96+9u2r+CBFNsPNluDBAXp+QKNgIVT6Qlluy0 Wtzr+y8+/hVefvNmdG3jIExyYTv1poWWusmqg52IV27nh3QLXcuUE3jv8R1L 7htAxlvUI3EU3yRA/3Dc0PNZ6oS8ARgvBTRqGDySxneMQOG/g1UvE=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: alice.albano@inrialpes.fr, fecframe@ietf.org Subject: Re: [Fecframe] Remark on the textual representation of FSSI fields X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 16:45:16 -0000 Hi Mathieu, Inline. > -----Original Message----- > From: Mathieu Cunche [mailto:mathieu.cunche@inrialpes.fr]=20 > Sent: Thursday, April 30, 2009 7:45 AM > To: Ali C. Begen (abegen) > Cc: fecframe@ietf.org; alice.albano@inrialpes.fr > Subject: Re: [Fecframe] Remark on the textual representation=20 > of FSSI fields >=20 > Hi Ali, >=20 > Thanks for the link. To summarize this 2007 discussion, there are > basically two issues: >=20 > - Does the FSSI need to be encoded into human-readable form or not? >=20 > Compactness is not an issue. We agree. > Having a human readable encoding can ease debugging. We agree. > SDP is only one possible way of carrying the FSSI, and we > must not restrict the kind of signaling mechanism. We agree. Yup. =20 > - Where should this encoding be specified? >=20 > Quoting Mark: > "It is the responsibility of the FEC Scheme specification > to define the contents of the Scheme-specific information > and the responsibility of the CDP specification to specify > how it is carried in a protocol." > However, there is no clear conclusion on this point. I will let Mark comment on this one. I agree with the earlier part = (defining the contens of the SSI). =20 > (Don't hesitate to correct us if we missed/misunderstood something) >=20 >=20 > In any case, the issue must be fixed, since: > - arbitrary binary content (like FSSI) cannot be directly represented > in SDP > - current I-Ds already use different assumptions > - none of them specifies what should be done, worse they contradict > one another Yes, we need to make a decision. > More specifically: > SDP elem =3D> "octet string", without precision, and examples > are provided: ss-fssi=3D1Q2A3Z; fssi=3D4W5S6X > raptor =3D> not specified, but the example: ss-fssi=3D5hu=3D > suggests Base64 is used >=20 >=20 > Concerning point 1, we have several possibilities: > - use base64: its compactness is not an asset in this case, but > it remains simple and well known. >=20 > - use hexadecimal: it's much more user friendly than base64 > encoding, especially with a structured FSSI. >=20 > - use an ASCII encoding of the whole FSSI value: for instance, > with an FSSI composed of two 16bit fields, containing 10 and 8 > respectively, the whole FSSI value is: > 00001010 00001000 (bin) =3D 2568 (dec), encoded as the ASCII > string "fssi=3D2568" > This is a bit tricky however! >=20 > - another ASCII alternative is to carry the ASCII string for each > FSSI internal field, separated by a comma (for instance). > With the above example: "fssi=3D10,8" > Simple, human readable, but no longer opaque and rather tricky! We need input from the WG on this as it will apply to almost all drafts. > One open question: does SDP have any mechanism to specify, within > the SDP file itself, the encoding used for the binary->textual > transformation. Eg., a way to say that what follows is in hexadecimal > or is base64 encoded? If this is permitted, this encoding can be > left unspecified with SDP. In case of another protocol, an explicit > rule can be defined if need be. I'd think this is possible based on the text you cited yesterday, but I = am not sure. =20 =20 > Concerning point 2, our feeling is that the encoding of the FSSI > should be defined in the SDP Element, i.e., where it is used. Agree, I will update the draft once we reach a consensus here. To do = that, we need to hear from FECframe folks. And this discussion is really = overdue. BR, -acbegen =20 >=20 > Regards, >=20 > Mathieu, Alice and Vincent >=20 >=20 >=20 > Ali C. Begen (abegen) wrote: > > Hi Mathieu, > > > > Thanks for bringing this up. My feeling is that the FEC=20 > scheme drafts should define the content of the FSSI=20 > information (i.e., what needs to go in there) but they do not=20 > normally need to define how the FSSI should be encoded in the=20 > SDP since FEC schemes may use other ways to convey the=20 > configuration information. However, if a scheme uses RTP, we=20 > clearly need the SDP encodings for that scheme as RTP will=20 > imply using SDP. > > > > For the encoding in SDP, we could use base64 as the default=20 > format. However, this has the disadvantage of not being=20 > human-readable. When we consider RTCP instrumentation in the=20 > middle boxes in the network, the opaque data is not a good=20 > idea, either. Just because it saves some bits won't make it=20 > an ideal encoding format. So, personally I prefer ascii. And=20 > when I look at most other formatting parameters (like the=20 > ones for RTP), they are all ascii. > > > > There are certain semantics that are not scheme specific,=20 > and they should be in ascii format in the SDP (like=20 > a=3Drepair-window) anyway. > > > > We had a similar discussion in 2007. Look at the archives here: > >=20 > http://www.ietf.org/mail-archive/web/fecframe-proto/current/mail7.html > > > > Comments? > > > > -acbegen > > > > =20 > >> -----Original Message----- > >> From: fecframe-bounces@ietf.org=20 > >> [mailto:fecframe-bounces@ietf.org] On Behalf Of Mathieu Cunche > >> Sent: Wednesday, April 29, 2009 5:10 AM > >> To: fecframe@ietf.org > >> Cc: alice.albano@inrialpes.fr > >> Subject: [Fecframe] Remark on the textual representation of=20 > >> FSSI fields > >> > >> Hello everybody, > >> > >> We have a remark on the the way the FSSI (FEC Scheme-Specific > >> Information) and the SS-FSSI (Sender-Side FSSI) binary fields > >> are converted into a character string for SDP. > >> In fact we haven't found any specification in the various > >> FECFRAME I-Ds on the way this conversion should be done. > >> > >> From RFC4566 "Session Description Protocol", p.33: > >> "Encoding considerations: > >> SDP files are primarily UTF-8 format text. The "a=3Dcharset:" > >> attribute may be used to signal the presence of other > >> character sets in certain parts of an SDP file (see > >> Section 6 of RFC 4566 > >> ). Arbitrary > >> binary content cannot be directly represented in SDP." > >> > >> We are typically in the case where we need a textual encoding > >> of the binary SS-FSSI/FSSI "octet string". > >> > >> In the SDP example provided in draft-ietf-fecframe-raptor-00 > >> (section 10) it seems that the encoding used is Base64. However > >> this is never explicitly said (!), neither in this I-D nor in > >> any other I-D (see extracts at the end of the email). > >> ----------- > >> [...] > >> a=3Dfec-repair-flow: scheme-id=3D0; ss-fssi=3D5hu=3D > >> ------------ > >> (BTW: the above SDP description is erroneous, since SS-FSSI > >> is never defined elsewhere in this I-D and on the opposite > >> the FSSI is missing) > >> > >> > >> Base64 seems to be the best solution (more compact than > >> an hexadecimal string). Should this encoding be definitively > >> adopted? And in this case, where should it be specified? > >> > >> Our feeling is that: > >> - it should be clarified in each FEC scheme document (as > >> is the case with RFC 5170/4.2.4.2 (LDPC) and > >> RFC 5510/4.2.4.2 (Reed-Solomon)), when a textual encoding > >> is needed for the "octet string"; > >> > >> - it should be specified in the sdp-elements I-D, section 3.3. > >> as well. > >> > >> Regards, > >> > >> > >> Mathieu, Alice and Vincent > >> > >> NB: here are the I-D extracts that mention SS-FSSI and FSSI: > >> > >> ------------ > >> > >> > >> * SDP Elements for FEC Framework=20 > >> (draft-ietf-fecframe-sdp-elements-02): > >> > >> - page 6: "The variable-length opaque SS-FSSI and FSSI=20 > containers > >> transmit the information in the form of an octet=20 > string. The FEC > >> schemes define the structure of this octet string, which=20 > >> may contain > >> multiple distinct elements." > >> > >> - page 10: " The OPTIONAL parameters 'ss-fssi' and 'fssi'=20 > >> are opaque > >> containers to convey the FEC-Scheme-Specific Information=20 > >> (FSSI) that > >> includes the information that is specific to the FEC=20 > >> scheme used by > >> the CDP and is necessary for proper FEC encoding and decoding > >> operations. The FSSI required only by the sender (called > >> Sender-Side FSSI) MUST be communicated in the container=20 > >> specified by > >> the parameter 'ss-fssi'. Any other FSSI MUST be=20 > >> communicated in the > >> container specified by the parameter 'fssi'. In both=20 > containers, > >> FSSI is transmitted in the form of an octet string. The=20 > >> FEC schemes > >> define the structure of this octet string, which MAY contain > >> multiple distinct elements. If the FEC scheme does not=20 > >> require any > >> specific information, the 'ss-fssi' and 'fssi'=20 > parameters MAY be > >> null and ignored." > >> > >> MC =3D> this text should be fixed since "transmitting the FSSI=20 > >> in the form > >> of an octet string" is not possible. > >> > >> > >> * Methods to convey FEC Framework Configuration Information > >> (draft-ietf-fecframe-config-signaling-01.txt) > >> > >> - page 5: "Additionally, the encoding format for each FEC=20 > >> Framework > >> configuration parameter must be defined in terms of a=20 > sequence of > >> octets that can be embedded within the payload of the signaling > >> protocol message(s). The length of the encoding format=20 > >> MUST either > >> be fixed, or derived by examining the encoded octets=20 > themselves. > >> For example, the initial octets may include some kind of length > >> indication. [...]The reader may refer to the SDP=20 > elements document > >> [FECSDP], which describes the usage of 'SDP' encoding=20 > format as an > >> example encoding format for FEC framework configuration=20 > >> information." > >> > >> MC =3D> with Base64 encoding, there is no need to add any=20 > "initial octet > >> to include a length indication". It's the goal of=20 > the final "=3D" > >> or "=3D=3D" characters. > >> > >> > >> * Raptor FEC Schemes for FECFRAME (draft-ietf-fecframe-raptor-00) > >> > >> - page 8: "The scheme-specific elements of the FEC Framework > >> Configuration information for this scheme are as follows: > >> Maximum Source Block Length A non-negative integer=20 > less than 213, > >> in units of symbols > >> Encoding Symbol Size A non-negative integer less than 216, in > >> units of bytes > >> An encoding format for this information in a 4 octet field is > >> defined as follows: > >> > >> 1 2 =20 > >> 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4=20 > >> 5 6 7 8 9 0 1 > >> =20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Symbol Size (T) | Max. Source=20 > >> Block Length | > >> =20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> Figure 1: FEC Scheme Specific Information > >> > >> MC =3D> the "encoding format" here refers to the binary encoding, = not > >> the final encoding to be used when this binary encoding must > >> be carried in SDP or any textual representation. > >> > >> > >> * And of course, we need to fix our Reed-Solomon I-D too... > >> > >> > >> _______________________________________________ > >> Fecframe mailing list > >> Fecframe@ietf.org > >> https://www.ietf.org/mailman/listinfo/fecframe > >> > >> =20 > > > > > > =20 >=20 >=20 From ron.even.tlv@gmail.com Thu Apr 30 11:13:08 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F27D13A6FBB; Thu, 30 Apr 2009 11:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.767 X-Spam-Level: X-Spam-Status: No, score=-1.767 tagged_above=-999 required=5 tests=[AWL=0.831, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 OGZOscjyaU-A; Thu, 30 Apr 2009 11:13:06 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 0D5B23A6DF6; Thu, 30 Apr 2009 11:13:05 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so1935537fgb.18 for ; Thu, 30 Apr 2009 11:14:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=BusdFcJaTU4Yd/j/C0GxMcxo6I+Ij6l7/ZGoTIionTA=; b=RdnXR3Dsfh6h+BaQTu5Mc9LbQURdtjmKK7yuHfOB1DOtzZTjckyoVqDNZRx2+WDsNe Bm3hiNRqjgwEmMSt6Tcf2PILlmQWBQ2XzrcW9s2ESGC9Ttuwp3HMsTiRKKzzdEMIC24a 9ulzDG/duCvctyt2UxTBd3xLWl8dh2eLTtZtQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; b=GcHBZrI6zH2UBIvpqQVJK/BgwKy0bRJiKlX8alZGQ9qcI0JhaE1jCdCJTmO3B1jqOO TRX2gyEW8XjoG06OT7gth3wZfAetd5yVbMPB+hZnQpqmwA8/LXXZMYStxHiVsF7xlbKa XB9O3eDk9uDFXTpJ6naUj5a98ST0TbSo3txEQ= Received: by 10.86.92.9 with SMTP id p9mr2115315fgb.15.1241115267815; Thu, 30 Apr 2009 11:14:27 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-57-219.red.bezeqint.net [79.177.57.219]) by mx.google.com with ESMTPS id d6sm4029458fga.22.2009.04.30.11.14.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Apr 2009 11:14:27 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> Date: Thu, 30 Apr 2009 21:12:21 +0300 Message-ID: <49f9ea83.0637560a.4488.62d2@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B3_01C9C9D8.636879C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnJgq+DQP1j7cRATQa6PC9zcfp8gAAD/6reAAsScqA= Content-Language: en-us Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 18:13:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B3_01C9C9D8.636879C0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ali, I noticed that the fec framework will allow SSRC multiplexing, are you = going to specify this in this draft in the SDP offer answer section.=20 Maybe you should also discuss when to use application media type and = when to use video or audio =20 Roni =20 From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Ali C. Begen (abegen) Sent: Thursday, April 30, 2009 3:54 PM To: vincent.roca@inrialpes.fr Cc: avt@ietf.org; fecframe@ietf.org Subject: Re: [AVT] [Fecframe] FW: New Version Notification for = draft-ietf-fecframe-interleaved-fec-scheme-04 =20 Hi Vincent This draft is not an fec scheme so it is not related to fec framework. = It is an rtp payload format draft. The wglc has been running almost a = month now. If you have comments in this perspective, pls submit them = soon. -acbegen ----- Original Message ----- From: Vincent Roca To: Ali C. Begen (abegen) Cc: fecframe@ietf.org ; avt@ietf.org Sent: Thu Apr 30 03:58:35 2009 Subject: Re: [Fecframe] FW: New Version Notification for = draft-ietf-fecframe-interleaved-fec-scheme-04 Hello Ali, I'm not in favor of finalizing the WGLC for this document. IMHO we must, first of all, finalize the framework document itself. For instance, the terminology used by the interleaved-fec-scheme I-D (section 3.1.) is not in line with the terminology used by the fecframe-framework-03 I-D (Section 2): "Source Flow" vs. "Source data flow" "Repair Flow" vs. "Repair data flow" "Source Symbol" vs. nothing "Repair Symbol" vs. nothing "Source Packet" vs. nothing "Repair Packet" vs. nothing And as I said before, IMHO the terminology proposed in the framework I-D should be discussed too. So let's do things in the right order, especially as the framework WGLC finishes soon. Additionally, I may have some comments for the interleaved-fec-scheme-04 I-D. Since I missed the WGLC deadline, you have the right to blame me = ;-) and I apologize in advance. Regards, Vincent Ali C. Begen (abegen) wrote: > This version addresses the comments received from fecframe and avt so = far. > = http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interleaved-fec-s= cheme-04.txt > > > Fecframe chairs, > > Could we proceed and finalize WGLC? > > -acbegen >=20 > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Wednesday, April 29, 2009 2:56 PM > To: Ali C. Begen (abegen) > Subject: New Version Notification for = draft-ietf-fecframe-interleaved-fec-scheme-04 > > > A new version of I-D, = draft-ietf-fecframe-interleaved-fec-scheme-04.txt has been successfuly = submitted by Ali Begen and posted to the IETF repository. > > Filename: draft-ietf-fecframe-interleaved-fec-scheme > Revision: 04 > Title: RTP Payload Format for 1-D Interleaved Parity = FEC > Creation_date: 2009-04-29 > WG ID: fecframe > Number_of_pages: 31 > > Abstract: > This document defines a new RTP payload format for the Forward Error > Correction (FEC) that is generated by the 1-D interleaved parity code > from a source media encapsulated in RTP. The 1-D interleaved parity > code is a systematic code, where a number of repair symbols are > generated from a set of source symbols and sent in a repair flow > separate from the source flow that carries the source symbols. The > 1-D interleaved parity code offers a good protection against bursty > packet losses at a cost of decent complexity. The new payload format > defined in this document is used (with some exceptions) as a part of > the DVB Application-layer FEC specification. > = =20 > > > The IETF Secretariat. > > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe ------=_NextPart_000_00B3_01C9C9D8.636879C0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Re: [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04

Ali,

I noticed that the fec framework will allow SSRC = multiplexing, are you going to specify this in this draft in the SDP offer answer = section.

Maybe you should also discuss when to use application = media type and when to use video or audio

 

Roni

 

From:= avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Ali C. Begen (abegen)
Sent: Thursday, April 30, 2009 3:54 PM
To: vincent.roca@inrialpes.fr
Cc: avt@ietf.org; fecframe@ietf.org
Subject: Re: [AVT] [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04

 

Hi = Vincent

This draft is not an fec scheme so it is not related to fec framework. = It is an rtp payload format draft. The wglc has been running almost a month now. = If you have comments in this perspective, pls submit them soon.




-acbegen

----- Original Message -----
From: Vincent Roca <vincent.roca@inrialpes.fr>
To: Ali C. Begen (abegen)
Cc: fecframe@ietf.org <fecframe@ietf.org>; avt@ietf.org <avt@ietf.org>
Sent: Thu Apr 30 03:58:35 2009
Subject: Re: [Fecframe] FW: New Version Notification for        draft-ietf-fecframe-interleaved-fec-scheme-04

Hello Ali,

I'm not in favor of finalizing the WGLC for this document. IMHO we = must,
first of all, finalize the framework document itself.

For instance, the terminology used by the interleaved-fec-scheme I-D
(section 3.1.) is not in line with the terminology used by the
fecframe-framework-03 I-D (Section 2):
        "Source = Flow"   vs. "Source data flow"
        "Repair = Flow"   vs. "Repair data flow"
        "Source Symbol" vs. nothing
        "Repair Symbol" vs. nothing
        "Source Packet" vs. nothing
        "Repair Packet" vs. = nothing
And as I said before, IMHO the terminology proposed in the framework
I-D should be discussed too.

So let's do things in the right order, especially as the framework
WGLC finishes soon.

Additionally, I may have some comments for the = interleaved-fec-scheme-04
I-D. Since I missed the WGLC deadline, you have the right to blame me = ;-)
and I apologize in advance.

Regards,

  Vincent


Ali C. Begen (abegen) wrote:
> This version addresses the comments received from fecframe and avt = so far.
> http://www.ietf.org/internet-drafts/draft-ietf-fecf= rame-interleaved-fec-scheme-04.txt
>
>
> Fecframe chairs,
>
> Could we proceed and finalize WGLC?
>
> -acbegen
> 
>
> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Wednesday, April 29, 2009 2:56 PM
> To: Ali C. Begen (abegen)
> Subject: New Version Notification for = draft-ietf-fecframe-interleaved-fec-scheme-04
>
>
> A new version of I-D, = draft-ietf-fecframe-interleaved-fec-scheme-04.txt has been successfuly submitted by Ali Begen and posted to the IETF = repository.
>
> Filename:      draft-ietf-fecframe-interleaved-fec-scheme
> Revision:      04
> Title:                 RTP Payload Format for = 1-D Interleaved Parity FEC
> Creation_date:         = 2009-04-29
> WG ID:                 fecframe
> Number_of_pages: 31
>
> Abstract:
> This document defines a new RTP payload format for the Forward = Error
> Correction (FEC) that is generated by the 1-D interleaved parity = code
> from a source media encapsulated in RTP.  The 1-D interleaved = parity
> code is a systematic code, where a number of repair symbols are
> generated from a set of source symbols and sent in a repair = flow
> separate from the source flow that carries the source = symbols.  The
> 1-D interleaved parity code offers a good protection against = bursty
> packet losses at a cost of decent complexity.  The new payload = format
> defined in this document is used (with some exceptions) as a part = of
> the DVB Application-layer FEC specification.
>           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;         
>
>
> The IETF Secretariat.
>
>
> _______________________________________________
> Fecframe mailing list
> Fecframe@ietf.org
> https://www.ietf.= org/mailman/listinfo/fecframe

------=_NextPart_000_00B3_01C9C9D8.636879C0-- From abegen@cisco.com Thu Apr 30 12:03:59 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFE0C28C326; Thu, 30 Apr 2009 12:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 FxHGVVFBCQWL; Thu, 30 Apr 2009 12:03:58 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id CDA5F28C35B; Thu, 30 Apr 2009 12:01:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,274,1238976000"; d="scan'208";a="160728761" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 30 Apr 2009 19:03:17 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3UJ3HfN013810; Thu, 30 Apr 2009 12:03:17 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3UJ3HnE017272; Thu, 30 Apr 2009 19:03:17 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 12:03:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 30 Apr 2009 12:01:15 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540934913F@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49f9ea83.0637560a.4488.62d2@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 Thread-Index: AcnJgq+DQP1j7cRATQa6PC9zcfp8gAAD/6reAAsScqAAAXPloA== References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> <49f9ea83.0637560a.4488.62d2@mx.google.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , X-OriginalArrivalTime: 30 Apr 2009 19:03:17.0059 (UTC) FILETIME=[51D80930:01C9C9C6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6586; t=1241118197; x=1241982197; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20[Fecframe]=20FW=3A=20New=20Vers ion=20Notification=09for=09draft-ietf-fecframe-interleaved-f ec-scheme-04 |Sender:=20; bh=CkTuab6xkOGqFObHxHnK70weg2gwV6jYDwtdXk2VMLA=; b=1D5WVGFTbGeUdiKvrCJXyl58cPf5BKoczwu8nYUvoNlgIIbCPLxbV+mkeZ xW6gcDBi6tV1tqd3spFju6QOiMdu5S3oW4e4+6C25jI4E2jvBEBVLzGYG674 O2DQhRaVaN; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 19:03:59 -0000 SGkgUm9uaSwgDQoNCj4gSSBub3RpY2VkIHRoYXQgdGhlIGZlYyBmcmFtZXdvcmsgd2lsbCBhbGxv dyBTU1JDIA0KDQpZZXMsIGl0IHdpbGwgbm90IGJlIHRoZSByZWNvbW1lbmRlZCB3YXkgb2YgdXNp bmcgRkVDLCBidXQgaXQgd2lsbCBiZSBzdXBwb3J0ZWQuIFRoZSA0NzU2YmlzIGRyYWZ0IGFsc28g c3VwcG9ydHMgaXQgbm93Lg0KDQo+IG11bHRpcGxleGluZywgYXJlIHlvdSBnb2luZyB0byBzcGVj aWZ5IHRoaXMgaW4gdGhpcyBkcmFmdCBpbiANCj4gdGhlIFNEUCBvZmZlciBhbnN3ZXIgc2VjdGlv bi4gDQoNCkkgYW0gbm90IHN1cmUgd2hhdCBJIG5lZWQgdG8gc3BlY2lmeSBhZGRpdGlvbmFsbHkg aW4gdGhpcyBzZWN0aW9uIHJlZ2FyZGluZyBTU1JDIG11bHRpcGxleGluZy4gQ291bGQgeW91IGxl dCBtZSBrbm93IGlmIHRoZXJlIGlzIHN1Y2ggYW4gZXhhbXBsZT8NCiANCj4gTWF5YmUgeW91IHNo b3VsZCBhbHNvIGRpc2N1c3Mgd2hlbiB0byB1c2UgYXBwbGljYXRpb24gbWVkaWEgDQo+IHR5cGUg YW5kIHdoZW4gdG8gdXNlIHZpZGVvIG9yIGF1ZGlvDQoNCkkgYmVsaWV2ZSB0aGUgRkVDIGlzIGFs d2F5cyBhcHBsaWNhdGlvbiB0eXBlLCB3ZSBkaWQgcmVnaXN0cmF0aW9uIGZvciB2aWRlbywgYXVk aW8sIGV0Yy4gc2luY2UgRkVDIGNvdWxkIHJlbGF0ZSB0byBzZXNzaW9ucyBjYXJyeWluZyBzdWNo IHR5cGVzLg0KDQpCUiwNCi1hY2JlZ2VuDQogDQo+ICANCj4gDQo+IFJvbmkNCj4gDQo+ICANCj4g DQo+IEZyb206IGF2dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXZ0LWJvdW5jZXNAaWV0Zi5v cmddIE9uIA0KPiBCZWhhbGYgT2YgQWxpIEMuIEJlZ2VuIChhYmVnZW4pDQo+IFNlbnQ6IFRodXJz ZGF5LCBBcHJpbCAzMCwgMjAwOSAzOjU0IFBNDQo+IFRvOiB2aW5jZW50LnJvY2FAaW5yaWFscGVz LmZyDQo+IENjOiBhdnRAaWV0Zi5vcmc7IGZlY2ZyYW1lQGlldGYub3JnDQo+IFN1YmplY3Q6IFJl OiBbQVZUXSBbRmVjZnJhbWVdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gDQo+IGZvciBk cmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUtMDQNCj4gDQo+ICANCj4g DQo+IEhpIFZpbmNlbnQNCj4gDQo+IFRoaXMgZHJhZnQgaXMgbm90IGFuIGZlYyBzY2hlbWUgc28g aXQgaXMgbm90IHJlbGF0ZWQgdG8gZmVjIA0KPiBmcmFtZXdvcmsuIEl0IGlzIGFuIHJ0cCBwYXls b2FkIGZvcm1hdCBkcmFmdC4gVGhlIHdnbGMgaGFzIA0KPiBiZWVuIHJ1bm5pbmcgYWxtb3N0IGEg bW9udGggbm93LiBJZiB5b3UgaGF2ZSBjb21tZW50cyBpbiB0aGlzIA0KPiBwZXJzcGVjdGl2ZSwg cGxzIHN1Ym1pdCB0aGVtIHNvb24uDQo+IA0KPiANCj4gDQo+IA0KPiAtYWNiZWdlbg0KPiANCj4g LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiBGcm9tOiBWaW5jZW50IFJvY2EgPHZpbmNl bnQucm9jYUBpbnJpYWxwZXMuZnI+DQo+IFRvOiBBbGkgQy4gQmVnZW4gKGFiZWdlbikNCj4gQ2M6 IGZlY2ZyYW1lQGlldGYub3JnIDxmZWNmcmFtZUBpZXRmLm9yZz47IGF2dEBpZXRmLm9yZyA8YXZ0 QGlldGYub3JnPg0KPiBTZW50OiBUaHUgQXByIDMwIDAzOjU4OjM1IDIwMDkNCj4gU3ViamVjdDog UmU6IFtGZWNmcmFtZV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgICAgICANCj4g ICBkcmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUtMDQNCj4gDQo+IEhl bGxvIEFsaSwNCj4gDQo+IEknbSBub3QgaW4gZmF2b3Igb2YgZmluYWxpemluZyB0aGUgV0dMQyBm b3IgdGhpcyBkb2N1bWVudC4gDQo+IElNSE8gd2UgbXVzdCwNCj4gZmlyc3Qgb2YgYWxsLCBmaW5h bGl6ZSB0aGUgZnJhbWV3b3JrIGRvY3VtZW50IGl0c2VsZi4NCj4gDQo+IEZvciBpbnN0YW5jZSwg dGhlIHRlcm1pbm9sb2d5IHVzZWQgYnkgdGhlIGludGVybGVhdmVkLWZlYy1zY2hlbWUgSS1EDQo+ IChzZWN0aW9uIDMuMS4pIGlzIG5vdCBpbiBsaW5lIHdpdGggdGhlIHRlcm1pbm9sb2d5IHVzZWQg YnkgdGhlDQo+IGZlY2ZyYW1lLWZyYW1ld29yay0wMyBJLUQgKFNlY3Rpb24gMik6DQo+ICAgICAg ICAgIlNvdXJjZSBGbG93IiAgIHZzLiAiU291cmNlIGRhdGEgZmxvdyINCj4gICAgICAgICAiUmVw YWlyIEZsb3ciICAgdnMuICJSZXBhaXIgZGF0YSBmbG93Ig0KPiAgICAgICAgICJTb3VyY2UgU3lt Ym9sIiB2cy4gbm90aGluZw0KPiAgICAgICAgICJSZXBhaXIgU3ltYm9sIiB2cy4gbm90aGluZw0K PiAgICAgICAgICJTb3VyY2UgUGFja2V0IiB2cy4gbm90aGluZw0KPiAgICAgICAgICJSZXBhaXIg UGFja2V0IiB2cy4gbm90aGluZw0KPiBBbmQgYXMgSSBzYWlkIGJlZm9yZSwgSU1ITyB0aGUgdGVy bWlub2xvZ3kgcHJvcG9zZWQgaW4gdGhlIGZyYW1ld29yaw0KPiBJLUQgc2hvdWxkIGJlIGRpc2N1 c3NlZCB0b28uDQo+IA0KPiBTbyBsZXQncyBkbyB0aGluZ3MgaW4gdGhlIHJpZ2h0IG9yZGVyLCBl c3BlY2lhbGx5IGFzIHRoZSBmcmFtZXdvcmsNCj4gV0dMQyBmaW5pc2hlcyBzb29uLg0KPiANCj4g QWRkaXRpb25hbGx5LCBJIG1heSBoYXZlIHNvbWUgY29tbWVudHMgZm9yIHRoZSANCj4gaW50ZXJs ZWF2ZWQtZmVjLXNjaGVtZS0wNA0KPiBJLUQuIFNpbmNlIEkgbWlzc2VkIHRoZSBXR0xDIGRlYWRs aW5lLCB5b3UgaGF2ZSB0aGUgcmlnaHQgdG8gDQo+IGJsYW1lIG1lIDstKQ0KPiBhbmQgSSBhcG9s b2dpemUgaW4gYWR2YW5jZS4NCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiAgIFZpbmNlbnQNCj4gDQo+ IA0KPiBBbGkgQy4gQmVnZW4gKGFiZWdlbikgd3JvdGU6DQo+ID4gVGhpcyB2ZXJzaW9uIGFkZHJl c3NlcyB0aGUgY29tbWVudHMgcmVjZWl2ZWQgZnJvbSBmZWNmcmFtZSANCj4gYW5kIGF2dCBzbyBm YXIuDQo+ID4gDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWll dGYtZmVjZnJhbWUtaW50ZXJsDQplYXZlZC1mZWMtc2NoZW1lLTA0LnR4dA0KPiA+DQo+ID4NCj4g PiBGZWNmcmFtZSBjaGFpcnMsDQo+ID4NCj4gPiBDb3VsZCB3ZSBwcm9jZWVkIGFuZCBmaW5hbGl6 ZSBXR0xDPw0KPiA+DQo+ID4gLWFjYmVnZW4NCj4gPiANCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogSUVURiBJLUQgU3VibWlzc2lvbiBUb29sIFttYWlsdG86 aWRzdWJtaXNzaW9uQGlldGYub3JnXQ0KPiA+IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjksIDIw MDkgMjo1NiBQTQ0KPiA+IFRvOiBBbGkgQy4gQmVnZW4gKGFiZWdlbikNCj4gPiBTdWJqZWN0OiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIA0KPiBkcmFmdC1pZXRmLWZlY2ZyYW1lLWludGVy bGVhdmVkLWZlYy1zY2hlbWUtMDQNCj4gPg0KPiA+DQo+ID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQs IA0KPiBkcmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUtMDQudHh0IGhh cyBiZWVuIA0KPiBzdWNjZXNzZnVseSBzdWJtaXR0ZWQgYnkgQWxpIEJlZ2VuIGFuZCBwb3N0ZWQg dG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4gPg0KPiA+IEZpbGVuYW1lOiAgICAgIGRyYWZ0LWll dGYtZmVjZnJhbWUtaW50ZXJsZWF2ZWQtZmVjLXNjaGVtZQ0KPiA+IFJldmlzaW9uOiAgICAgIDA0 DQo+ID4gVGl0bGU6ICAgICAgICAgICAgICAgICBSVFAgUGF5bG9hZCBGb3JtYXQgZm9yIDEtRCAN Cj4gSW50ZXJsZWF2ZWQgUGFyaXR5IEZFQw0KPiA+IENyZWF0aW9uX2RhdGU6ICAgICAgICAgMjAw OS0wNC0yOQ0KPiA+IFdHIElEOiAgICAgICAgICAgICAgICAgZmVjZnJhbWUNCj4gPiBOdW1iZXJf b2ZfcGFnZXM6IDMxDQo+ID4NCj4gPiBBYnN0cmFjdDoNCj4gPiBUaGlzIGRvY3VtZW50IGRlZmlu ZXMgYSBuZXcgUlRQIHBheWxvYWQgZm9ybWF0IGZvciB0aGUgRm9yd2FyZCBFcnJvcg0KPiA+IENv cnJlY3Rpb24gKEZFQykgdGhhdCBpcyBnZW5lcmF0ZWQgYnkgdGhlIDEtRCBpbnRlcmxlYXZlZCAN Cj4gcGFyaXR5IGNvZGUNCj4gPiBmcm9tIGEgc291cmNlIG1lZGlhIGVuY2Fwc3VsYXRlZCBpbiBS VFAuICBUaGUgMS1EIGludGVybGVhdmVkIHBhcml0eQ0KPiA+IGNvZGUgaXMgYSBzeXN0ZW1hdGlj IGNvZGUsIHdoZXJlIGEgbnVtYmVyIG9mIHJlcGFpciBzeW1ib2xzIGFyZQ0KPiA+IGdlbmVyYXRl ZCBmcm9tIGEgc2V0IG9mIHNvdXJjZSBzeW1ib2xzIGFuZCBzZW50IGluIGEgcmVwYWlyIGZsb3cN Cj4gPiBzZXBhcmF0ZSBmcm9tIHRoZSBzb3VyY2UgZmxvdyB0aGF0IGNhcnJpZXMgdGhlIHNvdXJj ZSBzeW1ib2xzLiAgVGhlDQo+ID4gMS1EIGludGVybGVhdmVkIHBhcml0eSBjb2RlIG9mZmVycyBh IGdvb2QgcHJvdGVjdGlvbiBhZ2FpbnN0IGJ1cnN0eQ0KPiA+IHBhY2tldCBsb3NzZXMgYXQgYSBj b3N0IG9mIGRlY2VudCBjb21wbGV4aXR5LiAgVGhlIG5ldyANCj4gcGF5bG9hZCBmb3JtYXQNCj4g PiBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgaXMgdXNlZCAod2l0aCBzb21lIGV4Y2VwdGlvbnMp IGFzIGEgcGFydCBvZg0KPiA+IHRoZSBEVkIgQXBwbGljYXRpb24tbGF5ZXIgRkVDIHNwZWNpZmlj YXRpb24uDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQo+ICAgICAgICAgICAgICAgICAgICAgIA0KPiA+DQo+ID4NCj4gPiBU aGUgSUVURiBTZWNyZXRhcmlhdC4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBGZWNmcmFtZSBtYWlsaW5nIGxpc3QNCj4g PiBGZWNmcmFtZUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZmVjZnJhbWUNCj4gDQo+IA0K From ron.even.tlv@gmail.com Thu Apr 30 13:04:24 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 307563A690F; Thu, 30 Apr 2009 13:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599] 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 uFu-k+kCknyw; Thu, 30 Apr 2009 13:04:23 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 92FD73A6ABF; Thu, 30 Apr 2009 13:04:22 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 13so858761fge.18 for ; Thu, 30 Apr 2009 13:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=dGVbuOf5rMSrUoztJo+aNsJOYX5wNnsTRjEawC7paeM=; b=T/P5pXpCTgi0R3aZhtb+yk/PNNwt1/u1OHTeH83I3B8i9oCG/3tsvBou67tHlYXt+K 2Is2eb/WDyFYiw8mPZQ5pq5zi5PQo9t+fH4ofZ1GzmCAALMi7ZRoJ019KgvjTRLiXaEI ZzfniT0Nixd+u0mF4HDNQrQi7TB31okoeVEXo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=ak2KbA8/P+OPckqK0yFeI1IcVPKxGz6+uLIue3DZt2I7EwDBc7cSGg7KiC6jW0Qwq0 wWCFl3ggDxo8m7lSOCxgM3l8KmSsE61SrbJ/okWjYHMq7Sh/9qUmqHa0tGkUcZNcyZ40 xzlraY+8/Nmnw+GKZ02nkJt1G7pNthGsE51F0= Received: by 10.86.65.9 with SMTP id n9mr2206565fga.43.1241121945049; Thu, 30 Apr 2009 13:05:45 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-57-219.red.bezeqint.net [79.177.57.219]) by mx.google.com with ESMTPS id 4sm10946595fge.23.2009.04.30.13.05.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Apr 2009 13:05:44 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> <49f9ea83.0637560a.4488.62d2@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D540934913F@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540934913F@xmb-sjc-215.amer.cisco.com> Date: Thu, 30 Apr 2009 23:03:29 +0300 Message-ID: <49fa0498.0405560a.615f.677e@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnJgq+DQP1j7cRATQa6PC9zcfp8gAAD/6reAAsScqAAAXPloAAB7PmA Content-Language: en-us Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 20:04:24 -0000 Ali, You can find examples in section 8.6 to 8.8 of RFC 4588, notice that = there is an optional parameter for the rtx stream that defines the = relation between the original and the rtx stream. Similar solution is = also specified for redundant encoding red payload type (RFC 2198). You = are offering both streams with different payload type numbers in the = same m-line. In this case the media type must be video or audio same as the media = type of the protected stream. This is why you needed the registration = for type audio and video Roni -----Original Message----- From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 Sent: Thursday, April 30, 2009 10:01 PM To: Roni Even; vincent.roca@inrialpes.fr Cc: avt@ietf.org; fecframe@ietf.org Subject: RE: [AVT] [Fecframe] FW: New Version Notification for = draft-ietf-fecframe-interleaved-fec-scheme-04 Hi Roni,=20 > I noticed that the fec framework will allow SSRC=20 Yes, it will not be the recommended way of using FEC, but it will be = supported. The 4756bis draft also supports it now. > multiplexing, are you going to specify this in this draft in=20 > the SDP offer answer section.=20 I am not sure what I need to specify additionally in this section = regarding SSRC multiplexing. Could you let me know if there is such an = example? =20 > Maybe you should also discuss when to use application media=20 > type and when to use video or audio I believe the FEC is always application type, we did registration for = video, audio, etc. since FEC could relate to sessions carrying such = types. BR, -acbegen =20 > =20 >=20 > Roni >=20 > =20 >=20 > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > Behalf Of Ali C. Begen (abegen) > Sent: Thursday, April 30, 2009 3:54 PM > To: vincent.roca@inrialpes.fr > Cc: avt@ietf.org; fecframe@ietf.org > Subject: Re: [AVT] [Fecframe] FW: New Version Notification=20 > for draft-ietf-fecframe-interleaved-fec-scheme-04 >=20 > =20 >=20 > Hi Vincent >=20 > This draft is not an fec scheme so it is not related to fec=20 > framework. It is an rtp payload format draft. The wglc has=20 > been running almost a month now. If you have comments in this=20 > perspective, pls submit them soon. >=20 >=20 >=20 >=20 > -acbegen >=20 > ----- Original Message ----- > From: Vincent Roca > To: Ali C. Begen (abegen) > Cc: fecframe@ietf.org ; avt@ietf.org > Sent: Thu Apr 30 03:58:35 2009 > Subject: Re: [Fecframe] FW: New Version Notification for =20 > draft-ietf-fecframe-interleaved-fec-scheme-04 >=20 > Hello Ali, >=20 > I'm not in favor of finalizing the WGLC for this document.=20 > IMHO we must, > first of all, finalize the framework document itself. >=20 > For instance, the terminology used by the interleaved-fec-scheme I-D > (section 3.1.) is not in line with the terminology used by the > fecframe-framework-03 I-D (Section 2): > "Source Flow" vs. "Source data flow" > "Repair Flow" vs. "Repair data flow" > "Source Symbol" vs. nothing > "Repair Symbol" vs. nothing > "Source Packet" vs. nothing > "Repair Packet" vs. nothing > And as I said before, IMHO the terminology proposed in the framework > I-D should be discussed too. >=20 > So let's do things in the right order, especially as the framework > WGLC finishes soon. >=20 > Additionally, I may have some comments for the=20 > interleaved-fec-scheme-04 > I-D. Since I missed the WGLC deadline, you have the right to=20 > blame me ;-) > and I apologize in advance. >=20 > Regards, >=20 > Vincent >=20 >=20 > Ali C. Begen (abegen) wrote: > > This version addresses the comments received from fecframe=20 > and avt so far. > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interl eaved-fec-scheme-04.txt > > > > > > Fecframe chairs, > > > > Could we proceed and finalize WGLC? > > > > -acbegen > >=20 > > > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > Sent: Wednesday, April 29, 2009 2:56 PM > > To: Ali C. Begen (abegen) > > Subject: New Version Notification for=20 > draft-ietf-fecframe-interleaved-fec-scheme-04 > > > > > > A new version of I-D,=20 > draft-ietf-fecframe-interleaved-fec-scheme-04.txt has been=20 > successfuly submitted by Ali Begen and posted to the IETF repository. > > > > Filename: draft-ietf-fecframe-interleaved-fec-scheme > > Revision: 04 > > Title: RTP Payload Format for 1-D=20 > Interleaved Parity FEC > > Creation_date: 2009-04-29 > > WG ID: fecframe > > Number_of_pages: 31 > > > > Abstract: > > This document defines a new RTP payload format for the Forward Error > > Correction (FEC) that is generated by the 1-D interleaved=20 > parity code > > from a source media encapsulated in RTP. The 1-D interleaved parity > > code is a systematic code, where a number of repair symbols are > > generated from a set of source symbols and sent in a repair flow > > separate from the source flow that carries the source symbols. The > > 1-D interleaved parity code offers a good protection against bursty > > packet losses at a cost of decent complexity. The new=20 > payload format > > defined in this document is used (with some exceptions) as a part of > > the DVB Application-layer FEC specification. > > =20 > =20 > > > > > > The IETF Secretariat. > > > > > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe >=20 >=20 From abegen@cisco.com Thu Apr 30 16:43:59 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 500FC3A6ABE; Thu, 30 Apr 2009 16:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.375 X-Spam-Level: X-Spam-Status: No, score=-6.375 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 a905FygRRXFB; Thu, 30 Apr 2009 16:43:58 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 02E373A6AB5; Thu, 30 Apr 2009 16:43:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,275,1238976000"; d="scan'208";a="158172953" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 30 Apr 2009 23:45:21 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3UNjLZA004702; Thu, 30 Apr 2009 16:45:21 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3UNjLPk005582; Thu, 30 Apr 2009 23:45:21 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 16:45:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 30 Apr 2009 16:45:12 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540934937B@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49fa0498.0405560a.615f.677e@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 Thread-Index: AcnJgq+DQP1j7cRATQa6PC9zcfp8gAAD/6reAAsScqAAAXPloAAB7PmAAAfhEBA= References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> <49f9ea83.0637560a.4488.62d2@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D540934913F@xmb-sjc-215.amer.cisco.com> <49fa0498.0405560a.615f.677e@mx.google.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , X-OriginalArrivalTime: 30 Apr 2009 23:45:21.0332 (UTC) FILETIME=[B97F2740:01C9C9ED] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9998; t=1241135121; x=1241999121; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20[Fecframe]=20FW=3A=20New=20Vers ion=20Notification=09for=09draft-ietf-fecframe-interleaved-f ec-scheme-04 |Sender:=20; bh=SXNuIcS6QYlWbQ2Z63KMfPJ0z/ZtY2lPnkpmma7e60o=; b=gTkvPzWGoO6JWifyY/FdZ+GJxNW9A8FcFoWB0vR+CMHZWxpE9uPWlzeM8W rsgePUIV7MBufTL0fWSHALeDZj9Pp3+I4v/n4PB/tcODm1dZuO3EZ2z2MDX9 MhQVA+HJHS2Hrd7c2+scSDrO0/0qEz8kchMZBpmUrCd/vqNHCX418=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 23:43:59 -0000 SGkgUm9uaSwNCg0KVGhhbmtzIGZvciB0aGUgcmVmZXJlbmNlcy4gSG93ZXZlciwgd2UgY2Fubm90 IGhhdmUgYSBwYXJhbWV0ZXIgdGhhdCB3aWxsIHJlbGF0ZSB0aGUgRkVDIHN0cmVhbSB0byB0aGUg c291cmNlIGFzIFJGQyA0NTg4IGRpZCB3aXRoICJhcHQiIHNpbmNlIGEgbG90IG9mIHBvc3NpYmls aXRpZXMgKG11bHRpcGxlIHNvdXJjZXMgYW5kL29yIG11bHRpcGxlIHJlcGFpciBmbG93cykgYXJl IHBvc3NpYmxlIHdpdGggRkVDLiBJbnN0ZWFkLCB3ZSB1c2UgZ3JvdXBpbmcgYW5kIHRoaXMgd29y a3MganVzdCBmaW5lIGluIHNlc3Npb24gbXVsdGlwbGV4aW5nLg0KDQpSZWdhcmRpbmcgU1NSQyBt dWx0aXBsZXhpbmcgb2Ygc291cmNlIGFuZCBGRUMgc3RyZWFtcywgSSBkb24ndCB0aGluayBnaXZp bmcgYW4gZXhwbGljaXQgZXhhbXBsZSBpcyBuZWVkZWQgb3IgaXQgaXMgYSBnb29kIGlkZWEgZm9y IHRoaXMgZHJhZnQgc2luY2UgU1NSQy1sZXZlbCBncm91cGluZyBpcyBqdXN0IGludHJvZHVjZWQg aW4gNDc1NmJpcyBhbmQgaXQgd2lsbCBpbmNsdWRlIHN1Y2ggZXhhbXBsZXMgYW55d2F5IChhY3R1 YWxseSB0aGUgdmVyc2lvbiBJIHN1Ym1pdHRlZCB0b2RheSBpbmNsdWRlcyBhbiBleGFtcGxlKS4g V2Ugc2hvdWxkIGJldHRlciBvbmx5IHByb3ZpZGUgc2Vzc2lvbiBtdWx0aXBsZXhpbmcgZXhhbXBs ZXMgaW4gdGhpcyBkcmFmdC4gVGhpcyBhbHNvIGVtcGhhc2l6ZXMgdGhlIHJlY29tbWVuZGVkIHdh eSBvZiBkb2luZyBGRUMuDQoNClJlZyB0aGUgcmVnaXN0cmF0aW9uIG9mIHRoZSBtZWRpYSB0eXBl cyBhbmQgU0RQIG1hcHBpbmdzLCBJIGJlbGlldmUgdGhlIGRyYWZ0IGhhcyB0aGUgbmVjZXNzYXJ5 IGRldGFpbHMuDQoNCkJSLA0KLWFjYmVnZW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBSb25pIEV2ZW4gW21haWx0bzpyb24uZXZlbi50bHZAZ21haWwuY29tXSANCj4g U2VudDogVGh1cnNkYXksIEFwcmlsIDMwLCAyMDA5IDE6MDMgUE0NCj4gVG86IEFsaSBDLiBCZWdl biAoYWJlZ2VuKTsgdmluY2VudC5yb2NhQGlucmlhbHBlcy5mcg0KPiBDYzogYXZ0QGlldGYub3Jn OyBmZWNmcmFtZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW0FWVF0gW0ZlY2ZyYW1lXSBGVzog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIA0KPiBmb3IgZHJhZnQtaWV0Zi1mZWNmcmFtZS1pbnRl cmxlYXZlZC1mZWMtc2NoZW1lLTA0DQo+IA0KPiBBbGksDQo+IFlvdSBjYW4gZmluZCBleGFtcGxl cyBpbiBzZWN0aW9uIDguNiB0byA4Ljggb2YgUkZDIDQ1ODgsIA0KPiBub3RpY2UgdGhhdCB0aGVy ZSBpcyBhbiBvcHRpb25hbCBwYXJhbWV0ZXIgZm9yIHRoZSBydHggc3RyZWFtIA0KPiB0aGF0IGRl ZmluZXMgdGhlIHJlbGF0aW9uIGJldHdlZW4gdGhlIG9yaWdpbmFsIGFuZCB0aGUgcnR4IA0KPiBz dHJlYW0uIFNpbWlsYXIgc29sdXRpb24gaXMgYWxzbyBzcGVjaWZpZWQgZm9yIHJlZHVuZGFudCAN Cj4gZW5jb2RpbmcgcmVkIHBheWxvYWQgdHlwZSAoUkZDIDIxOTgpLiBZb3UgYXJlIG9mZmVyaW5n IGJvdGggDQo+IHN0cmVhbXMgd2l0aCBkaWZmZXJlbnQgcGF5bG9hZCB0eXBlIG51bWJlcnMgaW4g dGhlIHNhbWUgbS1saW5lLg0KPiBJbiB0aGlzIGNhc2UgdGhlIG1lZGlhIHR5cGUgbXVzdCBiZSB2 aWRlbyBvciBhdWRpbyBzYW1lIGFzIA0KPiB0aGUgbWVkaWEgdHlwZSBvZiB0aGUgcHJvdGVjdGVk IHN0cmVhbS4gVGhpcyBpcyB3aHkgeW91IA0KPiBuZWVkZWQgdGhlIHJlZ2lzdHJhdGlvbiBmb3Ig dHlwZSBhdWRpbyBhbmQgdmlkZW8NCj4gDQo+IFJvbmkNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IEFsaSBDLiBCZWdlbiAoYWJlZ2VuKSBbbWFpbHRvOmFiZWdlbkBj aXNjby5jb21dIA0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMzAsIDIwMDkgMTA6MDEgUE0NCj4g VG86IFJvbmkgRXZlbjsgdmluY2VudC5yb2NhQGlucmlhbHBlcy5mcg0KPiBDYzogYXZ0QGlldGYu b3JnOyBmZWNmcmFtZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW0FWVF0gW0ZlY2ZyYW1lXSBG VzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIA0KPiBmb3IgZHJhZnQtaWV0Zi1mZWNmcmFtZS1p bnRlcmxlYXZlZC1mZWMtc2NoZW1lLTA0DQo+IA0KPiBIaSBSb25pLCANCj4gDQo+ID4gSSBub3Rp Y2VkIHRoYXQgdGhlIGZlYyBmcmFtZXdvcmsgd2lsbCBhbGxvdyBTU1JDIA0KPiANCj4gWWVzLCBp dCB3aWxsIG5vdCBiZSB0aGUgcmVjb21tZW5kZWQgd2F5IG9mIHVzaW5nIEZFQywgYnV0IGl0IA0K PiB3aWxsIGJlIHN1cHBvcnRlZC4gVGhlIDQ3NTZiaXMgZHJhZnQgYWxzbyBzdXBwb3J0cyBpdCBu b3cuDQo+IA0KPiA+IG11bHRpcGxleGluZywgYXJlIHlvdSBnb2luZyB0byBzcGVjaWZ5IHRoaXMg aW4gdGhpcyBkcmFmdCBpbiANCj4gPiB0aGUgU0RQIG9mZmVyIGFuc3dlciBzZWN0aW9uLiANCj4g DQo+IEkgYW0gbm90IHN1cmUgd2hhdCBJIG5lZWQgdG8gc3BlY2lmeSBhZGRpdGlvbmFsbHkgaW4g dGhpcyANCj4gc2VjdGlvbiByZWdhcmRpbmcgU1NSQyBtdWx0aXBsZXhpbmcuIENvdWxkIHlvdSBs ZXQgbWUga25vdyBpZiANCj4gdGhlcmUgaXMgc3VjaCBhbiBleGFtcGxlPw0KPiAgDQo+ID4gTWF5 YmUgeW91IHNob3VsZCBhbHNvIGRpc2N1c3Mgd2hlbiB0byB1c2UgYXBwbGljYXRpb24gbWVkaWEg DQo+ID4gdHlwZSBhbmQgd2hlbiB0byB1c2UgdmlkZW8gb3IgYXVkaW8NCj4gDQo+IEkgYmVsaWV2 ZSB0aGUgRkVDIGlzIGFsd2F5cyBhcHBsaWNhdGlvbiB0eXBlLCB3ZSBkaWQgDQo+IHJlZ2lzdHJh dGlvbiBmb3IgdmlkZW8sIGF1ZGlvLCBldGMuIHNpbmNlIEZFQyBjb3VsZCByZWxhdGUgdG8gDQo+ IHNlc3Npb25zIGNhcnJ5aW5nIHN1Y2ggdHlwZXMuDQo+IA0KPiBCUiwNCj4gLWFjYmVnZW4NCj4g IA0KPiA+ICANCj4gPiANCj4gPiBSb25pDQo+ID4gDQo+ID4gIA0KPiA+IA0KPiA+IEZyb206IGF2 dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXZ0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIA0KPiA+ IEJlaGFsZiBPZiBBbGkgQy4gQmVnZW4gKGFiZWdlbikNCj4gPiBTZW50OiBUaHVyc2RheSwgQXBy aWwgMzAsIDIwMDkgMzo1NCBQTQ0KPiA+IFRvOiB2aW5jZW50LnJvY2FAaW5yaWFscGVzLmZyDQo+ ID4gQ2M6IGF2dEBpZXRmLm9yZzsgZmVjZnJhbWVAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTog W0FWVF0gW0ZlY2ZyYW1lXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIA0KPiA+IGZvciBk cmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUtMDQNCj4gPiANCj4gPiAg DQo+ID4gDQo+ID4gSGkgVmluY2VudA0KPiA+IA0KPiA+IFRoaXMgZHJhZnQgaXMgbm90IGFuIGZl YyBzY2hlbWUgc28gaXQgaXMgbm90IHJlbGF0ZWQgdG8gZmVjIA0KPiA+IGZyYW1ld29yay4gSXQg aXMgYW4gcnRwIHBheWxvYWQgZm9ybWF0IGRyYWZ0LiBUaGUgd2dsYyBoYXMgDQo+ID4gYmVlbiBy dW5uaW5nIGFsbW9zdCBhIG1vbnRoIG5vdy4gSWYgeW91IGhhdmUgY29tbWVudHMgaW4gdGhpcyAN Cj4gPiBwZXJzcGVjdGl2ZSwgcGxzIHN1Ym1pdCB0aGVtIHNvb24uDQo+ID4gDQo+ID4gDQo+ID4g DQo+ID4gDQo+ID4gLWFjYmVnZW4NCj4gPiANCj4gPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t LS0tDQo+ID4gRnJvbTogVmluY2VudCBSb2NhIDx2aW5jZW50LnJvY2FAaW5yaWFscGVzLmZyPg0K PiA+IFRvOiBBbGkgQy4gQmVnZW4gKGFiZWdlbikNCj4gPiBDYzogZmVjZnJhbWVAaWV0Zi5vcmcg PGZlY2ZyYW1lQGlldGYub3JnPjsgYXZ0QGlldGYub3JnIA0KPiA8YXZ0QGlldGYub3JnPg0KPiA+ IFNlbnQ6IFRodSBBcHIgMzAgMDM6NTg6MzUgMjAwOQ0KPiA+IFN1YmplY3Q6IFJlOiBbRmVjZnJh bWVdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yICAgICAgDQo+ID4gICBkcmFmdC1p ZXRmLWZlY2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUtMDQNCj4gPiANCj4gPiBIZWxsbyBB bGksDQo+ID4gDQo+ID4gSSdtIG5vdCBpbiBmYXZvciBvZiBmaW5hbGl6aW5nIHRoZSBXR0xDIGZv ciB0aGlzIGRvY3VtZW50LiANCj4gPiBJTUhPIHdlIG11c3QsDQo+ID4gZmlyc3Qgb2YgYWxsLCBm aW5hbGl6ZSB0aGUgZnJhbWV3b3JrIGRvY3VtZW50IGl0c2VsZi4NCj4gPiANCj4gPiBGb3IgaW5z dGFuY2UsIHRoZSB0ZXJtaW5vbG9neSB1c2VkIGJ5IHRoZSBpbnRlcmxlYXZlZC1mZWMtc2NoZW1l IEktRA0KPiA+IChzZWN0aW9uIDMuMS4pIGlzIG5vdCBpbiBsaW5lIHdpdGggdGhlIHRlcm1pbm9s b2d5IHVzZWQgYnkgdGhlDQo+ID4gZmVjZnJhbWUtZnJhbWV3b3JrLTAzIEktRCAoU2VjdGlvbiAy KToNCj4gPiAgICAgICAgICJTb3VyY2UgRmxvdyIgICB2cy4gIlNvdXJjZSBkYXRhIGZsb3ciDQo+ ID4gICAgICAgICAiUmVwYWlyIEZsb3ciICAgdnMuICJSZXBhaXIgZGF0YSBmbG93Ig0KPiA+ICAg ICAgICAgIlNvdXJjZSBTeW1ib2wiIHZzLiBub3RoaW5nDQo+ID4gICAgICAgICAiUmVwYWlyIFN5 bWJvbCIgdnMuIG5vdGhpbmcNCj4gPiAgICAgICAgICJTb3VyY2UgUGFja2V0IiB2cy4gbm90aGlu Zw0KPiA+ICAgICAgICAgIlJlcGFpciBQYWNrZXQiIHZzLiBub3RoaW5nDQo+ID4gQW5kIGFzIEkg c2FpZCBiZWZvcmUsIElNSE8gdGhlIHRlcm1pbm9sb2d5IHByb3Bvc2VkIGluIHRoZSBmcmFtZXdv cmsNCj4gPiBJLUQgc2hvdWxkIGJlIGRpc2N1c3NlZCB0b28uDQo+ID4gDQo+ID4gU28gbGV0J3Mg ZG8gdGhpbmdzIGluIHRoZSByaWdodCBvcmRlciwgZXNwZWNpYWxseSBhcyB0aGUgZnJhbWV3b3Jr DQo+ID4gV0dMQyBmaW5pc2hlcyBzb29uLg0KPiA+IA0KPiA+IEFkZGl0aW9uYWxseSwgSSBtYXkg aGF2ZSBzb21lIGNvbW1lbnRzIGZvciB0aGUgDQo+ID4gaW50ZXJsZWF2ZWQtZmVjLXNjaGVtZS0w NA0KPiA+IEktRC4gU2luY2UgSSBtaXNzZWQgdGhlIFdHTEMgZGVhZGxpbmUsIHlvdSBoYXZlIHRo ZSByaWdodCB0byANCj4gPiBibGFtZSBtZSA7LSkNCj4gPiBhbmQgSSBhcG9sb2dpemUgaW4gYWR2 YW5jZS4NCj4gPiANCj4gPiBSZWdhcmRzLA0KPiA+IA0KPiA+ICAgVmluY2VudA0KPiA+IA0KPiA+ IA0KPiA+IEFsaSBDLiBCZWdlbiAoYWJlZ2VuKSB3cm90ZToNCj4gPiA+IFRoaXMgdmVyc2lvbiBh ZGRyZXNzZXMgdGhlIGNvbW1lbnRzIHJlY2VpdmVkIGZyb20gZmVjZnJhbWUgDQo+ID4gYW5kIGF2 dCBzbyBmYXIuDQo+ID4gPiANCj4gPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybA0KPiBlYXZlZC1mZWMtc2NoZW1lLTA0LnR4dA0K PiA+ID4NCj4gPiA+DQo+ID4gPiBGZWNmcmFtZSBjaGFpcnMsDQo+ID4gPg0KPiA+ID4gQ291bGQg d2UgcHJvY2VlZCBhbmQgZmluYWxpemUgV0dMQz8NCj4gPiA+DQo+ID4gPiAtYWNiZWdlbg0KPiA+ ID4gDQo+ID4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206 IElFVEYgSS1EIFN1Ym1pc3Npb24gVG9vbCBbbWFpbHRvOmlkc3VibWlzc2lvbkBpZXRmLm9yZ10N Cj4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjksIDIwMDkgMjo1NiBQTQ0KPiA+ID4gVG86 IEFsaSBDLiBCZWdlbiAoYWJlZ2VuKQ0KPiA+ID4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciANCj4gPiBkcmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hl bWUtMDQNCj4gPiA+DQo+ID4gPg0KPiA+ID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIA0KPiA+IGRy YWZ0LWlldGYtZmVjZnJhbWUtaW50ZXJsZWF2ZWQtZmVjLXNjaGVtZS0wNC50eHQgaGFzIGJlZW4g DQo+ID4gc3VjY2Vzc2Z1bHkgc3VibWl0dGVkIGJ5IEFsaSBCZWdlbiBhbmQgcG9zdGVkIHRvIHRo ZSBJRVRGIA0KPiByZXBvc2l0b3J5Lg0KPiA+ID4NCj4gPiA+IEZpbGVuYW1lOiAgICAgIGRyYWZ0 LWlldGYtZmVjZnJhbWUtaW50ZXJsZWF2ZWQtZmVjLXNjaGVtZQ0KPiA+ID4gUmV2aXNpb246ICAg ICAgMDQNCj4gPiA+IFRpdGxlOiAgICAgICAgICAgICAgICAgUlRQIFBheWxvYWQgRm9ybWF0IGZv ciAxLUQgDQo+ID4gSW50ZXJsZWF2ZWQgUGFyaXR5IEZFQw0KPiA+ID4gQ3JlYXRpb25fZGF0ZTog ICAgICAgICAyMDA5LTA0LTI5DQo+ID4gPiBXRyBJRDogICAgICAgICAgICAgICAgIGZlY2ZyYW1l DQo+ID4gPiBOdW1iZXJfb2ZfcGFnZXM6IDMxDQo+ID4gPg0KPiA+ID4gQWJzdHJhY3Q6DQo+ID4g PiBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBuZXcgUlRQIHBheWxvYWQgZm9ybWF0IGZvciB0aGUg DQo+IEZvcndhcmQgRXJyb3INCj4gPiA+IENvcnJlY3Rpb24gKEZFQykgdGhhdCBpcyBnZW5lcmF0 ZWQgYnkgdGhlIDEtRCBpbnRlcmxlYXZlZCANCj4gPiBwYXJpdHkgY29kZQ0KPiA+ID4gZnJvbSBh IHNvdXJjZSBtZWRpYSBlbmNhcHN1bGF0ZWQgaW4gUlRQLiAgVGhlIDEtRCANCj4gaW50ZXJsZWF2 ZWQgcGFyaXR5DQo+ID4gPiBjb2RlIGlzIGEgc3lzdGVtYXRpYyBjb2RlLCB3aGVyZSBhIG51bWJl ciBvZiByZXBhaXIgc3ltYm9scyBhcmUNCj4gPiA+IGdlbmVyYXRlZCBmcm9tIGEgc2V0IG9mIHNv dXJjZSBzeW1ib2xzIGFuZCBzZW50IGluIGEgcmVwYWlyIGZsb3cNCj4gPiA+IHNlcGFyYXRlIGZy b20gdGhlIHNvdXJjZSBmbG93IHRoYXQgY2FycmllcyB0aGUgc291cmNlIA0KPiBzeW1ib2xzLiAg VGhlDQo+ID4gPiAxLUQgaW50ZXJsZWF2ZWQgcGFyaXR5IGNvZGUgb2ZmZXJzIGEgZ29vZCBwcm90 ZWN0aW9uIA0KPiBhZ2FpbnN0IGJ1cnN0eQ0KPiA+ID4gcGFja2V0IGxvc3NlcyBhdCBhIGNvc3Qg b2YgZGVjZW50IGNvbXBsZXhpdHkuICBUaGUgbmV3IA0KPiA+IHBheWxvYWQgZm9ybWF0DQo+ID4g PiBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgaXMgdXNlZCAod2l0aCBzb21lIGV4Y2VwdGlvbnMp IA0KPiBhcyBhIHBhcnQgb2YNCj4gPiA+IHRoZSBEVkIgQXBwbGljYXRpb24tbGF5ZXIgRkVDIHNw ZWNpZmljYXRpb24uDQo+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCj4gPiAgICAgICAgICAgICAgICAgICAgICANCj4gPiA+ DQo+ID4gPg0KPiA+ID4gVGhlIElFVEYgU2VjcmV0YXJpYXQuDQo+ID4gPg0KPiA+ID4NCj4gPiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBG ZWNmcmFtZSBtYWlsaW5nIGxpc3QNCj4gPiA+IEZlY2ZyYW1lQGlldGYub3JnDQo+ID4gPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZlY2ZyYW1lDQo+ID4gDQo+ID4gDQo+ IA0KPiANCg== From ron.even.tlv@gmail.com Thu Apr 30 23:57:16 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEF8E3A6F3F; Thu, 30 Apr 2009 23:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599] 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 67wLWRqiBjoW; Thu, 30 Apr 2009 23:57:15 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id 9AECA3A6E0A; Thu, 30 Apr 2009 23:57:14 -0700 (PDT) Received: by bwz7 with SMTP id 7so2193054bwz.37 for ; Thu, 30 Apr 2009 23:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=vNj7MudDL3Env6XYGraqiWWyG8SkfD6TWM9T1I7p1TI=; b=rnJd2W6F9qvHbEyn4KFO68BlqOx6xKFwjDb5YBAve0pNliXIMRcUacj4V/SB6dvDG/ gMCeKtf1RyTCh/myYh9Uzf8CFI3equK+nwDeRvH1P6rwq2aZR+6ZPUKjS57/T5IPVxSM 8lgG/YlLqS7JK9YepDVbTvQTAd2wLM5jLjwvQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=FNvMN0Q/IaX88zU67BMQ2nwiFc80gOgDrZKQRes4Y1m1bUapMDGmsnFHnHv5xF+b8y SZXdghgRceL6f0M6Vj/pRUfgYoQ0GeelAaTXiLpePv6iPdyeNJZBe1zpfoIoddSuHofS vkpVoRLEeUzBqXBvUE36h/Sg0kAuRRRUJjbHw= Received: by 10.86.68.1 with SMTP id q1mr2616470fga.34.1241161117214; Thu, 30 Apr 2009 23:58:37 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-57-219.red.bezeqint.net [79.177.57.219]) by mx.google.com with ESMTPS id 3sm288086fge.14.2009.04.30.23.58.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Apr 2009 23:58:36 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> <49f9ea83.0637560a.4488.62d2@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D540934913F@xmb-sjc-215.amer.cisco.com> <49fa0498.0405560a.615f.677e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D540934937B@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540934937B@xmb-sjc-215.amer.cisco.com> Date: Fri, 1 May 2009 09:56:31 +0300 Message-ID: <49fa9d9c.0305560a.5885.7b1f@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnJgq+DQP1j7cRATQa6PC9zcfp8gAAD/6reAAsScqAAAXPloAAB7PmAAAfhEBAAD01A8A== Content-Language: en-us Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 06:57:16 -0000 Hi Ali, This is up to the WG to decide if they want to have support for SSRC = multiplexing and the implications of this support. I am not sure what = you mean by "we cannot have a parameter", I see only your view on the = list. If only session multiplexing is allowed then the draft should clearly = state it and in this case I am not sure why you are registering the = video, audio and text media subtypes. Roni -----Original Message----- From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 Sent: Friday, May 01, 2009 2:45 AM To: Roni Even; vincent.roca@inrialpes.fr Cc: avt@ietf.org; fecframe@ietf.org Subject: RE: [AVT] [Fecframe] FW: New Version Notification for = draft-ietf-fecframe-interleaved-fec-scheme-04 Hi Roni, Thanks for the references. However, we cannot have a parameter that will = relate the FEC stream to the source as RFC 4588 did with "apt" since a = lot of possibilities (multiple sources and/or multiple repair flows) are = possible with FEC. Instead, we use grouping and this works just fine in = session multiplexing. Regarding SSRC multiplexing of source and FEC streams, I don't think = giving an explicit example is needed or it is a good idea for this draft = since SSRC-level grouping is just introduced in 4756bis and it will = include such examples anyway (actually the version I submitted today = includes an example). We should better only provide session multiplexing = examples in this draft. This also emphasizes the recommended way of = doing FEC. Reg the registration of the media types and SDP mappings, I believe the = draft has the necessary details. BR, -acbegen > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > Sent: Thursday, April 30, 2009 1:03 PM > To: Ali C. Begen (abegen); vincent.roca@inrialpes.fr > Cc: avt@ietf.org; fecframe@ietf.org > Subject: RE: [AVT] [Fecframe] FW: New Version Notification=20 > for draft-ietf-fecframe-interleaved-fec-scheme-04 >=20 > Ali, > You can find examples in section 8.6 to 8.8 of RFC 4588,=20 > notice that there is an optional parameter for the rtx stream=20 > that defines the relation between the original and the rtx=20 > stream. Similar solution is also specified for redundant=20 > encoding red payload type (RFC 2198). You are offering both=20 > streams with different payload type numbers in the same m-line. > In this case the media type must be video or audio same as=20 > the media type of the protected stream. This is why you=20 > needed the registration for type audio and video >=20 > Roni >=20 > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > Sent: Thursday, April 30, 2009 10:01 PM > To: Roni Even; vincent.roca@inrialpes.fr > Cc: avt@ietf.org; fecframe@ietf.org > Subject: RE: [AVT] [Fecframe] FW: New Version Notification=20 > for draft-ietf-fecframe-interleaved-fec-scheme-04 >=20 > Hi Roni,=20 >=20 > > I noticed that the fec framework will allow SSRC=20 >=20 > Yes, it will not be the recommended way of using FEC, but it=20 > will be supported. The 4756bis draft also supports it now. >=20 > > multiplexing, are you going to specify this in this draft in=20 > > the SDP offer answer section.=20 >=20 > I am not sure what I need to specify additionally in this=20 > section regarding SSRC multiplexing. Could you let me know if=20 > there is such an example? > =20 > > Maybe you should also discuss when to use application media=20 > > type and when to use video or audio >=20 > I believe the FEC is always application type, we did=20 > registration for video, audio, etc. since FEC could relate to=20 > sessions carrying such types. >=20 > BR, > -acbegen > =20 > > =20 > >=20 > > Roni > >=20 > > =20 > >=20 > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > > Behalf Of Ali C. Begen (abegen) > > Sent: Thursday, April 30, 2009 3:54 PM > > To: vincent.roca@inrialpes.fr > > Cc: avt@ietf.org; fecframe@ietf.org > > Subject: Re: [AVT] [Fecframe] FW: New Version Notification=20 > > for draft-ietf-fecframe-interleaved-fec-scheme-04 > >=20 > > =20 > >=20 > > Hi Vincent > >=20 > > This draft is not an fec scheme so it is not related to fec=20 > > framework. It is an rtp payload format draft. The wglc has=20 > > been running almost a month now. If you have comments in this=20 > > perspective, pls submit them soon. > >=20 > >=20 > >=20 > >=20 > > -acbegen > >=20 > > ----- Original Message ----- > > From: Vincent Roca > > To: Ali C. Begen (abegen) > > Cc: fecframe@ietf.org ; avt@ietf.org=20 > > > Sent: Thu Apr 30 03:58:35 2009 > > Subject: Re: [Fecframe] FW: New Version Notification for =20 > > draft-ietf-fecframe-interleaved-fec-scheme-04 > >=20 > > Hello Ali, > >=20 > > I'm not in favor of finalizing the WGLC for this document.=20 > > IMHO we must, > > first of all, finalize the framework document itself. > >=20 > > For instance, the terminology used by the interleaved-fec-scheme I-D > > (section 3.1.) is not in line with the terminology used by the > > fecframe-framework-03 I-D (Section 2): > > "Source Flow" vs. "Source data flow" > > "Repair Flow" vs. "Repair data flow" > > "Source Symbol" vs. nothing > > "Repair Symbol" vs. nothing > > "Source Packet" vs. nothing > > "Repair Packet" vs. nothing > > And as I said before, IMHO the terminology proposed in the framework > > I-D should be discussed too. > >=20 > > So let's do things in the right order, especially as the framework > > WGLC finishes soon. > >=20 > > Additionally, I may have some comments for the=20 > > interleaved-fec-scheme-04 > > I-D. Since I missed the WGLC deadline, you have the right to=20 > > blame me ;-) > > and I apologize in advance. > >=20 > > Regards, > >=20 > > Vincent > >=20 > >=20 > > Ali C. Begen (abegen) wrote: > > > This version addresses the comments received from fecframe=20 > > and avt so far. > > >=20 > > http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interl > eaved-fec-scheme-04.txt > > > > > > > > > Fecframe chairs, > > > > > > Could we proceed and finalize WGLC? > > > > > > -acbegen > > >=20 > > > > > > -----Original Message----- > > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > > Sent: Wednesday, April 29, 2009 2:56 PM > > > To: Ali C. Begen (abegen) > > > Subject: New Version Notification for=20 > > draft-ietf-fecframe-interleaved-fec-scheme-04 > > > > > > > > > A new version of I-D,=20 > > draft-ietf-fecframe-interleaved-fec-scheme-04.txt has been=20 > > successfuly submitted by Ali Begen and posted to the IETF=20 > repository. > > > > > > Filename: draft-ietf-fecframe-interleaved-fec-scheme > > > Revision: 04 > > > Title: RTP Payload Format for 1-D=20 > > Interleaved Parity FEC > > > Creation_date: 2009-04-29 > > > WG ID: fecframe > > > Number_of_pages: 31 > > > > > > Abstract: > > > This document defines a new RTP payload format for the=20 > Forward Error > > > Correction (FEC) that is generated by the 1-D interleaved=20 > > parity code > > > from a source media encapsulated in RTP. The 1-D=20 > interleaved parity > > > code is a systematic code, where a number of repair symbols are > > > generated from a set of source symbols and sent in a repair flow > > > separate from the source flow that carries the source=20 > symbols. The > > > 1-D interleaved parity code offers a good protection=20 > against bursty > > > packet losses at a cost of decent complexity. The new=20 > > payload format > > > defined in this document is used (with some exceptions)=20 > as a part of > > > the DVB Application-layer FEC specification. > > > =20 > > =20 > > > > > > > > > The IETF Secretariat. > > > > > > > > > _______________________________________________ > > > Fecframe mailing list > > > Fecframe@ietf.org > > > https://www.ietf.org/mailman/listinfo/fecframe > >=20 > >=20 >=20 >=20