From nobody Mon Apr 1 15:57:49 2019 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBB4120193 for ; Mon, 1 Apr 2019 15:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=networked-media.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHkagzsY4sGT for ; Mon, 1 Apr 2019 15:57:44 -0700 (PDT) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE1061201B1 for ; Mon, 1 Apr 2019 15:57:44 -0700 (PDT) Received: by mail-yb1-xb2f.google.com with SMTP id b18so4092137yba.12 for ; Mon, 01 Apr 2019 15:57:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networked-media.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PP1LjK+ZEKDtLhMT1KS0SZZKnnjpAtTzsj5LFr62iOs=; b=zAKYMMRKq8/JdsQphoaT7M6K8uTNPFPuHF8O7vC9fEmsRGYUQHyP7+XKwGLcH9Vydb h2xglRtR7I9oltHnZPJ2icX2j7h0GyyOW3fFJZObnpJMNREqclaNJpAZXvTL5e7BalDS hU+lrOCXyS/bhmwyEvEtiiTf1xcuiynU5SJ6KF8ejg4LlfH/XfD0I0tRCLmG8LQuwS5o qIN9gIAclUU3Qv5A/P2+imoMrrPFwsaYgC0GYVEdMMzaW08TOOAkPHRdQvxT7C3kJhK1 /C43Y4it+m2PyiQLkrp9VhK1wfq2BsG3hbJmGGQeNK/Kj0JYcOwcnzDb7pBRHMhVbhs0 5SOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PP1LjK+ZEKDtLhMT1KS0SZZKnnjpAtTzsj5LFr62iOs=; b=t1d7kuhpv+AzidIXOFpPZjB69eNJvLro4wFGe9VIUX/Z4+MxMHFNk35i+uwti8iG1V PsG/2RxAfTbF48wsvpQdvh2+bFlFYtUXsPvqzuIfQRdmdZm6kADVRNUpyLIBJ5mN7o6z 9+zLk4hs0tpV9lE3/n4CVjlUb1VxDX/sFoeG8xCQzJT7JJ1sMzzwqRdBdRYKns12PyYF Y09WrUSNzqkwfjaVvLxooH2xqKzCvn76QWj8IaSYQmusnbmtc9LRxX2oFg/IzkzqNvVo m4+IrN+fpAG8YxuCZCaB0cqmo3ZmxijLx07vvgQr7bcqb93Y4VQ8f6pS9bZpFTNsOuvU 9PQQ== X-Gm-Message-State: APjAAAXeYIypxl0KXwW/VVbviQ2Hu9hrxSZlTBOnZqmKg2mU09Bmjt8L 690nYYapn6DCUgJI99jPeRhqls3JpGeDkzdoOH7ftw== X-Google-Smtp-Source: APXvYqweVGATRgNc8/9kpDr+HSbhlG5z1/RVxNplz/bNPK1mRvn9FndymR53AZOcQQol+9lAon3VpUrPzfszx581dVw= X-Received: by 2002:a5b:28c:: with SMTP id x12mr54318617ybl.196.1554159463734; Mon, 01 Apr 2019 15:57:43 -0700 (PDT) MIME-Version: 1.0 References: <5e948e46153445c892dc661085d21073@NASANEXM01C.na.qualcomm.com> In-Reply-To: <5e948e46153445c892dc661085d21073@NASANEXM01C.na.qualcomm.com> From: "Ali C. Begen" Date: Tue, 2 Apr 2019 01:57:32 +0300 Message-ID: To: Giridhar Mandyam Cc: "payload@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c2b9d905857ff202" Archived-At: Subject: Re: [payload] Updates on FLEX FEC (ver -19) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 22:57:48 -0000 --000000000000c2b9d905857ff202 Content-Type: text/plain; charset="UTF-8" Folks, please provide feedback. There are important changes in the flex fec and in a few days, the draft will be shipped to the RFC editor. Thanks. On Thu, Mar 28, 2019 at 9:19 PM Giridhar Mandyam wrote: > Dear Payload WG, > > After offline discussion with the editors and reviewers (special thanks to > Bernard Aboba), we have decided that the spec needed to be slightly > modified. Version -19 contains the following changes: > > a) Recommendation against negotiation of RTP RTX when FLEX FEC is used. A > new section 1.1.7 on the use of FLEX FEC retransmissions has been added to > indicate as such. > > b) Elimination of all optional SDP parameters (e.g. ToP, L and D fields). > This means that the sender can send any FEC configuration (as indicated by > the FEC header) as long as it stays consistent with the mandatory SDP > parameters (rate and repair window). Sec. 1.1.6, 1.1.7, 4.2.2, and 5 are > the primary impacted sections. We believe this will greatly simplify SDP > O/A and while retaining the "flexibility" of FLEX FEC to adapt FEC repair > data on a packet-by-packet basis. > - Note that L and D cannot be larger than 255, respectively. As > we gain implementation experience, if we decide that 255 is not sufficient > then it could be possible to extend the corresponding header fields in the > future. Currently there are header values that are reserved (R=F=1 and > L=D=0) that could be used to indicate the use of an extended L and D field, > as an example of one way to implement extended fields for L and D. > > c) Slight adjustment of Sec. 6.3.1.2 to correct for sequence numbering > errors in the abstract procedure for grouping of source packets using their > RTP sequence numbers. > > d) Accounting for the remaining nit's in Benjamin Kaduk's last review. > > e) Explicitly defining "FLEX FEC" in the abstract. > > Please provide any feedback within 7 days of the sending of this > notification. > > Thank you, > > -The Editors of FLEX FEC > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > --000000000000c2b9d905857ff202 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Folks, please provide feedback. There are important change= s in the flex fec and in a few days, the draft will be shipped to the RFC e= ditor.

Thanks.

On Thu, Mar 28, 2019 at 9:19 PM Giri= dhar Mandyam <mandyam@qti.qu= alcomm.com> wrote:
Dear Payload WG,

After offline discussion with the editors and reviewers (special thanks to = Bernard Aboba), we have decided that the spec needed to be slightly modifie= d.=C2=A0 Version -19 contains the following changes:

a) Recommendation against negotiation of RTP RTX when FLEX FEC is used.=C2= =A0 A new section 1.1.7 on the use of FLEX FEC retransmissions has been add= ed to indicate as such.

b) Elimination of all optional SDP parameters (e.g. ToP, L and D fields).= =C2=A0 This means that the sender can send any FEC configuration (as indica= ted by the FEC header) as long as it stays consistent with the mandatory SD= P parameters (rate and repair window).=C2=A0 Sec. 1.1.6, 1.1.7, 4.2.2, and = 5 are the primary impacted sections.=C2=A0 We believe this will greatly sim= plify SDP O/A and while retaining the "flexibility" of FLEX FEC t= o adapt FEC repair data on a packet-by-packet basis.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Note that L and D cannot be larger than 255, = respectively.=C2=A0 As we gain implementation experience, if we decide that= 255 is not sufficient then it could be possible to extend the correspondin= g header fields in the future. Currently there are header values that are r= eserved (R=3DF=3D1 and=C2=A0 L=3DD=3D0) that could be used to indicate the = use of an extended L and D field, as an example of one way to implement ext= ended fields for L and D.

c) Slight adjustment of Sec. 6.3.1.2 to correct for sequence numbering erro= rs in the abstract procedure for grouping of source packets using their RTP= sequence numbers.

d) Accounting for the remaining nit's in Benjamin Kaduk's last revi= ew.

e) Explicitly defining "FLEX FEC" in the abstract.

Please provide any feedback within 7 days of the sending of this notificati= on.

Thank you,

-The Editors of FLEX FEC


_______________________________________________
payload mailing list
payload@ietf.org<= br> https://www.ietf.org/mailman/listinfo/payload
--000000000000c2b9d905857ff202-- From nobody Tue Apr 2 09:59:20 2019 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0418E120169 for ; Tue, 2 Apr 2019 09:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivwnaD0pV6iK for ; Tue, 2 Apr 2019 09:59:17 -0700 (PDT) Received: from smtp80.iad3a.emailsrvr.com (smtp80.iad3a.emailsrvr.com [173.203.187.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9796120003 for ; Tue, 2 Apr 2019 09:59:16 -0700 (PDT) Received: from smtp19.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp19.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id ACCE253E6; Tue, 2 Apr 2019 12:59:15 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp19.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 40FE337E6; Tue, 2 Apr 2019 12:59:15 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Tue, 02 Apr 2019 12:59:15 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_0C043370-9994-48ED-9E6D-9E2D7CE8A160" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Cullen Jennings In-Reply-To: <5e948e46153445c892dc661085d21073@NASANEXM01C.na.qualcomm.com> Date: Tue, 2 Apr 2019 10:59:14 -0600 Cc: "payload@ietf.org" Message-Id: <09C61B56-FBD5-4C1F-BF5F-FD8757C34575@iii.ca> References: <5e948e46153445c892dc661085d21073@NASANEXM01C.na.qualcomm.com> To: Giridhar Mandyam X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [payload] Updates on FLEX FEC (ver -19) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 16:59:19 -0000 --Apple-Mail=_0C043370-9994-48ED-9E6D-9E2D7CE8A160 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 28, 2019, at 12:18 PM, Giridhar Mandyam = wrote: >=20 > b) Elimination of all optional SDP parameters (e.g. ToP, L and D = fields). This means that the sender can send any FEC configuration (as = indicated by the FEC header) as long as it stays consistent with the = mandatory SDP parameters (rate and repair window). Sec. 1.1.6, 1.1.7, = 4.2.2, and 5 are the primary impacted sections. We believe this will = greatly simplify SDP O/A and while retaining the "flexibility" of FLEX = FEC to adapt FEC repair data on a packet-by-packet basis.=20 > - Note that L and D cannot be larger than 255, respectively. As = we gain implementation experience, if we decide that 255 is not = sufficient then it could be possible to extend the corresponding header = fields in the future. Currently there are header values that are = reserved (R=3DF=3D1 and L=3DD=3D0) that could be used to indicate the = use of an extended L and D field, as an example of one way to implement = extended fields for L and D. I=E2=80=99m strongly apposed to making this huge change at this late = stage. It means the receiver has no ability to influence the FEC even = thought on small device it may need to. It is just as important for the = receiver to be able to have influence over what happens as the sender. = We should not remove this. Removing this will cause some people to just = keep using old FEC schemes instead of moving to something even as simply = 1D with flex fec.=20 I know we wish everyone would implement the most advanced version of = everything we specify, but this will have the opposite effect of just = deciding not to implement it at all.=20 --Apple-Mail=_0C043370-9994-48ED-9E6D-9E2D7CE8A160 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 28, 2019, at 12:18 PM, Giridhar Mandyam <mandyam@qti.qualcomm.com> wrote:

b) Elimination of all optional = SDP parameters (e.g. ToP, L and D fields).  This means that the = sender can send any FEC configuration (as indicated by the FEC header) = as long as it stays consistent with the mandatory SDP parameters (rate = and repair window).  Sec. 1.1.6, 1.1.7, 4.2.2, and 5 are the = primary impacted sections.  We believe this will greatly simplify = SDP O/A and while retaining the "flexibility" of FLEX FEC to adapt FEC = repair data on a packet-by-packet basis. 
- Note that L = and D cannot be larger than 255, respectively.  As we gain = implementation experience, if we decide that 255 is not sufficient then = it could be possible to extend the corresponding header fields in the = future. Currently there are header values that are reserved (R=3DF=3D1 = and  L=3DD=3D0) that could be used to indicate the use of an = extended L and D field, as an example of one way to implement extended = fields for L and D.

I=E2=80=99m strongly apposed to making this = huge change at this late stage. It means the receiver has no ability to = influence the FEC even thought on small device it may need to. It is = just as important for the receiver to be able to have influence over = what happens as the sender. We should not remove this. Removing this = will cause some people to just keep using old FEC schemes instead of = moving to something even as simply 1D with flex fec. 

I know we wish everyone = would implement the most advanced version of everything we specify, but = this will have the opposite effect of just deciding not to implement it = at all. 





= --Apple-Mail=_0C043370-9994-48ED-9E6D-9E2D7CE8A160-- From nobody Tue Apr 2 10:55:04 2019 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92A7120172 for ; Tue, 2 Apr 2019 10:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQl2jSFrrN9O for ; Tue, 2 Apr 2019 10:54:58 -0700 (PDT) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05C45120182 for ; Tue, 2 Apr 2019 10:54:58 -0700 (PDT) Received: by mail-ua1-x930.google.com with SMTP id d5so4676062uan.6 for ; Tue, 02 Apr 2019 10:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VutlxtZGNcoiIJYssbuyfojjpfpjPPAfJKRIJs9npeA=; b=muF889fuJAhZuIZzHjfzQ8h0/csp9ZcsU0GNm2VJOsH6AB6B0MTI1z9t7jVSWSfGRb EswPrh7OooV5sS44MiUCeQG5k8KL9iesT88hnkjhqfrGDnTxgkNf1Bw+g5ZPOHJqdak4 QdQiBOyN66PDGaR/LoPPyNxp/4WThWGniKhFR6gpKwWUC0tQST6BAtJjkAX3elKwQYH0 wUdWMZ/JidSfHpFAKrACh5x8PbgET/g6PYNffLhflkuE0UvolRcucKd69RGwXJvOtP9Q AvQk7Xndy1bpVr+75xVsLWXQOPPsXxrZXoVQA1Ko250aJcvzbyqLKnpOBslvihERswmC vttA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VutlxtZGNcoiIJYssbuyfojjpfpjPPAfJKRIJs9npeA=; b=HlYIiQ34kqmASmP26GBBcrsqkzTAad2SFKAO1HQUWV/Vi7wlq9Q+Ay646DAtk5bMVf YzZA/0+pI0U390tLTKX+MBBQzSurw+mLtMyWaKVyjEZDNP6GGesUup3UuYzWPorDw5TA M4A2S4Nep8Z/Z69P9GWdH5pNHntWkdgobmpbVHgARRcyWyXlL3oJVJ1m0kNF0AhFPnLD m1me2n0d/58UV5HqlNuxCS2zLCqU9LNE8a6PlO/dLrlk+BMNlQzed/J7Z9wAZla6hs5c RZl2pFOF8EuyNCci0b4qSUD9m1olEkGvToIiG32aH0FbAuDPWykA0cZS3cttqpZRib3o D1fQ== X-Gm-Message-State: APjAAAWlMLhYexxHDTiMFXbgDoX704yDhUhKWtAzV4BrPiK3a/BH1NCw thUCYjICy6AhNrCfa55qLH/UcSMAgCfawBF5JLM= X-Google-Smtp-Source: APXvYqy+poNem0gsKm8oU2AicBfYgbRP4HHPf3SJ9psbqrOwug8P/KDPFbRxrKktvo7WIeIJwqHnJtJEGLZ759vxt8o= X-Received: by 2002:ab0:70d4:: with SMTP id r20mr36402427ual.67.1554227696658; Tue, 02 Apr 2019 10:54:56 -0700 (PDT) MIME-Version: 1.0 References: <5e948e46153445c892dc661085d21073@NASANEXM01C.na.qualcomm.com> In-Reply-To: From: Bernard Aboba Date: Tue, 2 Apr 2019 13:54:45 -0400 Message-ID: To: "Ali C. Begen" Cc: Giridhar Mandyam , "payload@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c26eda05858fd53a" Archived-At: Subject: Re: [payload] Updates on FLEX FEC (ver -19) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 17:55:02 -0000 --000000000000c26eda05858fd53a Content-Type: text/plain; charset="UTF-8" Here is my feedback. IMHO the new draft is an improvement, because it makes clear what is mandatory to implement (almost everything) as well as clarifying the SDP negotiation (which seemed quite unclear before). Both of these issues had been encountered in implementations and were likely to lead to interoperability problems. The clarifications do raise the bar in terms of what an implementation needs to be able to handle, but AFAICT not to an unreachable level (at least in a browser or a game console environment). In terms of specific comments: 1.1.7 . FEC Protection with Retransmission This specification supports both forward error correction, i.e. before any loss is reported, as well as retransmission of source packets after loss is reported. The retransmission includes the RTP header of the source packet in addition to the payload. Therefore, endpoints supporting other RTP retransmission methods (see [RFC4588 ]) in addition to FLEX FEC MUST only use the FLEX FEC retransmission method. [BA] I would like to see this rephrased in Offer/Answer terminology. For example, "If a peer supporting both FLEX FEC and other RTP retransmission methods (see [RFC4588]) receives an Offer including both FLEX FEC and another RTP retransmission method, it MUST respond with an Answer containing only FLEX FEC." On Mon, Apr 1, 2019 at 6:57 PM Ali C. Begen wrote: > Folks, please provide feedback. There are important changes in the flex > fec and in a few days, the draft will be shipped to the RFC editor. > > Thanks. > > On Thu, Mar 28, 2019 at 9:19 PM Giridhar Mandyam > wrote: > >> Dear Payload WG, >> >> After offline discussion with the editors and reviewers (special thanks >> to Bernard Aboba), we have decided that the spec needed to be slightly >> modified. Version -19 contains the following changes: >> >> a) Recommendation against negotiation of RTP RTX when FLEX FEC is used. >> A new section 1.1.7 on the use of FLEX FEC retransmissions has been added >> to indicate as such. >> >> b) Elimination of all optional SDP parameters (e.g. ToP, L and D >> fields). This means that the sender can send any FEC configuration (as >> indicated by the FEC header) as long as it stays consistent with the >> mandatory SDP parameters (rate and repair window). Sec. 1.1.6, 1.1.7, >> 4.2.2, and 5 are the primary impacted sections. We believe this will >> greatly simplify SDP O/A and while retaining the "flexibility" of FLEX FEC >> to adapt FEC repair data on a packet-by-packet basis. >> - Note that L and D cannot be larger than 255, respectively. As >> we gain implementation experience, if we decide that 255 is not sufficient >> then it could be possible to extend the corresponding header fields in the >> future. Currently there are header values that are reserved (R=F=1 and >> L=D=0) that could be used to indicate the use of an extended L and D field, >> as an example of one way to implement extended fields for L and D. >> >> c) Slight adjustment of Sec. 6.3.1.2 to correct for sequence numbering >> errors in the abstract procedure for grouping of source packets using their >> RTP sequence numbers. >> >> d) Accounting for the remaining nit's in Benjamin Kaduk's last review. >> >> e) Explicitly defining "FLEX FEC" in the abstract. >> >> Please provide any feedback within 7 days of the sending of this >> notification. >> >> Thank you, >> >> -The Editors of FLEX FEC >> >> >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >> > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > --000000000000c26eda05858fd53a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here is my feedback.=C2=A0

IMHO the new= draft is an improvement, because it makes clear what is mandatory to imple= ment (almost everything) as well as clarifying the SDP negotiation (which s= eemed quite unclear before).=C2=A0

Both of these i= ssues had been encountered in implementations and were likely to lead to in= teroperability problems.=C2=A0

The clarifications = do raise the bar in terms of what an implementation needs to be able to han= dle, but AFAICT not to an unreachable level (at least in a browser or a gam= e console environment).=C2=A0

In terms of specific= comments:=C2=A0

1.1.7.  FEC Protection with Retransmission


   This specification supports both forward error correction, i.e.
   before any loss is reported, as well as retransmission of source
   packets after loss is reported.  The retransmission includes the RTP
   header of the source packet in addition to the payload.  Therefore,
   endpoints supporting other RTP retransmission methods (see [RFC4588])
   in addition to FLEX FEC MUST only use the FLEX FEC retransmission
   method.

[BA] I would like to=
 see this rephrased in Offer/Answer terminology.  For example,
"If a peer supporting bot=
h FLEX FEC and other RTP retransmission methods (see [RFC4588])
receives an Offer including b=
oth FLEX FEC and another RTP retransmission method, it
MUST respond with an Answer containing=
 only FLEX FEC."



On Mon, Apr = 1, 2019 at 6:57 PM Ali C. Begen <ali.begen@networked.media> wrote:
F= olks, please provide feedback. There are important changes in the flex fec = and in a few days, the draft will be shipped to the RFC editor.

Thanks.

On Thu, Mar 28, 2019 at 9:19 PM Giridhar Mandyam <<= a href=3D"mailto:mandyam@qti.qualcomm.com" target=3D"_blank">mandyam@qti.qu= alcomm.com> wrote:
Dear Payload WG,

After offline discussion with the editors and reviewers (special thanks to = Bernard Aboba), we have decided that the spec needed to be slightly modifie= d.=C2=A0 Version -19 contains the following changes:

a) Recommendation against negotiation of RTP RTX when FLEX FEC is used.=C2= =A0 A new section 1.1.7 on the use of FLEX FEC retransmissions has been add= ed to indicate as such.

b) Elimination of all optional SDP parameters (e.g. ToP, L and D fields).= =C2=A0 This means that the sender can send any FEC configuration (as indica= ted by the FEC header) as long as it stays consistent with the mandatory SD= P parameters (rate and repair window).=C2=A0 Sec. 1.1.6, 1.1.7, 4.2.2, and = 5 are the primary impacted sections.=C2=A0 We believe this will greatly sim= plify SDP O/A and while retaining the "flexibility" of FLEX FEC t= o adapt FEC repair data on a packet-by-packet basis.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Note that L and D cannot be larger than 255, = respectively.=C2=A0 As we gain implementation experience, if we decide that= 255 is not sufficient then it could be possible to extend the correspondin= g header fields in the future. Currently there are header values that are r= eserved (R=3DF=3D1 and=C2=A0 L=3DD=3D0) that could be used to indicate the = use of an extended L and D field, as an example of one way to implement ext= ended fields for L and D.

c) Slight adjustment of Sec. 6.3.1.2 to correct for sequence numbering erro= rs in the abstract procedure for grouping of source packets using their RTP= sequence numbers.

d) Accounting for the remaining nit's in Benjamin Kaduk's last revi= ew.

e) Explicitly defining "FLEX FEC" in the abstract.

Please provide any feedback within 7 days of the sending of this notificati= on.

Thank you,

-The Editors of FLEX FEC


_______________________________________________
payload mailing list
payload@ietf.org<= br> https://www.ietf.org/mailman/listinfo/payload
_______________________________________________
payload mailing list
payload@ietf.org<= br> https://www.ietf.org/mailman/listinfo/payload
--000000000000c26eda05858fd53a-- From nobody Wed Apr 10 10:27:08 2019 Return-Path: X-Original-To: payload@ietf.org Delivered-To: payload@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39ACA120603; Wed, 10 Apr 2019 10:27:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: payload@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: payload@ietf.org Message-ID: <155491722719.9429.13349317873691954223@ietfa.amsl.com> Date: Wed, 10 Apr 2019 10:27:07 -0700 Archived-At: Subject: [payload] I-D Action: draft-ietf-payload-rtp-jpegxs-01.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 17:27:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads WG of the IETF. Title : RTP Payload Format for ISO/IEC 21122 (JPEG XS) Authors : Sébastien Lugan Gaël Rouvroy Antonin Descampe Thomas Richter Alexandre Willeme Filename : draft-ietf-payload-rtp-jpegxs-01.txt Pages : 19 Date : 2019-04-10 Abstract: This document specifies a Real-Time Transport Protocol (RTP) payload format to be used for transporting JPEG XS (ISO/IEC 21122) encoded video. JPEG XS is a low-latency, lightweight image coding system. Compared to an uncompressed video use case, it allows higher resolutions and frame rates, while offering visually lossless quality, reduced power consumption, and end-to-end latency confined to a fraction of a frame. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-jpegxs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-payload-rtp-jpegxs-01 https://datatracker.ietf.org/doc/html/draft-ietf-payload-rtp-jpegxs-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-jpegxs-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 11 09:24:22 2019 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3E21203F8 for ; Thu, 11 Apr 2019 09:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dynmail.crt1.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWp6wHg97m6C for ; Thu, 11 Apr 2019 09:24:17 -0700 (PDT) Received: from mail.crt1.net (smtp-6to4.mail.seb.crt1.net [IPv6:2002:4f89:4abc:ffff:1::101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEBEC1202E8 for ; Thu, 11 Apr 2019 09:24:15 -0700 (PDT) Received: from micro.mail.seb.crt1.net (ecc7826c7133.n2_pvt [IPv6:fd68:2323:388:50:ffff::105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.crt1.net (SebMail/v2.00) with ESMTPS id 96BC120032; Thu, 11 Apr 2019 18:24:10 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.crt1.net 96BC120032 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dynmail.crt1.net; s=dkim; t=1554999850; bh=XzcPRI+t6Z3Qk+p7NXuKC9bhDo36ryzlLh6Ti9+6SQU=; h=To:From:Subject:Cc:Date:From; b=CW4HkHeiTijXpAcbj1FJKEvFBSOy1ZfCTHzjN6X+zEkJWJYrTWDeQFgEH+FRsLrmH 0d2I2l6maTjJlPpWFG+SFTmxDouNOVKXPMRf/QJOv1GLCJsUiKQAgw0sqP+lDluLj4 gDYP77XecBV5QFBNpYg+JqFGm7pOEY2r6tw45P6C3KVFoGUhAG+rJtVxIveUIIDCpu NCDgKm8TC9cdeVmWb3G2H2UMtJm/wEv2DmM0epT62lgHBGdWrldA9KZ9YArhsksoYm clTs/wBDo349rUhkhlDlDwqC4kecC/VVsTga8V6U3R+55QEUJzwIePoY1DcIpeimkP iA66nhy3Pegpw== Received: from [IPv6:fd68:2323:388:114::1] (unknown [IPv6:fd68:2323:388:114::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by micro.mail.seb.crt1.net (SebMicroMail/v1.00) with ESMTPS id 71FDF2002C; Thu, 11 Apr 2019 18:24:10 +0200 (CEST) To: payload@ietf.org From: =?UTF-8?Q?S=c3=a9bastien_Lugan?= Cc: Antonin Descampe , Thomas Richter , Alexandre Willeme , =?UTF-8?Q?Ga=c3=abl_Rouvroy?= Message-ID: <8c9869cf-8d53-9072-286f-bc17e1764729@seb.advanced-ip.crt1.net> Date: Thu, 11 Apr 2019 18:24:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [payload] draft-ietf-payload-rtp-jpegxs-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 16:24:20 -0000 Dear all, Please find below an updated version of draft-ietf-payload-rtp-jpegxs: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-jpegxs/ https://www.ietf.org/id/draft-ietf-payload-rtp-jpegxs-01.txt This version tries to address most of the comments we received (annotated list: https://docs.google.com/document/d/1ARCZYlHUXTkT2_-ULkLNdYuT6hk3jZ2Cs1xy6eAwie8/edit ). In addition, the following improvements have been made: - simplifications: - no more fragments nor slice groups, - simplification of the payload header, - paragraph and figure related to the packetization of a JPEG XS codestream moved from Section 3 (Media format description) to Section 4 (payload format), - various clarifications and reformulations; - addition of a color specification box (in addition to the video support box); - media type renamed to video/jxsv to be consistent with media types already defined for JPEG XS (image/jxs, image/jxss, image/jxsi, image/jxsc). Please do not hesitate to send us your remarks, comments and suggestions regarding this new version. Thanks in advance, Best regards, Sébastien Lugan From nobody Thu Apr 25 03:56:59 2019 Return-Path: X-Original-To: payload@ietf.org Delivered-To: payload@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 096B2120021; Thu, 25 Apr 2019 03:56:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: payload@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: payload@ietf.org Message-ID: <155618981096.23475.8422583355533384403@ietfa.amsl.com> Date: Thu, 25 Apr 2019 03:56:51 -0700 Archived-At: Subject: [payload] I-D Action: draft-ietf-payload-rtp-ttml-01.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 10:56:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads WG of the IETF. Title : RTP Payload for TTML Timed Text Author : James Sandford Filename : draft-ietf-payload-rtp-ttml-01.txt Pages : 15 Date : 2019-04-25 Abstract: This memo describes a Real-time Transport Protocol (RTP) payload format for TTML, an XML based timed text format for live and file based workflows from W3C. This payload format is specifically targeted at live workflows using TTML. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-ttml/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-payload-rtp-ttml-01 https://datatracker.ietf.org/doc/html/draft-ietf-payload-rtp-ttml-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-ttml-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 25 04:03:14 2019 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9977120071 for ; Thu, 25 Apr 2019 04:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bB-aMmrdBRk for ; Thu, 25 Apr 2019 04:03:10 -0700 (PDT) Received: from mailout1.cwwtf.bbc.co.uk (mailout1.cwwtf.bbc.co.uk [132.185.160.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F02120021 for ; Thu, 25 Apr 2019 04:03:10 -0700 (PDT) Received: from BGB01XI1010.national.core.bbc.co.uk (bgb01xi1010.national.core.bbc.co.uk [10.161.14.14]) by mailout1.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id x3PB38Zd021983 for ; Thu, 25 Apr 2019 12:03:08 +0100 (BST) Received: from BGB01XI1004.national.core.bbc.co.uk (10.184.50.54) by BGB01XI1010.national.core.bbc.co.uk (10.161.14.14) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 25 Apr 2019 12:03:08 +0100 Received: from BGB01XUD1001.national.core.bbc.co.uk ([10.184.52.80]) by BGB01XI1004.national.core.bbc.co.uk ([10.184.50.54]) with mapi id 14.03.0408.000; Thu, 25 Apr 2019 12:03:05 +0100 From: James Sandford To: "payload@ietf.org" Thread-Topic: draft-ietf-payload-rtp-ttml-01 Thread-Index: AdT7VlQ3BCOEJKYgROOsDFQqQ3MOpQ== Date: Thu, 25 Apr 2019 11:03:04 +0000 Message-ID: <734752AF0E88364D983373FE5CEFED5759511DFA@bgb01xud1001> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.212] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.2.1013-24054.007 X-TM-AS-Result: No-4.545400-8.000000-10 X-TMASE-MatchedRID: kJ09j7qenzCRTfgfKCWeWsK1Ib9JAALxKx5ICGp/WtG638ZUY6gSd7do r5TBU2lyDG9GVY7e3suSu+bwQnj5Z1R6onqcwQyn5DSMPEZQAkP7RKDUj/7lwS1bKLdhloRJM6L 7GI9gT+uG9q1iO90XWl3uZ8qTIJ6Wo5RUoF1j1rjKt6QEbZDnyoEcpMn6x9cZvStYzicikmsclG SxZ4ugJnb4Bm7FqQnLPnI1EZ0G8mxTeZCGZ2HhGAwfhKwa9GwDBgA+oehWZhFCI7pNLiSjfeCfw dXr9Uztb2i4jKCmMNKrLW8uEEp/W/MTBQjTvrpg/zHKAEIZbPS6ONg3bN/9Kpsoi2XrUn/J5AP+ yqovSZka3uZ27iW8TtAtbEEX0MxBm+MB6kaZ2g7iiWOfD/Z/tk6Rgci2eaf5Lf9FJEmh0FdbM+e uBXbEHny31CGEbWUSIgMXA9bvBNhzlGd4o4fmSlXu/0eOq++2u3g2emwM/MAacsnD3yv6d2qtY+ SNmslUYtd4xFC0bZ38qUTNZxJ8gAbrBWCb56TEG2Q4wl7vs3F2Ik3N2hJScrHBXh9M7L4sWKKVA sjp9U0= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--4.545400-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.2.1013-24054.007 Content-Type: multipart/alternative; boundary="_000_734752AF0E88364D983373FE5CEFED5759511DFAbgb01xud1001_" MIME-Version: 1.0 Archived-At: Subject: [payload] draft-ietf-payload-rtp-ttml-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 11:03:13 -0000 --_000_734752AF0E88364D983373FE5CEFED5759511DFAbgb01xud1001_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please find the latest version of draft-ietf-payload-rtp-ttml at: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-ttml/ https://www.ietf.org/id/draft-ietf-payload-rtp-ttml-01.txt Changes are: - Clarification to wording of when processing of a document may be stopped - Completion of RFC Editior Considerations section - Completion of Acknowledgements section - Minor improvement to formatting in RTP Header Usage section Any comments/suggestions appreciated. Regards, James =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D James Sandford R&D Engineer BBC Research and Development 5th Floor Dock House MediaCityUK Salford M50 2LH Tel: 030304 (09549) Web: http://www.bbc.co.uk/rd --_000_734752AF0E88364D983373FE5CEFED5759511DFAbgb01xud1001_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Please find the latest version of draft-ietf-payload-rtp-ttml a= t:

Changes are:
- Clarification to wording of when processing of a document may be sto= pped
- Completion of RFC Editior Considerations section
- Completion of Acknowledgements section
- Minor improvement to formattin= g in RTP Header Usage section

Any comments/suggestions appreciated.

Regards,
James

        &n= bsp;      
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
James Sandford
R&D Engineer

BBC Research and Development
5th Floor
Dock House
MediaCityUK
Salford
M50 2LH

Tel: 030304 (09549)
Web: http://www.bbc.co.uk/rd
--_000_734752AF0E88364D983373FE5CEFED5759511DFAbgb01xud1001_--