From nobody Mon Aug 8 14:40:47 2016 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 A2CF712D158; Mon, 8 Aug 2016 14:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-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 ppLnBerFNVMk; Mon, 8 Aug 2016 14:40:44 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 207B912D176; Mon, 8 Aug 2016 14:40:44 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id q128so143172518wma.1; Mon, 08 Aug 2016 14:40:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=u0TBkdx9w2eInWkgPDrIFWzwPwGPt+H5XL8zROnGIRg=; b=nPtZZppzYWzZpPXhj6sfFTbB3Mjvk+IgmaoNBdk51SxWJz7CXluUBWOfsLw+rkdkYj aLBKJMY0cJMB39jj3cHDXO/PtulRBuzF+Uwsac6tUEoaJQ1x4sUxUQugqxLalGt3541y 04aPR5h670rY7tYnT4aJiy/gvvHdQT+zqGRavwnWWK+ryBLXKigKHOXoNb/bPmN3Cjqi daqyU2sj8XCNSBJmSENa4uQprHDLCVQnc2REww3ro6vlpQdbTDkyP6uVCPD8Z7WcdieY NDgWouUNDzDrFD/ttikN0UXfgXTBlkgmBoLuFyJIa8jdLElzEIl1YqoGqmk06g6aeir/ eGVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=u0TBkdx9w2eInWkgPDrIFWzwPwGPt+H5XL8zROnGIRg=; b=iLH94/cVftx9IVzEuH5eMrR6kz8FbR2LeOjRIP6l7s0pENbHliPUSjNWJ23g8TA6Vy EzAqw1yiL1OqzjWmi8FLTMTIxiQuw8NTxP7WtT67Do0bcVa/i3OCaiGzzy4W11xptqRZ yeBcGVx7ByIIMV5pMXfEgsiUZMNA1uFNAgLF6vInsgt1lUczfgo1+HV1yeqaI4S9v9lc 2+ouCZE8BokiITWc5rDWACmGLiJiyCKvDdCe3wmnJNJyMnbe8gwTvA2nCLh44Jdta2HV XtAa4zM+Yef3OpPbw4p8SVL7jiCgy2AZcqqhkGW26FuH9d3uafZgfAN3oOZ84EjSGykE Mjpg== X-Gm-Message-State: AEkoouuZylauyXGb31uy04GnqHpID1+/nPyhwDerePKpogMqfRRy3NTXtNzH+c7nlcTEjA== X-Received: by 10.28.199.131 with SMTP id x125mr18364810wmf.49.1470692442321; Mon, 08 Aug 2016 14:40:42 -0700 (PDT) Received: from RoniPC (bzq-79-176-39-238.red.bezeqint.net. [79.176.39.238]) by smtp.gmail.com with ESMTPSA id q186sm303980wma.1.2016.08.08.14.40.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 08 Aug 2016 14:40:41 -0700 (PDT) From: "Roni Even" To: References: In-Reply-To: Date: Tue, 9 Aug 2016 00:40:28 +0300 Message-ID: <011901d1f1bd$7b734580$7259d080$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_011A_01D1F1D6.A0C1DD10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdHnBhrfOOr7ktHaRfyfFTzHl5kaagKsQreA Content-Language: he Archived-At: Cc: draft-ietf-payload-melpe@ietf.org Subject: Re: [payload] WGLC on draft-ietf-payload-melpe-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 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, 08 Aug 2016 21:40:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_011A_01D1F1D6.A0C1DD10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I reviewed the document and have some comments 1. In the abstract you can delete the last sentence "Also, within the document there are included necessary details for the use of MELP with SDP." 2. I assume that sections 3.1.1, 3.1.2, 3.1.3, 3.2 are copied from STANAG 4591 in which case you can just provide a reference to the relevant sections 3. In section 3.3 it looks like a MELPE packet can be of zero coded frame and zero comfort noise frame? 4. For section 3.4 look at RFC7587 section 5 for text suggestions 5. In section 4.1 the type name is audio while the subtype names are MELP,. 6. In section 4.1 published specification "RFCXXXX" to be replaced by the RFC Editor 7. In section 4.2 we do not use MIME but "media type" (audio) and "media subtype " (MELPE,.) 8. The following text is not clear "A remote MELPe encoder SHALL receive "bitrate" parameter in the SDP "a=fmtp" attribute by copying them directly from the MIME media type string as a semicolon separated with parameter=value, where parameter is "bitrate", and value can be one or more of 2400, 1200, and 600 separated by commas (where each bit-rate value indicates the corresponding MELPe coder). Is this for the an offer? 9. We use "For declarative SDP" and not "For streaming media". It also better to have a sub section for SDP offer answer considerations and Declarative SDP considerations 10. In section 8 "its media decoder" use "the MELPe encoder" Roni Even From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Tuesday, July 26, 2016 9:24 AM To: 'payload@ietf.org' (payload@ietf.org) Cc: 'draft-ietf-payload-melpe@ietf.org' Subject: WGLC on draft-ietf-payload-melpe-02 Hi, I would like to start a WGLC on https://tools.ietf.org/html/draft-ietf-payload-melpe-02 , RTP Payload Format for MELPe Codec The WGLC will end on August 9th , 2016 Please review the draft and send comments to the list. For the draft authors; Are you aware of any IPR that applies to draft-ietf-payload-melpe-02? If so, has this IPR been disclosed in compliance with IETF IPR rules? The above question is needed for the document write-up when sent to publication. Thanks Roni Even Payload co-chair ------=_NextPart_000_011A_01D1F1D6.A0C1DD10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I reviewed the document = and have some comments

 

1.       = In the abstract you can delete the last sentence = “Also, within the document there are included necessary = details for the use of MELP with SDP.”

2.       = I assume that sections 3.1.1, 3.1.2, 3.1.3, 3.2 = are copied from STANAG 4591 in which case you can just provide a = reference to the relevant sections

3.       = In section 3.3 it looks like a MELPE packet can = be of zero coded frame and zero comfort noise = frame?

4.       = For section 3.4 look at RFC7587 section 5 for = text suggestions

5.       = In section 4.1 the type name is audio while the = subtype names are MELP,…

6.       = In section 4.1 published specification = “RFCXXXX” to be replaced by the RFC = Editor

7.       = In section 4.2 we do not use MIME but = “media type” (audio) and “media subtype “ = (MELPE,…)

8.       = The following text is not clear ”A = remote MELPe encoder SHALL receive "bitrate" parameter in the = SDP "a=3Dfmtp" attribute by copying them directly from the = MIME media type string as a semicolon separated with parameter=3Dvalue, = where parameter is "bitrate", and value can be one or more of = 2400, 1200, and 600 separated by commas (where each bit-rate value = indicates the corresponding MELPe coder). Is this for the an offer?

9.       = We use “For = declarative SDP” and not “For streaming media”. It = also better to have a sub section for SDP offer answer considerations = and Declarative SDP considerations

10.   In section 8 “its media = decoder” use “the MELPe encoder”

 

Roni = Even

 

From:= = Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: Tuesday, July = 26, 2016 9:24 AM
To: 'payload@ietf.org' = (payload@ietf.org)
Cc: = 'draft-ietf-payload-melpe@ietf.org'
Subject: WGLC on = draft-ietf-payload-melpe-02

 

Hi,

I would =
like to start a WGLC on  https://=
tools.ietf.org/html/draft-ietf-payload-melpe-02  , RTP Payload Format for MELPe =
Codec
 =

 =

 =

The WGLC will = end on August 9th , 2016

 

Please = review the draft and send comments to the list.

 

For the = draft authors;  Are you aware of any IPR that applies to = draft-ietf-payload-melpe-02?

If so, has = this IPR been disclosed in compliance with IETF IPR = rules?

The above =
question is needed for the document write-up when sent to =
publication.
 =

 =

Thanks

 

Roni = Even

Payload =  co-chair

 

------=_NextPart_000_011A_01D1F1D6.A0C1DD10-- From nobody Mon Aug 8 19:14:06 2016 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 9D7FB12D592; Mon, 8 Aug 2016 19:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, 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 c1fqHUw0n9nM; Mon, 8 Aug 2016 19:14:04 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.199]) (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 4E4A012D688; Mon, 8 Aug 2016 19:14:04 -0700 (PDT) Received: from [216.82.241.83] by server-7.bemta-8.messagelabs.com id 11/A1-02887-B6C39A75; Tue, 09 Aug 2016 02:14:03 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRWlGSWpSXmKPExsUi0uJqq5ttszL cYMF9LosP2/YzWVy6eJbJgcljyZKfTAGMUayZeUn5FQmsGR/7DzIW3FOpuL7/NnsDY7NSFyMX h5DANUaJw887WCGcOYwSH+/tYuti5ORgEzCT2Nr+nxHEFhEolph7cjZYXFhARWLVwqfMXYwcQ HFNiefvDCFK9CSmfF/ECmKzAJXs693HBGLzCrhKdE88AGYzCohJfD+1BsxmFhCXuPVkPpgtIS AgsWTPeWYIW1Ti5eN/rCDjJQSUJJoW5UGU50pcutnBAjFSUOLkzCcsExgFZiGZNAtJ2SwkZRB xHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0Vo0ZxalFZapGuoaFeUlFmekZJbmJmjq6hgYVe bmpxcWJ6ak5iUrFecn7uJkZgHDAAwQ7GGbOcDzFKcjApifK2W64MF+JLyk+pzEgszogvKs1JL T7EKMPBoSTBq2wNlBMsSk1PrUjLzAFGJExagoNHSYRXHSTNW1yQmFucmQ6ROsWoKCXOaw+SEA BJZJTmwbXBksAlRlkpYV5GoEOEeApSi3IzS1DlXzGKczAqCfN6gUzhycwrgZv+CmgxE9DiJNU VIItLEhFSUg2M27lPJL+JiT979YP3i27xAvGG8/FCIt+nzz1QYMl8QvHcrymzio5NfZlz3E7u q2/X5m1zz/Y+cy79Y64c22W/94aux91z/XMtT17SeLuj+MHktbOPfg4pVAnXWxE6acsTh/k6l +IiFln49peXcjbFBQWrXfz88ntdhlesq8l3znny1dnFdxI+K7EUZyQaajEXFScCAEskuyT9Ag AA X-Env-Sender: standifm@textronsystems.com X-Msg-Ref: server-5.tower-37.messagelabs.com!1470708842!52622864!1 X-Originating-IP: [20.132.69.61] X-StarScan-Received: X-StarScan-Version: 8.77; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16046 invoked from network); 9 Aug 2016 02:14:03 -0000 Received: from unknown (HELO TXAINFNWH047.textron.com) (20.132.69.61) by server-5.tower-37.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 9 Aug 2016 02:14:03 -0000 Received: from TXAMASNWH027.ent.textron.com (txamasnwh027.ent.textron.com [10.244.221.27]) by TXAINFNWH047.textron.com with smtp id 5382_1792_de9875da_2179_43be_98f4_8bb0ceef1471; Tue, 09 Aug 2016 02:13:04 +0000 Received: from TXAMASNWH026.ent.textron.com ([10.244.221.26]) by txamasnwh027 ([10.244.221.27]) with mapi id 14.03.0210.002; Mon, 8 Aug 2016 22:14:02 -0400 From: "Standiford, Matt" To: "draft-ietf-payload-melpe@ietf.org" , "payload@ietf.org" Thread-Topic: draft-ietf-payload-melpe-02 Thread-Index: AdHx44t7v20G6+WBR9qsCd97B6en7A== Date: Tue, 9 Aug 2016 02:14:01 +0000 Message-ID: <77B9327894EB1C43B471F8D884CCC532010607AF81@txamasnwh026> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.244.221.231] Content-Type: multipart/alternative; boundary="_000_77B9327894EB1C43B471F8D884CCC532010607AF81txamasnwh026_" MIME-Version: 1.0 Archived-At: Subject: [payload] draft-ietf-payload-melpe-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 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, 09 Aug 2016 02:14:05 -0000 --_000_77B9327894EB1C43B471F8D884CCC532010607AF81txamasnwh026_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IETF I've reviewed the subject draft, and the document looks good to me in its c= urrent form. Thanks, -Matt Matt Standiford Systems Engineer AAI Corporation Textron Systems Unmanned Systems 124 Industry Lane Hunt Valley MD, 21030 standifm@textronsystems.com Desk: 410-628-3451 Cell: 443-547-5753 www.textronsystems.com --_000_77B9327894EB1C43B471F8D884CCC532010607AF81txamasnwh026_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IETF

 

I’ve reviewed the subject draft, and the docum= ent looks good to me in its current form.

 

Thanks,

 

-Matt

 

 

Matt Standiford

Systems Engineer

AAI Corporation

 

Textron Systems

Unmanned Systems

124 Industry Lane

Hunt Valley MD, 21030

standifm@textronsystems.com
Desk: 410-628-3451

Cell: 443-547-5753

www.tex= tronsystems.com

 

--_000_77B9327894EB1C43B471F8D884CCC532010607AF81txamasnwh026_-- From nobody Tue Aug 9 07:18:02 2016 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 5950312D821 for ; Tue, 9 Aug 2016 07:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 OTW9KGejhoK2 for ; Tue, 9 Aug 2016 07:18:00 -0700 (PDT) Received: from cuda.olm1.com (cuda.olm1.com [72.236.255.32]) (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 4853012D5D1 for ; Tue, 9 Aug 2016 07:17:59 -0700 (PDT) X-ASG-Debug-ID: 1470752265-092fd37a5491a010001-U2jSCT Received: from host105.olm1.com (host105.olm1.com [72.236.255.15]) by cuda.olm1.com with ESMTP id DsxbagFSx2a8GCg5 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 09 Aug 2016 10:17:45 -0400 (EDT) X-Barracuda-Envelope-From: Dave.Satterlee@vocal.com X-Barracuda-Apparent-Source-IP: 72.236.255.15 Received: from [192.168.11.22] (rrcs-72-43-202-98.nys.biz.rr.com [72.43.202.98]) by host105.olm1.com (Postfix) with ESMTPSA id 9893BB4338E for ; Tue, 9 Aug 2016 10:17:43 -0400 (EDT) References: X-ASG-Orig-Subj: Fwd: Latest MELP RTP Payload draft (UNCLASSIFIED) To: "payload@ietf.org" From: "Dave Satterlee (Vocal)" Organization: Vocal Technologies X-Forwarded-Message-Id: Message-ID: Date: Tue, 9 Aug 2016 10:17:55 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0D4E58680AF900A81D4160DE" X-Barracuda-Connect: host105.olm1.com[72.236.255.15] X-Barracuda-Start-Time: 1470752265 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://72.236.255.32:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at olm1.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.31869 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: [payload] Fwd: Latest MELP RTP Payload draft (UNCLASSIFIED) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 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, 09 Aug 2016 14:18:01 -0000 This is a multi-part message in MIME format. --------------0D4E58680AF900A81D4160DE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit -------- Forwarded Message -------- Subject: Latest MELP RTP Payload draft (UNCLASSIFIED) Date: Mon, 8 Aug 2016 21:23:57 +0000 From: Lee, John To: payload@ietf.org , draft-ietf-payload-melpe@ietf.org CC: victord@vocal.com , daves@vocal.com Dave and Victor, I concur with the latest draft. Thanks, John Lee JSIL Cert Center (O) 256-955-8969 (BB) 256-698-8985 / ------------------------------------------------------------------------------------------ The information contained in this message, and any attachments, may contain privileged and/or proprietary information that is intended solely for the person or entity to which it is addressed. Moreover, it may contain export restricted technical data controlled by Export Administration Regulations (EAR) or the International Traffic in Arms Regulations (ITAR). Any review, retransmission, dissemination, or re-export to foreign or domestic entities by anyone other than the intended recipient in accordance with EAR and/or ITAR regulations is prohibited. / --------------0D4E58680AF900A81D4160DE Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit




-------- Forwarded Message --------
Subject: Latest MELP RTP Payload draft (UNCLASSIFIED)
Date: Mon, 8 Aug 2016 21:23:57 +0000
From: Lee, John <John.Lee@dynetics.com>
To: payload@ietf.org <payload@ietf.org>, draft-ietf-payload-melpe@ietf.org <draft-ietf-payload-melpe@ietf.org>
CC: victord@vocal.com <victord@vocal.com>, daves@vocal.com <daves@vocal.com>


Dave and Victor,
I concur with the latest draft.
Thanks,

John Lee

JSIL Cert Center

(O) 256-955-8969

(BB) 256-698-8985


The information contained in this message, and any attachments, may contain privileged and/or proprietary information that is intended solely for the person or entity to which it is addressed. Moreover, it may contain export restricted technical data controlled by Export Administration Regulations (EAR) or the International Traffic in Arms Regulations (ITAR). Any review, retransmission, dissemination, or re-export to foreign or domestic entities by anyone other than the intended recipient in accordance with EAR and/or ITAR regulations is prohibited.
--------------0D4E58680AF900A81D4160DE-- From nobody Tue Aug 9 07:23:30 2016 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 3EED212D882 for ; Tue, 9 Aug 2016 07:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 senNKIN-YEwl for ; Tue, 9 Aug 2016 07:23:26 -0700 (PDT) Received: from cuda.olm1.com (cuda.olm1.com [72.236.255.32]) (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 9208A12D8A7 for ; Tue, 9 Aug 2016 07:23:26 -0700 (PDT) X-ASG-Debug-ID: 1470752605-092fd37a5491b230001-U2jSCT Received: from host105.olm1.com (host105.olm1.com [72.236.255.15]) by cuda.olm1.com with ESMTP id jjb80HTC9ij5drHC (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 09 Aug 2016 10:23:25 -0400 (EDT) X-Barracuda-Envelope-From: Dave.Satterlee@vocal.com X-Barracuda-Apparent-Source-IP: 72.236.255.15 Received: from [192.168.11.22] (rrcs-72-43-202-98.nys.biz.rr.com [72.43.202.98]) by host105.olm1.com (Postfix) with ESMTPSA id 11354B43449 for ; Tue, 9 Aug 2016 10:23:25 -0400 (EDT) References: <6809FCABEB2B464BAF620D2F5945B153D4FFB69C@FCSVR3.flightcell.local> X-ASG-Orig-Subj: Fwd: WGLC on draft-ietf-payload-melpe-02 To: "payload@ietf.org" From: "Dave Satterlee (Vocal)" Organization: Vocal Technologies X-Forwarded-Message-Id: <6809FCABEB2B464BAF620D2F5945B153D4FFB69C@FCSVR3.flightcell.local> Message-ID: <4ea83ff8-a278-367c-fb74-a05e3c494620@vocal.com> Date: Tue, 9 Aug 2016 10:23:36 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <6809FCABEB2B464BAF620D2F5945B153D4FFB69C@FCSVR3.flightcell.local> Content-Type: multipart/alternative; boundary="------------8DA75F333EBE6081951569C1" X-Barracuda-Connect: host105.olm1.com[72.236.255.15] X-Barracuda-Start-Time: 1470752605 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://72.236.255.32:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at olm1.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.31869 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: [payload] Fwd: WGLC on draft-ietf-payload-melpe-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 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, 09 Aug 2016 14:23:29 -0000 This is a multi-part message in MIME format. --------------8DA75F333EBE6081951569C1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit -------- Forwarded Message -------- Subject: WGLC on draft-ietf-payload-melpe-02 Date: Fri, 5 Aug 2016 02:32:59 +0000 From: James Mace To: draft-ietf-payload-melpe@ietf.org , payload@ietf.org CC: Dave Satterlee (Vocal) We at Flightcell approve this draft (draft-ietf-payload-melpe-02) and find it necessary to create interoperability in our industry. We recommend the WG adopt this draft as an RFC. Yours sincerely James Mace Director */Flightcell International Limited/* 98 Vickerman St P O Box 1481 Nelson 7010 *New Zealand* _www.flightcell.com_ Ph +64 3 545 8651 Mob +64 22 548 7043 --------------8DA75F333EBE6081951569C1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit




-------- Forwarded Message --------
Subject: WGLC on draft-ietf-payload-melpe-02
Date: Fri, 5 Aug 2016 02:32:59 +0000
From: James Mace <James@flightcell.com>
To: draft-ietf-payload-melpe@ietf.org <draft-ietf-payload-melpe@ietf.org>, payload@ietf.org <payload@ietf.org>
CC: Dave Satterlee (Vocal) <Dave.Satterlee@vocal.com>


We at Flightcell approve this draft (draft-ietf-payload-melpe-02) and find it necessary to create interoperability in our industry. We recommend the WG adopt this draft as an RFC.
Yours sincerely
James Mace
Director
Flightcell International Limited
98 Vickerman St
P O Box 1481
Nelson 7010
New Zealand
Ph +64 3 545 8651
Mob +64 22 548 7043
--------------8DA75F333EBE6081951569C1-- From nobody Mon Aug 15 15:54:37 2016 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 19F6912D799; Mon, 15 Aug 2016 15:54:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147130167610.31591.2593891071477423396.idtracker@ietfa.amsl.com> Date: Mon, 15 Aug 2016 15:54:36 -0700 Archived-At: Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-ancillary-05.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 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, 15 Aug 2016 22:54:36 -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 of the IETF. Title : RTP Payload for SMPTE ST 291 Ancillary Data Author : Thomas G. Edwards Filename : draft-ietf-payload-rtp-ancillary-05.txt Pages : 14 Date : 2016-08-15 Abstract: This memo describes an RTP Payload format for SMPTE Ancillary data, as defined by SMPTE ST 291-1. SMPTE Ancillary data is generally used along with professional video formats to carry a range of ancillary data types, including time code, Closed Captioning, and the Active Format Description (AFD). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-ancillary/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-payload-rtp-ancillary-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-ancillary-05 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 Tue Aug 16 01:50:09 2016 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 64D9212D589 for ; Tue, 16 Aug 2016 01:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.846 X-Spam-Level: X-Spam-Status: No, score=-3.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=webrtc-org.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 H-cFmMVSFymn for ; Tue, 16 Aug 2016 01:50:05 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 E476F12B01F for ; Tue, 16 Aug 2016 01:50:04 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id i5so151992944wmg.0 for ; Tue, 16 Aug 2016 01:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=webrtc-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kDqPCSHRqz13xpR5PS4gTZTSCmqtEyBdsbajmNgXkVs=; b=1GJGjOcpUKZ8m+RuYa2wXYG6G7FL//ezJtWwFUTQPlNiSTCBlhlfhIbjQy5fEjMoP+ gah2tCBzVWj6Hs5JInyhBj66t49qfLPf57E1yjoLYyFwHRWtDKpN6VxHnZIkzoQg9L7u sHfQJFay26gc42L6EarGdAMQSq3ukXWjGnCFB/FhgIeEeb3GnIf3IuapU5Jb/L1DvISJ +BFwxBLxVcxQPBW7JGrrSH21HdZY+CKBocOhP+iX3q/JSQP6kHP2SLyM97xGCP7qS7Ga IeFu/BDeCeAXZywB7fHPPu40jKhMHzjfOHCQ8yJqsZB2bqWLm9BoLPLGCRjC4bCvuCqG Cm2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kDqPCSHRqz13xpR5PS4gTZTSCmqtEyBdsbajmNgXkVs=; b=YP4I9ooMFTF2uwXBcgCgIstrVoRKyHqoJPDKrI0Sv9LhFgn1w0VrZvFA/7NJSFrN8C PfXQc0zsoQQNEW+MMTAzgis3xPeZ8SuEGqs7dAieDpiz9vywfd972k48fkFeHdvVa/QM eQQzwDP2vvT6Nbhoxg3LzVQSn+ErGtm4CUqeUD/n2zcs72yQ1wLu0HYZ6XH52x728Zi/ AL6FvLpWb57p9puXC0MKDrjhG0WjJhX0xyRwgD4l/89jU3v2oOEnKtDB501VxqeaegSg kbrRGBcrOLHvw2B6Xdo4+hjPC4yePeQXZ/kUP+I4e54ELFzfh7GP/9SiSvdB3X6All6y CzQQ== X-Gm-Message-State: AEkooutgJ5BzWz3CkZPXDQAdzNu+hOjRDK5g6hl8FK7tFAKlyAZjsdHQIpgFtOvg6jb0gp7W+9irX7hOZJw+ih7W X-Received: by 10.28.185.202 with SMTP id j193mr20512913wmf.78.1471337403147; Tue, 16 Aug 2016 01:50:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Stefan Holmer Date: Tue, 16 Aug 2016 08:49:52 +0000 Message-ID: To: Varun Singh , "payload@ietf.org" Content-Type: multipart/alternative; boundary=001a1148ef2642ce3c053a2c6fec Archived-At: Cc: Varun Singh Subject: Re: [payload] FLEXFEC: retransmissions optimization X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 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, 16 Aug 2016 08:50:07 -0000 --001a1148ef2642ce3c053a2c6fec Content-Type: text/plain; charset=UTF-8 Sounds like good optimizations to me. Below are some, possibly naive, suggestions: Have we considered also reusing the timestamp field in the RTP header to save another 4 bytes by not having the timestamp field in the flex fec header when doing retransmits? Since the RTP timestamp should represent the sampling instant of the first octet in the RTP data packet, it seems reasonable that it is the original timestamp and not something newly generated for the retransmit. The same thing might be possible to do with PT recovery. /Stefan On Thu, Jul 21, 2016 at 3:26 PM Varun Singh wrote: > Hi all, > > Following up on the discussion based in the Payload session at Berlin. > > The current draft has the following format > > 0 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |F|R| P|X| CC |M| PT recovery | length recovery | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TS recovery | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | SSRCCount | reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | SSRC_i | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | SN base_i |k| Mask [0-14] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |k| Mask [15-45] (optional) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |k| | > +-+ Mask [46-108] (optional) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... next in SSRC_i ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > For retransmission, decomposes to (also in the draft): > > 0 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|1| P|X| CC |M| PT recovery | length recovery | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TS recovery | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | SSRCCount=1 | reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | SSRC_i | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | SN base_i |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The was called out to be suboptimal in Yokohama, and we are now suggesting > the following: > > > 0 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |R|F| P|X| CC |M| PT recovery | sequence number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | timestamp | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | SSRC | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Retx | > > : RTP payload : > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Just want to call out a few things here, comparing FEC payload packets > > and Retx packets: > > > 1. R and F bits swapped places, which makes the retransmission bit first, > > thus copying the retransmission packet as is, would work because the > > RTP V bit would align with R=1,F=0 and nothing special needs to be > > handled in this case. > > > 2. sequence number (SN base_i) replaces length recovery > > > 3. SSRCCount and the reserved field is removed, as retx contains just > > a single packet from an SSRC. > > > > Regards, > > Varun and Mo. > > > -- > http://www.callstats.io > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > --001a1148ef2642ce3c053a2c6fec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sounds like good optimizations to me. Below are some, poss= ibly naive, suggestions:

Have we considered also reusing= the timestamp field in the RTP header to save another 4 bytes by not havin= g the timestamp field in the flex fec header when doing retransmits? Since = the RTP timestamp should represent the sampling instant of the first octet = in the RTP data packet, it seems reasonable that it is the original timesta= mp and not something newly generated for the retransmit.

The same thing might be possible to do with PT recovery.
<= br>
/Stefan

On Thu, Jul 21, 2016 at 3:26 PM Varun Singh <vsingh.ietf@gmail.com> wrote:
Hi all,

= Following up on the discussion based in the Payload session at Berlin.

The current draft has the following format
<= br>
        0                   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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |F|R| P|X|  CC   |M| PT recovery |         length recovery      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          TS recovery                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   SSRCCount   |                    reserved                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             SSRC_i                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           SN base_i           |k|          Mask [0-14]        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |k|                   Mask [15-45] (optional)                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |k|                                                             |
       +-+                   Mask [46-108] (optional)                  |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     ... next in SSRC_i ...                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


For retransmission, decompos= es to (also in the draft):=C2=A0

       =
 0                   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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |1|1| P|X|  CC   |M| PT recovery |         length recovery      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          TS recovery                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   SSRCCount=3D1 |                    reserved                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             SSRC_i                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           SN base_i           |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The was called out to be suboptimal in Yokoham= a, and we are now suggesting the following:

        0                   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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |R|F| P|X|  CC   |M| PT recovery |         sequence number      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            timestamp                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               SSRC                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       =
|                              Retx                             |
                :    =
                                                        RTP payload        =
                                                :
       +-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<=
br>

Just want=
 to call out a few things here, comparing FEC payload packets 
and Retx packe=
ts:

1. R and F bits swapped places, which makes the retransmission bit fir=
st, 
thus copying the retransmission packet as is, would work because the 
RTP =
V bit would align with R=3D1,F=3D0 and nothing special needs to be 
handled i=
n this case.

2. sequence number (SN base_i) replaces length recovery
=


3. S=
SRCCount and the reserved field is removed, as retx contains just 
a single p=
acket from an SSRC.


Regards,
Varun and Mo.
--
http://www.callstats.io
_______________________________________________
payload mailing list
payload@ietf.org
https://w= ww.ietf.org/mailman/listinfo/payload
--001a1148ef2642ce3c053a2c6fec-- From nobody Tue Aug 16 04:01:18 2016 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 4AED312D773 for ; Tue, 16 Aug 2016 04:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=callstats.io 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 bsgUQ55fEPnG for ; Tue, 16 Aug 2016 04:01:14 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 9A03512D768 for ; Tue, 16 Aug 2016 04:01:13 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id i5so159163192wmg.0 for ; Tue, 16 Aug 2016 04:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callstats.io; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Np1ODNeVhqV7S04F6oEuB9OILECV+iDfqz/naa/owlU=; b=DTJD5tNABF7HMQ5T8P/NITppjsUwaffOsWfIMloLnABKeic8qviX61PfYdSf/LNMbP njGAmlzGi7V30YbeQiv+H7Kh5K4bGCL3wo4FGcFF1ZpfQCICDk+KCTi3NbAAE7YuT13J Drz2tqIsLbnhbW45bIoMGqC2vwoBQL9nrG+us= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Np1ODNeVhqV7S04F6oEuB9OILECV+iDfqz/naa/owlU=; b=QcUNZ9Syul8HUDFdBGTZin/q000dCJdINym9QwYmyfg8Y/LbwNp4Zr1MVvB/NTNz85 ITYuZ3Dsy8hb+X1S4xqGFfZhTOL0XNUx9ZoyHSuR9Squ2gLQs5sOqjKopIhFU5Y1J8vQ v752BPA/LonuB0xEZK3Ygr58kgKepa/BSX8Wt+HwhrRLpNPyLrqdx2NJDXxzYy9QdA8a zZT2/Td8QUadfO0dOVpzftLLcxzb2FAZR3cZ0IkkdCywodGgakIay+LnXtGCwhiGsQII 3/1SCOKqXdEr3vSlQL+5ChhqYfnKRVoJBec0iFTzI6pxpGtvvWyV4iiG6afmW8OUyvzP KD8g== X-Gm-Message-State: AEkoouutrqMN6vYNFXXDpjqDsvuIPVY1ygVM8ibzv5oco9qqXWjzmkVDfL5TXyZ8KPYJOKUcfgGey1D75uFvBA== X-Received: by 10.28.94.18 with SMTP id s18mr20376991wmb.44.1471345271633; Tue, 16 Aug 2016 04:01:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.128.135 with HTTP; Tue, 16 Aug 2016 04:00:51 -0700 (PDT) In-Reply-To: References: From: Varun Singh Date: Tue, 16 Aug 2016 14:00:51 +0300 Message-ID: To: Stefan Holmer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "payload@ietf.org" Subject: Re: [payload] FLEXFEC: retransmissions optimization X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 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, 16 Aug 2016 11:01:16 -0000 Hi Stefan, The RTP header will follow the timing and payload rules for the RTP stream. Further, an endpoint could intersperse retx and FEC packets, which would make keeping track of sequence numbers difficult. Regards, Varun On Tue, Aug 16, 2016 at 11:49 AM, Stefan Holmer wrote: > Sounds like good optimizations to me. Below are some, possibly naive, > suggestions: > > Have we considered also reusing the timestamp field in the RTP header to > save another 4 bytes by not having the timestamp field in the flex fec > header when doing retransmits? Since the RTP timestamp should represent the > sampling instant of the first octet in the RTP data packet, it seems > reasonable that it is the original timestamp and not something newly > generated for the retransmit. > > The same thing might be possible to do with PT recovery. > > /Stefan > > On Thu, Jul 21, 2016 at 3:26 PM Varun Singh wrote: >> >> Hi all, >> >> Following up on the discussion based in the Payload session at Berlin. >> >> The current draft has the following format >> >> 0 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |F|R| P|X| CC |M| PT recovery | length recovery | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | TS recovery | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | SSRCCount | reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | SSRC_i | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | SN base_i |k| Mask [0-14] | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |k| Mask [15-45] (optional) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |k| | >> +-+ Mask [46-108] (optional) | >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... next in SSRC_i ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> For retransmission, decomposes to (also in the draft): >> >> 0 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |1|1| P|X| CC |M| PT recovery | length recovery | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | TS recovery | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | SSRCCount=1 | reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | SSRC_i | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | SN base_i |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> The was called out to be suboptimal in Yokohama, and we are now suggesting >> the following: >> >> >> 0 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |R|F| P|X| CC |M| PT recovery | sequence number | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | timestamp | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | SSRC | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | Retx | >> >> : >> RTP payload : >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> Just want to call out a few things here, comparing FEC payload packets >> >> and Retx packets: >> >> >> 1. R and F bits swapped places, which makes the retransmission bit first, >> >> thus copying the retransmission packet as is, would work because the >> >> RTP V bit would align with R=1,F=0 and nothing special needs to be >> >> handled in this case. >> >> >> 2. sequence number (SN base_i) replaces length recovery >> >> >> 3. SSRCCount and the reserved field is removed, as retx contains just >> >> a single packet from an SSRC. >> >> >> >> Regards, >> >> Varun and Mo. >> >> >> >> >> -- >> http://www.callstats.io >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload -- Founder, CEO, callstats.io http://www.callstats.io Analytics and Optimizations for WebRTC. We are hiring: www.callstats.io/jobs/ From nobody Tue Aug 16 04:09:49 2016 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 F0E2D12D77A for ; Tue, 16 Aug 2016 04:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.846 X-Spam-Level: X-Spam-Status: No, score=-3.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=webrtc-org.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 qlQE7gHCfWSD for ; Tue, 16 Aug 2016 04:09:45 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 3CA6012D777 for ; Tue, 16 Aug 2016 04:09:45 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id o80so159713000wme.1 for ; Tue, 16 Aug 2016 04:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=webrtc-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l35EXVySL+ELg2YB0Y932CRjJacHwXkvZoS+6R0bqzo=; b=L+mYPN/kCzs8QN+4zUDILY7Q0rwitEyKHmE076c7ePMgknyE2aRH9dsltkc/78JJSx 4/w6CvDpm+LS98KcGrdYYJI6m+6GkbJlVb0t8+pPiTx66dnI5ByJPDJbCZlYnZQbQUH9 pEggF8z23DNVAdXhq7y4gpt+bQp2xghQvXTOwXZHHhlReyS08YD+YJBrI2fpNRZBdAAG hW3VVqOSfrWvhLANTYQP+8tuMbuDFfBqTmLRkRoKfUiy3XjK00uACmMPIJlS3hIHRIPa Kez1e7nkc1HcW860bIKkLW535MgdXIJMNQP0baYm4Uej2PpcUKqSzg9Y6dwi6zNZKYUl LU/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l35EXVySL+ELg2YB0Y932CRjJacHwXkvZoS+6R0bqzo=; b=dgMrgy/KSdF2o9UTLCwKhM05SsxNu+AEIiO9wRrylbAYkYR1lURmgJj0GhOoXX/3Q0 3Lvsp1+vxZfwLdOXW8qz98WXChZ4OOoHsYYe1gfAJLZ0ZFq8LZc6VTj4IgL/Kr3lP+sl sv2TUqlnwqIQ/6rk78/6MayRhl5QOQCRTghTkvs0SssiTUQ/5ZYZOT6iiR9Drm/kKE5y vl4XofkwoWiyLb7yqu8RLa38pwaoQh5zocuYrlkRVhAsnyM4k0QlAHCiG7yMJc98hEO+ 2OHiI4IDugBdDNXp/jBA08rxhHfc4cFntU1G/Tj+CsNIiWakah8FlmzRIZAvJv25Wq0C 4l2w== X-Gm-Message-State: AEkoousLUhOrEWm7xG9Dqqlfy3rkxfbIoIE2YDwB4A40pYl95B1MplvFVZzX8+AlYPEmMpHipUbYePvyrFv8rWV6 X-Received: by 10.28.185.202 with SMTP id j193mr21237793wmf.78.1471345783378; Tue, 16 Aug 2016 04:09:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Stefan Holmer Date: Tue, 16 Aug 2016 11:09:32 +0000 Message-ID: To: Varun Singh Content-Type: multipart/alternative; boundary=001a1148ef26c31ed1053a2e62d0 Archived-At: Cc: "payload@ietf.org" Subject: Re: [payload] FLEXFEC: retransmissions optimization X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 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, 16 Aug 2016 11:09:48 -0000 --001a1148ef26c31ed1053a2e62d0 Content-Type: text/plain; charset=UTF-8 I agree that we should have the sequence numbers in the flex fec header, but timestamps I don't see why we need there. RFC 4588 does the same optimization without running into problems, right? I can see that it could be an issue if you retransmit packets from two different rtp streams, where one is video and one is audio with a different rtp timestamp rate. Is that the reason for this not being possible, or could those be differentiated via payload types? /Stefan On Tue, Aug 16, 2016 at 1:01 PM Varun Singh wrote: > Hi Stefan, > > The RTP header will follow the timing and payload rules for the RTP > stream. Further, an endpoint could intersperse retx and FEC packets, > which would make keeping track of sequence numbers difficult. > > Regards, > Varun > > On Tue, Aug 16, 2016 at 11:49 AM, Stefan Holmer wrote: > > Sounds like good optimizations to me. Below are some, possibly naive, > > suggestions: > > > > Have we considered also reusing the timestamp field in the RTP header to > > save another 4 bytes by not having the timestamp field in the flex fec > > header when doing retransmits? Since the RTP timestamp should represent > the > > sampling instant of the first octet in the RTP data packet, it seems > > reasonable that it is the original timestamp and not something newly > > generated for the retransmit. > > > > The same thing might be possible to do with PT recovery. > > > > /Stefan > > > > On Thu, Jul 21, 2016 at 3:26 PM Varun Singh > wrote: > >> > >> Hi all, > >> > >> Following up on the discussion based in the Payload session at Berlin. > >> > >> The current draft has the following format > >> > >> 0 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 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> |F|R| P|X| CC |M| PT recovery | length recovery | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | TS recovery | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | SSRCCount | reserved | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | SSRC_i | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | SN base_i |k| Mask [0-14] | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> |k| Mask [15-45] (optional) | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> |k| | > >> +-+ Mask [46-108] (optional) | > >> | | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | ... next in SSRC_i ... | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> > >> > >> For retransmission, decomposes to (also in the draft): > >> > >> 0 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 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> |1|1| P|X| CC |M| PT recovery | length recovery | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | TS recovery | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | SSRCCount=1 | reserved | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | SSRC_i | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | SN base_i |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> > >> The was called out to be suboptimal in Yokohama, and we are now > suggesting > >> the following: > >> > >> > >> 0 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 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> |R|F| P|X| CC |M| PT recovery | sequence number | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | timestamp | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | SSRC | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> | Retx | > >> > >> : > >> RTP payload : > >> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> > >> > >> Just want to call out a few things here, comparing FEC payload packets > >> > >> and Retx packets: > >> > >> > >> 1. R and F bits swapped places, which makes the retransmission bit > first, > >> > >> thus copying the retransmission packet as is, would work because the > >> > >> RTP V bit would align with R=1,F=0 and nothing special needs to be > >> > >> handled in this case. > >> > >> > >> 2. sequence number (SN base_i) replaces length recovery > >> > >> > >> 3. SSRCCount and the reserved field is removed, as retx contains just > >> > >> a single packet from an SSRC. > >> > >> > >> > >> Regards, > >> > >> Varun and Mo. > >> > >> > >> > >> > >> -- > >> http://www.callstats.io > >> _______________________________________________ > >> payload mailing list > >> payload@ietf.org > >> https://www.ietf.org/mailman/listinfo/payload > > > > -- > Founder, CEO, callstats.io > http://www.callstats.io > Analytics and Optimizations for WebRTC. > > We are hiring: www.callstats.io/jobs/ > --001a1148ef26c31ed1053a2e62d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree that we should have the sequence numbers in the fl= ex fec header, but timestamps I don't see why we need there. RFC 4588 d= oes the same optimization without running into problems, right?

I can see that it could be an issue if you retransmit packets from = two different rtp streams, where one is video and one is audio with a diffe= rent rtp timestamp rate. Is that the reason for this not being possible, or= could those be differentiated via payload types?

= /Stefan

On Tue, = Aug 16, 2016 at 1:01 PM Varun Singh <varun@callstats.io> wrote:
stefan@webrtc.org> wrote:
> Sounds like good optimizations to me. Below are some, possibly naive,<= br> > suggestions:
>
> Have we considered also reusing the timestamp field in the RTP header = to
> save another 4 bytes by not having the timestamp field in the flex fec=
> header when doing retransmits? Since the RTP timestamp should represen= t the
> sampling instant of the first octet in the RTP data packet, it seems > reasonable that it is the original timestamp and not something newly > generated for the retransmit.
>
> The same thing might be possible to do with PT recovery.
>
> /Stefan
>
> On Thu, Jul 21, 2016 at 3:26 PM Varun Singh <vsingh.ietf@gmail.com> wrote: >>
>> Hi all,
>>
>> Following up on the discussion based in the Payload session at Ber= lin.
>>
>> The current draft has the following format
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00 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
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |F|R| P|X|=C2=A0 CC=C2=A0 =C2=A0|M| PT = recovery |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0length recovery=C2=A0 =C2=A0 = =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TS recovery=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0SSRCCount=C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 reser= ved=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC_i=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0SN base_i=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|k|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Mask [0-14]=C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |k|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mask [15-45] (optional)=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |k|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mask [46-108] (optional)=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0... next in SSRC_i ...=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>
>>
>> For retransmission, decomposes to (also in the draft):
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00 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
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |1|1| P|X|=C2=A0 CC=C2=A0 =C2=A0|M| PT = recovery |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0length recovery=C2=A0 =C2=A0 = =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TS recovery=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0SSRCCount=3D1 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 reserved=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC_i=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0SN base_i=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|0 0 0 0 0 0 0 0 0 0 0= 0 0 0 0 0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>
>> The was called out to be suboptimal in Yokohama, and we are now su= ggesting
>> the following:
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00 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
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |R|F| P|X|=C2=A0 CC=C2=A0 =C2=A0|M| PT = recovery |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sequence number=C2=A0 =C2=A0 = =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 timestamp=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SS= RC=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Retx=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:
>> RTP payload=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>
>>
>> Just want to call out a few things here, comparing FEC payload pac= kets
>>
>> and Retx packets:
>>
>>
>> 1. R and F bits swapped places, which makes the retransmission bit= first,
>>
>> thus copying the retransmission packet as is, would work because t= he
>>
>> RTP V bit would align with R=3D1,F=3D0 and nothing special needs t= o be
>>
>> handled in this case.
>>
>>
>> 2. sequence number (SN base_i) replaces length recovery
>>
>>
>> 3. SSRCCount and the reserved field is removed, as retx contains j= ust
>>
>> a single packet from an SSRC.
>>
>>
>>
>> Regards,
>>
>> Varun and Mo.
>>
>>
>>
>>
>> --
>> http://www.callstats.io
>> _______________________________________________
>> payload mailing list
>> payload@ietf= .org
>> https://www.ietf.org/mailman/listinfo/payload<= /a>



--
Founder, CEO, callstats.io
ht= tp://www.callstats.io
Analytics and Optimizations for WebRTC.

We are hiring: www.callstats.io/jobs/
--001a1148ef26c31ed1053a2e62d0-- From nobody Thu Aug 18 10:45:40 2016 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 A8B0712DA4D for ; Thu, 18 Aug 2016 10:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=callstats.io 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 zcJoffZoxld1 for ; Thu, 18 Aug 2016 10:42:56 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 B03C712D77F for ; Thu, 18 Aug 2016 10:42:43 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id q128so5725210wma.1 for ; Thu, 18 Aug 2016 10:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callstats.io; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=slvGYASF0O/cqps9zaXnjx91UASbTWbSej4Gv4mYwKA=; b=kZJLR33RCtId+9vx4Q7ln3lnfeuzgeC8HT40raKYMz0R4mIXsKs8V8xjtWJDcTpErB IV6IJ8moG6hqjfzwLMXQ4pk2nGe9kZlYq1+4QoQfsuhDdrNJke3Aa+penw6M1EUCCCiC ki0ZzjraJQDKLSFuN1PqFhsQ4v+WxQuSvIM+Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=slvGYASF0O/cqps9zaXnjx91UASbTWbSej4Gv4mYwKA=; b=YQfcbCR5pslTTupEvE39Ap9POoipMM66nGwsU4lQY8k8IVAqK82gsO4vTdhtZ6/76H kYOouA5rW2Jt+bZjKPKRiacpvUfUdZAVN2bCZ+BHQKqMkZQ11wCarIU1My2GjJihz+Gv Iv4DF14/qK/cuzOJLHwBfT8ZmbsbcMJ3uWzJ3v3bs21q+C+N8UrzU8BATAa3d0MrhGqs o36dZNEplpFMgmDmymdrZ2LBLHKKAI1iTmnAHpot7+G9CPv8wKGcgb+bx9MEeOMkLWTb ZxZWfXgSunj3IoRYTkyc4UFaDFbrg2kiuX8xQrATx8WDankAk73rNqFMqxushI5zk8c0 afDQ== X-Gm-Message-State: AEkoouv2eFD6F7+fdliJitt8M9qFkg50MsXgw4u9Ma9U58H+DJuusfDFeVnO0n/yXAbl/9GqiwRdPpYcFWYJCw== X-Received: by 10.28.168.83 with SMTP id r80mr631846wme.44.1471542161909; Thu, 18 Aug 2016 10:42:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.128.135 with HTTP; Thu, 18 Aug 2016 10:42:21 -0700 (PDT) In-Reply-To: References: From: Varun Singh Date: Thu, 18 Aug 2016 20:42:21 +0300 Message-ID: To: Stefan Holmer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "payload@ietf.org" Subject: Re: [payload] FLEXFEC: retransmissions optimization X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 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, 18 Aug 2016 17:43:07 -0000 Hi Stefan, On Tue, Aug 16, 2016 at 2:09 PM, Stefan Holmer wrote: > I agree that we should have the sequence numbers in the flex fec header, but > timestamps I don't see why we need there. RFC 4588 does the same > optimization without running into problems, right? > see below. > I can see that it could be an issue if you retransmit packets from two > different rtp streams, where one is video and one is audio with a different > rtp timestamp rate. Is that the reason for this not being possible, or could > those be differentiated via payload types? Exactly. we can use the FEC stream to protect multiple RTP streams, in which case this would not make sense. And we need to identify the FEC stream, the payload type for the FEC packet is set in the SDP. > > /Stefan > > On Tue, Aug 16, 2016 at 1:01 PM Varun Singh wrote: >> >> Hi Stefan, >> >> The RTP header will follow the timing and payload rules for the RTP >> stream. Further, an endpoint could intersperse retx and FEC packets, >> which would make keeping track of sequence numbers difficult. >> >> Regards, >> Varun >> >> On Tue, Aug 16, 2016 at 11:49 AM, Stefan Holmer wrote: >> > Sounds like good optimizations to me. Below are some, possibly naive, >> > suggestions: >> > >> > Have we considered also reusing the timestamp field in the RTP header to >> > save another 4 bytes by not having the timestamp field in the flex fec >> > header when doing retransmits? Since the RTP timestamp should represent >> > the >> > sampling instant of the first octet in the RTP data packet, it seems >> > reasonable that it is the original timestamp and not something newly >> > generated for the retransmit. >> > >> > The same thing might be possible to do with PT recovery. >> > >> > /Stefan >> > >> > On Thu, Jul 21, 2016 at 3:26 PM Varun Singh >> > wrote: >> >> >> >> Hi all, >> >> >> >> Following up on the discussion based in the Payload session at Berlin. >> >> >> >> The current draft has the following format >> >> >> >> 0 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 >> >> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> |F|R| P|X| CC |M| PT recovery | length recovery >> >> | >> >> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | TS recovery >> >> | >> >> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | SSRCCount | reserved >> >> | >> >> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | SSRC_i >> >> | >> >> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | SN base_i |k| Mask [0-14] >> >> | >> >> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> |k| Mask [15-45] (optional) >> >> | >> >> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> |k| >> >> | >> >> +-+ Mask [46-108] (optional) >> >> | >> >> | >> >> | >> >> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | ... next in SSRC_i ... >> >> | >> >> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> >> >> >> >> For retransmission, decomposes to (also in the draft): >> >> >> >> 0 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 >> >> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> |1|1| P|X| CC |M| PT recovery | length recovery >> >> | >> >> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | TS recovery >> >> | >> >> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | SSRCCount=1 | reserved >> >> | >> >> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | SSRC_i >> >> | >> >> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | SN base_i |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 >> >> 0| >> >> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> >> >> The was called out to be suboptimal in Yokohama, and we are now >> >> suggesting >> >> the following: >> >> >> >> >> >> 0 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 >> >> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> |R|F| P|X| CC |M| PT recovery | sequence number >> >> | >> >> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | timestamp >> >> | >> >> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | SSRC >> >> | >> >> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> | Retx >> >> | >> >> >> >> : >> >> RTP payload : >> >> >> >> >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> >> >> >> >> Just want to call out a few things here, comparing FEC payload packets >> >> >> >> and Retx packets: >> >> >> >> >> >> 1. R and F bits swapped places, which makes the retransmission bit >> >> first, >> >> >> >> thus copying the retransmission packet as is, would work because the >> >> >> >> RTP V bit would align with R=1,F=0 and nothing special needs to be >> >> >> >> handled in this case. >> >> >> >> >> >> 2. sequence number (SN base_i) replaces length recovery >> >> >> >> >> >> 3. SSRCCount and the reserved field is removed, as retx contains just >> >> >> >> a single packet from an SSRC. >> >> >> >> >> >> >> >> Regards, >> >> >> >> Varun and Mo. >> >> >> >> >> >> >> >> >> >> -- >> >> http://www.callstats.io >> >> _______________________________________________ >> >> payload mailing list >> >> payload@ietf.org >> >> https://www.ietf.org/mailman/listinfo/payload >> >> >> >> -- >> Founder, CEO, callstats.io >> http://www.callstats.io >> Analytics and Optimizations for WebRTC. >> >> We are hiring: www.callstats.io/jobs/ -- Founder, CEO, callstats.io http://www.callstats.io Analytics and Optimizations for WebRTC. We are hiring: www.callstats.io/jobs/ From nobody Fri Aug 19 07:25:58 2016 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 D5F3F12DA6B; Fri, 19 Aug 2016 07:25:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147161675387.24157.6621487481337860093.idtracker@ietfa.amsl.com> Date: Fri, 19 Aug 2016 07:25:53 -0700 Archived-At: Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-melpe-03.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 14:25:54 -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 of the IETF. Title : RTP Payload Format for MELPe Codec Authors : Victor Demjanenko David Satterlee Filename : draft-ietf-payload-melpe-03.txt Pages : 26 Date : 2016-08-19 Abstract: This document describes the RTP payload format for the Mixed Excitation Linear Prediction Enhanced (MELPe) speech coder. MELPe's three different speech encoding rates and sample frames sizes are supported. Comfort noise procedures and packet loss concealment are detailed. INTERNET DRAFT RTP Payload Format for the MELPe Codec August 19, 2016 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-melpe/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-payload-melpe-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-melpe-03 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 Fri Aug 19 07:30:40 2016 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 5E94A12DAAB for ; Fri, 19 Aug 2016 07:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 ZtjG6erRXDxr for ; Fri, 19 Aug 2016 07:30:36 -0700 (PDT) Received: from cuda.olm1.com (cuda.olm1.com [72.236.255.32]) (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 DC9B912DAEF for ; Fri, 19 Aug 2016 07:30:33 -0700 (PDT) X-ASG-Debug-ID: 1471617026-092fd35b1604300001-U2jSCT Received: from host105.olm1.com (host105.olm1.com [72.236.255.15]) by cuda.olm1.com with ESMTP id qCuwe2nvgSdKZu8E (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 19 Aug 2016 10:30:26 -0400 (EDT) X-Barracuda-Envelope-From: victor.demjanenko@vocal.com X-Barracuda-Apparent-Source-IP: 72.236.255.15 Received: from ClintonLT (rrcs-72-43-202-98.nys.biz.rr.com [72.43.202.98]) by host105.olm1.com (Postfix) with ESMTPSA id 92022B43627; Fri, 19 Aug 2016 10:30:25 -0400 (EDT) From: "Victor Demjanenko, Ph.D." To: "'Roni Even'" , References: <011901d1f1bd$7b734580$7259d080$@gmail.com> In-Reply-To: Date: Fri, 19 Aug 2016 10:30:13 -0400 X-ASG-Orig-Subj: RE: WGLC on draft-ietf-payload-melpe-02 Message-ID: <007301d1fa26$33109100$9931b300$@demjanenko@vocal.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0074_01D1FA04.ABFEF100" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdHnBhrfOOr7ktHaRfyfFTzHl5kaagKsQreAAMFUm9ABWk598A== Content-Language: en-us X-Barracuda-Connect: host105.olm1.com[72.236.255.15] X-Barracuda-Start-Time: 1471617026 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://72.236.255.32:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at olm1.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests=HTML_MESSAGE, MSGID_MULTIPLE_AT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.32152 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 MSGID_MULTIPLE_AT Message-ID contains multiple '@' characters 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Cc: draft-ietf-payload-melpe@ietf.org, "'Dave Satterlee \(Vocal\)'" Subject: Re: [payload] WGLC on draft-ietf-payload-melpe-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 19 Aug 2016 14:30:38 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0074_01D1FA04.ABFEF100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To Payload Members: We have addressed all of Roni's comments with the exception of item 2. Comments on all other items are below in the original list. In response to item 2, we recommend leaving sections 3.1 and 3.2 the way they are. Each of the three MELP speech coder rates were developed by different groups. The notation that each one used is similar but different. 1. One group presented their bits in LSB to MSB order. This was a potential confusion that our draft cleared up with at least one party implementing a MELP RTP payload. (They did not notice the inconsistency between speech coder rates until reading our draft.) 2. The MS Word typesetting nomenclature used non-simple ASCII parameter/field names/bit numbering which is addressed by the normalized tables we present in these sections. 3. Comfort noise is described in yet some other document (SCIP I believe) and is only done verbally. While we do understand the desire for removing unnecessary redundancy, we do believe our normalized tables in 3.1 and 3.2 do help in ensuring an interoperable implementation. As such, they are not an exact copy of reference tables and we recommend leaving these sections as we have written. Regards, Victor Demjanenko David Satterlee From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Monday, August 8, 2016 5:40 PM To: payload@ietf.org Cc: draft-ietf-payload-melpe@ietf.org Subject: RE: WGLC on draft-ietf-payload-melpe-02 Hi, I reviewed the document and have some comments 1. In the abstract you can delete the last sentence "Also, within the document there are included necessary details for the use of MELP with SDP." v-> Done 2. I assume that sections 3.1.1, 3.1.2, 3.1.3, 3.2 are copied from STANAG 4591 in which case you can just provide a reference to the relevant sections v-> We recommend leaving the normalized tables to clear up potential confusion 3. In section 3.3 it looks like a MELPE packet can be of zero coded frame and zero comfort noise frame? v-> We added a sentence to clarify and permit such use. This could be used for encoder connectivity confirmation and not specifically as an RTP keep-alive (which is specifically different and outside this recommended purpose.) 4. For section 3.4 look at RFC7587 section 5 for text suggestions v-> Section 3.4 replaced by recommended text from RFC7587. 5. In section 4.1 the type name is audio while the subtype names are MELP,. v-> The name and subtype name have been corrected. 6. In section 4.1 published specification "RFCXXXX" to be replaced by the RFC Editor v-> RFCXXXX was replaced with RFC6562. 7. In section 4.2 we do not use MIME but "media type" (audio) and "media subtype " (MELPE,.) v-> The word MIME has been removed and "media" added where needed. 8. The following text is not clear "A remote MELPe encoder SHALL receive "bitrate" parameter in the SDP "a=fmtp" attribute by copying them directly from the MIME media type string as a semicolon separated with parameter=value, where parameter is "bitrate", and value can be one or more of 2400, 1200, and 600 separated by commas (where each bit-rate value indicates the corresponding MELPe coder). Is this for the an offer? v-> The language has been changed to "The optional media type parameter, "bitrate", when present, MUST be included in the "a=fmtp" attribute in the SDP, expressed as a media type string in the form of a semicolon-separated list of parameter=value pairs. The string, "value", can be one or more of 2400, 1200, and 600 separated by commas (where each bit-rate value indicates the corresponding MELPe coder)." v-> The bitrate parameter can be used by both offerer and answerer as the example suggests in a later example (now in a new section 4.4 9. We use "For declarative SDP" and not "For streaming media". It also better to have a sub section for SDP offer answer considerations and Declarative SDP considerations v-> Sections 4.3 and 4.4 have been added for declarative SDP and offer/answer SDP. Paragraphs that originally followed offer/answer SDP have been moved up as they apply to all SDP. 10. In section 8 "its media decoder" use "the MELPe encoder" v-> Text now uses "the MELPe decoder". Roni Even From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Tuesday, July 26, 2016 9:24 AM To: 'payload@ietf.org' (payload@ietf.org) Cc: 'draft-ietf-payload-melpe@ietf.org' Subject: WGLC on draft-ietf-payload-melpe-02 Hi, I would like to start a WGLC on https://tools.ietf.org/html/draft-ietf-payload-melpe-02 , RTP Payload Format for MELPe Codec The WGLC will end on August 9th , 2016 Please review the draft and send comments to the list. For the draft authors; Are you aware of any IPR that applies to draft-ietf-payload-melpe-02? If so, has this IPR been disclosed in compliance with IETF IPR rules? The above question is needed for the document write-up when sent to publication. Thanks Roni Even Payload co-chair ------=_NextPart_000_0074_01D1FA04.ABFEF100 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To Payload Members:

 

We have addressed all of = Roni’s comments with the exception of item 2.  Comments on = all other items are below in the original list.

 

In response to item 2, = we recommend leaving sections 3.1 and 3.2 the way they are.  Each = of the three MELP speech coder rates were developed by different = groups.  The notation that each one used is similar but = different. 

 

1.      = One group = presented their bits in LSB to MSB order.  This was a potential = confusion that our draft cleared up with at least one party implementing = a MELP RTP payload.  (They did not notice the inconsistency between = speech coder rates until reading our draft.)

2.      = The MS Word = typesetting nomenclature used non-simple ASCII parameter/field names/bit = numbering which is addressed by the normalized tables we present in = these sections. 

3.      = Comfort = noise is described in yet some other document (SCIP I believe) and is = only done verbally.

 

While we do understand = the desire for removing unnecessary redundancy, we do believe our = normalized tables in 3.1 and 3.2 do help in ensuring an interoperable = implementation.  As such, they are not an exact copy of reference = tables and we recommend leaving these sections as we have = written.

 

Regards,

 

Victor = Demjanenko

David Satterlee

 

 

From:= = Roni Even [mailto:ron.even.tlv@gmail.com]=
Sent: Monday, August 8, 2016 5:40 PM
To: payload@ietf.org
Cc: draft-ietf-payload-melp= e@ietf.org
Subject: RE: WGLC on = draft-ietf-payload-melpe-02

 

Hi,

I reviewed the document = and have some comments

 

1.      = In the = abstract you can delete the last sentence “Also, within the = document there are included necessary details for the use of MELP with = SDP.”

v-> = Done

2.      = I = assume that sections 3.1.1, 3.1.2, = 3.1.3, 3.2 are copied from STANAG 4591 in which case you can just = provide a reference to the relevant sections

v-> We recommend = leaving the normalized tables to clear up potential = confusion

3.      = In section = 3.3 it looks like a MELPE packet can be of zero coded frame and zero = comfort noise frame?

v-> We added a sentence to clarify and permit = such use.  This could be used for encoder connectivity confirmation = and not specifically as an RTP keep-alive (which is specifically = different and outside this recommended purpose.)

4.      = For section = 3.4 look at RFC7587 section 5 for text = suggestions

v-> Section 3.4 replaced by recommended text = from RFC7587.

5.      = In section = 4.1 the type name is audio while the subtype names are = MELP,…

v-> The name and subtype name have been = corrected.

6.      = In section = 4.1 published specification “RFCXXXX” to be replaced by the = RFC Editor

v-> RFCXXXX was replaced with = RFC6562.

7.      = In section = 4.2 we do not use MIME but “media type” (audio) and = “media subtype “ (MELPE,…)

v-> The word MIME has been removed and = “media” added where needed.

8.      = The = following text is not clear ”A remote MELPe encoder SHALL = receive "bitrate" parameter in the SDP "a=3Dfmtp" = attribute by copying them directly from the MIME media type string as a = semicolon separated with parameter=3Dvalue, where parameter is = "bitrate", and value can be one or more of 2400, 1200, and 600 = separated by commas (where each bit-rate value indicates the = corresponding MELPe coder). Is this for the an offer?

v-> The language has been changed to = “The optional media type parameter, "bitrate", when = present, MUST be included in the "a=3Dfmtp" attribute in the = SDP, expressed as a media type string in the form of a = semicolon-separated list of parameter=3Dvalue pairs.  The string, = "value", can be one or more of 2400, 1200, and 600 separated = by commas (where each bit-rate value indicates the corresponding MELPe = coder).”

v-> The bitrate parameter can be used by both = offerer and answerer as the example suggests in a later example (now in = a new section 4.4

9.      We = use “For declarative SDP” and not “For streaming = media”. It also better to have a sub section for SDP offer answer = considerations and Declarative SDP considerations

v-> Sections 4.3 and 4.4 have been added for = declarative SDP and offer/answer SDP.  Paragraphs that originally = followed offer/answer SDP have been moved up as they apply to all = SDP.

10.   In section 8 = “its = media decoder” use “the MELPe encoder”

v-> Text now uses “the MELPe = decoder”.

 

Roni = Even

 

From:= = Roni Even [mailto:ron.even.tlv@gmail.com]=
Sent: Tuesday, July 26, 2016 9:24 AM
To: = 'payload@ietf.org' (payload@ietf.org)
Cc: = 'draft-ietf-payload-melpe@ietf.org'
Subject: WGLC on = draft-ietf-payload-melpe-02

 

Hi,

I would =
like to start a WGLC on  https://=
tools.ietf.org/html/draft-ietf-payload-melpe-02  , RTP Payload Format for MELPe =
Codec
 =

 =

 =

The WGLC will = end on August 9th , 2016

 

Please = review the draft and send comments to the list.

 

For the = draft authors;  Are you aware of any IPR that applies to = draft-ietf-payload-melpe-02?

If so, has = this IPR been disclosed in compliance with IETF IPR = rules?

The above =
question is needed for the document write-up when sent to =
publication.
 =

 =

Thanks

 

Roni = Even

Payload =  co-chair

 

------=_NextPart_000_0074_01D1FA04.ABFEF100-- From nobody Fri Aug 19 11:42:25 2016 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 1D9ED12D92B for ; Fri, 19 Aug 2016 11:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 jX9wPlTSUw40 for ; Fri, 19 Aug 2016 11:42:22 -0700 (PDT) Received: from cuda.olm1.com (cuda.olm1.com [72.236.255.32]) (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 89FD512DA86 for ; Fri, 19 Aug 2016 11:42:21 -0700 (PDT) X-ASG-Debug-ID: 1471632139-092fd35b162c770001-U2jSCT Received: from host105.olm1.com (host105.olm1.com [72.236.255.15]) by cuda.olm1.com with ESMTP id M7HeXKHxxcjxHxr3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 19 Aug 2016 14:42:19 -0400 (EDT) X-Barracuda-Envelope-From: victor.demjanenko@vocal.com X-Barracuda-Apparent-Source-IP: 72.236.255.15 Received: from ClintonLT (rrcs-72-43-202-98.nys.biz.rr.com [72.43.202.98]) by host105.olm1.com (Postfix) with ESMTPSA id 3DC12B4357D; Fri, 19 Aug 2016 14:42:19 -0400 (EDT) From: "Victor Demjanenko, Ph.D." To: "'Lee, John'" , , References: , <133601d1f7eb$fdd624a0$f9826de0$@demjanenko@vocal.com> <20160818053154.7073877.99795.1928@dynetics.com> In-Reply-To: <20160818053154.7073877.99795.1928@dynetics.com> Date: Fri, 19 Aug 2016 14:42:06 -0400 X-ASG-Orig-Subj: RE: Latest MELP RTP Payload draft (UNCLASSIFIED) Message-ID: <00b801d1fa49$63531180$29f93480$@demjanenko@vocal.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B9_01D1FA27.DC417180" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdHuekjWp8YznbmBRxKbRxxuIWjH4gJcN/4QAEmphcsATcD8AA== Content-Language: en-us X-Barracuda-Connect: host105.olm1.com[72.236.255.15] X-Barracuda-Start-Time: 1471632139 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://72.236.255.32:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at olm1.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests=HTML_MESSAGE, MSGID_MULTIPLE_AT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.32157 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 MSGID_MULTIPLE_AT Message-ID contains multiple '@' characters 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Cc: "'SHERIDAN, LARRY M \(Michael\) JR CTR USARMY RDECOM AMRDEC \(US\)'" , "'Dave Satterlee \(Vocal\)'" Subject: Re: [payload] Latest MELP RTP Payload draft (UNCLASSIFIED) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 19 Aug 2016 18:42:24 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00B9_01D1FA27.DC417180 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi John, =20 Thank you for your comments and confirming this special case. =20 As you may have seen a revised draft (03) has been posted. I think this should be close to final. We are awaiting Roni and Ali to advise on the next step(s). =20 Thanks to everyone on this mailing group for your support and comments. =20 Victor & David =20 =20 From: Lee, John [mailto:John.Lee@dynetics.com]=20 Sent: Thursday, August 18, 2016 1:32 AM To: Victor Demjanenko, Ph.D. Cc: victord@vocal.com; daves@vocal.com; SHERIDAN, LARRY M (Michael) JR = CTR USARMY RDECOM AMRDEC (US) Subject: RE: Latest MELP RTP Payload draft (UNCLASSIFIED) =20 Victor, =FDI don't believe it would break anything, but it might introduce a new = edge case that would need to be considered by our vendors. I don't think we = can speak for them. Worst case scenario, we end up levying a separate requirement on our systems prohibiting something that is permitted (but = not required) in the RFC to ensure interoperability. So, I do not think = there is a problem with proceeding if that behavior is desired. =20 =20 From: Victor Demjanenko, Ph.D. Sent: Tuesday, August 16, 2016 8:28 AM To: Lee, John Cc: victord@vocal.com; daves@vocal.com Subject: [EXTERNAL] RE: Latest MELP RTP Payload draft (UNCLASSIFIED) =20 Hi John, =20 You have always been quick with responses and appreciate that. We have = one item that we would like your opinion on before we change/clarify in our = next draft. It has been pointed out that according to our spec the MELP RTP packet may contain no speech coder frame and no comfort noise frame. We = can either prohibit this or we can permit it. One possibly useful = permission is to us an empty frame to indicate an otherwise idle receiver. This would indicate the absence of a radio receive signal. One can argue that this = is the role of RTP keep-alive but the keep-alive mechanism could be from a different layer in some implementation? =20 =20 Do you have any comments or preference? =20 Will be break anything if we allow an empty MELP RTP packet? =20 A quick response would be helpful as we are about to post a revised = draft. =20 Thanks, =20 Victor =20 =20 From: Lee, John [mailto:John.Lee@dynetics.com]=20 Sent: Monday, August 8, 2016 5:24 PM To: payload@ietf.org; draft-ietf-payload-melpe@ietf.org Cc: victord@vocal.com; daves@vocal.com Subject: Latest MELP RTP Payload draft (UNCLASSIFIED) =20 Dave and Victor, I concur with the latest draft.=20 Thanks, John Lee JSIL Cert Center (O) 256-955-8969 (BB) 256-698-8985 =20 _____ =20 The information contained in this message, and any attachments, may = contain privileged and/or proprietary information that is intended solely for = the person or entity to which it is addressed. Moreover, it may contain = export restricted technical data controlled by Export Administration = Regulations (EAR) or the International Traffic in Arms Regulations (ITAR). Any = review, retransmission, dissemination, or re-export to foreign or domestic = entities by anyone other than the intended recipient in accordance with EAR = and/or ITAR regulations is prohibited. ------=_NextPart_000_00B9_01D1FA27.DC417180 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Hi John,

 

Thank you for your comments and confirming this special = case.

 

As you may have seen a revised draft (03) has been posted.=A0 I think = this should be close to final.=A0 We are awaiting Roni and Ali to advise = on the next step(s).

 

Thanks to everyone on this mailing group for your support and = comments.

 

Victor & David

 

 

From:= = Lee, John [mailto:John.Lee@dynetics.com]
Sent: Thursday, = August 18, 2016 1:32 AM
To: Victor Demjanenko, = Ph.D.
Cc: victord@vocal.com; daves@vocal.com; SHERIDAN, LARRY = M (Michael) JR CTR USARMY RDECOM AMRDEC (US)
Subject: RE: = Latest MELP RTP Payload draft = (UNCLASSIFIED)

 

Victor,

=FDI don't = believe it would break anything, but it might introduce a new edge case = that would need to be considered by our vendors. I don't think we can = speak for them. Worst case scenario, we end up levying a separate = requirement on our systems prohibiting something that is permitted (but = not required) in the RFC to ensure interoperability. So, I do not think = there is a problem with proceeding if that behavior is = desired.

 

 

From: = Victor = Demjanenko, Ph.D.

Sent: = Tuesday, = August 16, 2016 8:28 AM

To: = Lee, = John

Subject: = [EXTERNAL] = RE: Latest MELP RTP Payload draft = (UNCLASSIFIED)

 

Hi John,

 

You have always been quick with responses and appreciate that.  = We have one item that we would like your opinion on before we = change/clarify in our next draft.  It has been pointed out that = according to our spec the MELP RTP packet may contain no speech coder = frame and no comfort noise frame.  We can either prohibit this or = we can permit it.  One possibly useful permission is to us an empty = frame to indicate an otherwise idle receiver.  This would indicate = the absence of a radio receive signal.  One can argue that this is = the role of RTP keep-alive but the keep-alive mechanism could be from a = different layer in some implementation? 

 

Do you have any comments or preference?

 

Will be break anything if we allow an empty MELP RTP = packet?

 

A quick response would be helpful as we are about to post a revised = draft.

 

Thanks,

 

Victor

 

 

From:= = Lee, John [mailto:John.Lee@dynetics.com] =
Sent: Monday, August 8, 2016 5:24 PM
To: payload@ietf.org; draft-ietf-payload-melp= e@ietf.org
Cc: victord@vocal.com; daves@vocal.com
Subject: = Latest MELP RTP Payload draft = (UNCLASSIFIED)

 

= Dave and Victor,
I concur with the latest draft. =

= Thanks,

J= ohn Lee

J= SIL Cert Center

(= O) 256-955-8969

(= BB) = 256-698-8985

 

The information contained in this message, and = any attachments, may contain privileged and/or proprietary information = that is intended solely for the person or entity to which it is = addressed. Moreover, it may contain export restricted technical data = controlled by Export Administration Regulations (EAR) or the = International Traffic in Arms Regulations (ITAR). Any review, = retransmission, dissemination, or re-export to foreign or domestic = entities by anyone other than the intended recipient in accordance with = EAR and/or ITAR regulations is = prohibited.

------=_NextPart_000_00B9_01D1FA27.DC417180-- From nobody Sat Aug 20 13:59:22 2016 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 088E012B005; Sat, 20 Aug 2016 13:59:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147172676099.2623.6422849732429308870.idtracker@ietfa.amsl.com> Date: Sat, 20 Aug 2016 13:59:20 -0700 Archived-At: Cc: payload-chairs@ietf.org, payload@ietf.org Subject: [payload] payload - New Meeting Session Request for IETF 97 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 20:59:21 -0000 A new meeting session request has just been submitted by Roni Even, a Chair of the payload working group. --------------------------------------------------------- Working Group Name: Audio/Video Transport Payloads Area Name: Applications and Real-Time Area Session Requester: Roni Even Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 70 Conflicts to Avoid: First Priority: tsvwg rmcat xrblock rtcweb avtcore mmusic dispatch avtext netvc perc Second Priority: tram sipcore lmap stir Third Priority: tls Special Requests: will be good directly after avtcore --------------------------------------------------------- From nobody Tue Aug 23 04:48:20 2016 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 3617712D09B for ; Tue, 23 Aug 2016 04:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=webrtc-org.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 uNGR0yblaeH0 for ; Tue, 23 Aug 2016 04:48:16 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 EF66B12B007 for ; Tue, 23 Aug 2016 04:48:14 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id i5so191121230wmg.0 for ; Tue, 23 Aug 2016 04:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=webrtc-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+y/VdXzYR20FPXxByX2ruXwGe8WM03+bcDx0J5HkG6w=; b=AG2ZOnzxr+8qX7dho/qWX/U5biFbITALOmNLfGBirlYcHoH8KqZaPWDzAgV4ig7oUe Fa3T1k69EziHi0Vrg5Wf7NERetcYihe3zDk53fU7v3UQwvsv5yt+ObB29ASnn81E3EhX N5WFr5OmGJcOYGYa7GrdtkPd1jb3tlAHK8IVTkUM4DVSwUbhBXIpT+nOektcNFgv1d95 eGCLr66Yhudvo9ojZutfWBDSoniA3xSiJCMYrnh0h5VSmgrIhXbECDPThNmSXbhNQhqL xjfgyUzhKYUCe8f1va46k93Bq1ynL8g3MKAdMHoZgBQbDSRw4XjHgVcFV5T9htI5Lkjp jVmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+y/VdXzYR20FPXxByX2ruXwGe8WM03+bcDx0J5HkG6w=; b=Tfsgb1JrJRhPIK7R+01S3FDkiCgbOzoQKRlxxY3wJ+L1/hovzb5ucrptx+vHQe0+Lp HNfjXUIrEc+RiQ8Et8DOVFs8BDSK+E5dUCQmzc6QXwYOwkQX//x2mibd7EblCrtmVCp5 N4udi+6cxvznU0cbFsQ6rDI5tvZf+T06pIdpJmnOGP3DCK647T5U9EcMnHRkfc8kMq3v /6xKg1Qsg4+NqT0Nv+Y96/GAFdx8I7vwAUY3aKfK5Uaoy8gTa6qV1D68MXsj9odruy5G Part5KldmSarDcFU3h3VFT5w2ouyuK5EBs+D9jgbmYgcbhbXCwP7oemkteNV8uGcqxfa X1Wg== X-Gm-Message-State: AEkooutz7Kq6sEd8kJTuoFZsUv1SR5T0+2869GjEY1J6w0Iis3D52yHZ8TztvvdDwACH4Fjz67SXAULlFrmomVCd X-Received: by 10.28.13.143 with SMTP id 137mr20393355wmn.46.1471952893148; Tue, 23 Aug 2016 04:48:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Stefan Holmer Date: Tue, 23 Aug 2016 11:48:02 +0000 Message-ID: To: Varun Singh Content-Type: multipart/alternative; boundary=001a1144248852f1b5053abbbd8e Archived-At: Cc: "payload@ietf.org" Subject: Re: [payload] FLEXFEC: retransmissions optimization X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 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, 23 Aug 2016 11:48:19 -0000 --001a1144248852f1b5053abbbd8e Content-Type: text/plain; charset=UTF-8 On Thu, Aug 18, 2016 at 7:42 PM Varun Singh wrote: > Hi Stefan, > > On Tue, Aug 16, 2016 at 2:09 PM, Stefan Holmer wrote: > > I agree that we should have the sequence numbers in the flex fec header, > but > > timestamps I don't see why we need there. RFC 4588 does the same > > optimization without running into problems, right? > > > > see below. > Two follow-up questions: 1. What RTP timestamp frequency do we recommend for flexfec packets? This doesn't seem to be specified in the draft. 2. What value do we think the current definition of the flexfec timestamps will provide (representing the transmission time of the flexfec packet)? The possiblity of computing the trannsmission jitter? It's not immediately obvious to me what value that adds. > > > I can see that it could be an issue if you retransmit packets from two > > different rtp streams, where one is video and one is audio with a > different > > rtp timestamp rate. Is that the reason for this not being possible, or > could > > those be differentiated via payload types? > > Exactly. we can use the FEC stream to protect multiple RTP streams, in > which > case this would not make sense. And we need to identify the FEC stream, > the payload type for the FEC packet is set in the SDP. > Agree, it doesn't generalize well to protecting multiple streams. Thanks. > > > > > /Stefan > > > > On Tue, Aug 16, 2016 at 1:01 PM Varun Singh wrote: > >> > >> Hi Stefan, > >> > >> The RTP header will follow the timing and payload rules for the RTP > >> stream. Further, an endpoint could intersperse retx and FEC packets, > >> which would make keeping track of sequence numbers difficult. > >> > >> Regards, > >> Varun > >> > >> On Tue, Aug 16, 2016 at 11:49 AM, Stefan Holmer > wrote: > >> > Sounds like good optimizations to me. Below are some, possibly naive, > >> > suggestions: > >> > > >> > Have we considered also reusing the timestamp field in the RTP header > to > >> > save another 4 bytes by not having the timestamp field in the flex fec > >> > header when doing retransmits? Since the RTP timestamp should > represent > >> > the > >> > sampling instant of the first octet in the RTP data packet, it seems > >> > reasonable that it is the original timestamp and not something newly > >> > generated for the retransmit. > >> > > >> > The same thing might be possible to do with PT recovery. > >> > > >> > /Stefan > >> > > >> > On Thu, Jul 21, 2016 at 3:26 PM Varun Singh > >> > wrote: > >> >> > >> >> Hi all, > >> >> > >> >> Following up on the discussion based in the Payload session at > Berlin. > >> >> > >> >> The current draft has the following format > >> >> > >> >> 0 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 > >> >> > >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >> |F|R| P|X| CC |M| PT recovery | length recovery > >> >> | > >> >> > >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >> | TS recovery > >> >> | > >> >> > >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >> | SSRCCount | reserved > >> >> | > >> >> > >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >> | SSRC_i > >> >> | > >> >> > >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >> | SN base_i |k| Mask [0-14] > >> >> | > >> >> > >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >> |k| Mask [15-45] (optional) > >> >> | > >> >> > >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >> |k| > >> >> | > >> >> +-+ Mask [46-108] (optional) > >> >> | > >> >> | > >> >> | > >> >> > >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >> | ... next in SSRC_i ... > >> >> | > >> >> > >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >> > >> >> > >> >> > >> >> For retransmission, decomposes to (also in the draft): > >> >> > >> >> 0 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 > >> >> > >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >> |1|1| P|X| CC |M| PT recovery | length recovery > >> >> | > >> >> > >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >> | TS recovery > >> >> | > >> >> > >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >> | SSRCCount=1 | reserved > >> >> | > >> >> > >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >> | SSRC_i > >> >> | > >> >> > >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >> | SN base_i |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > >> >> 0| > >> >> > >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >> > >> >> > >> >> The was called out to be suboptimal in Yokohama, and we are now > >> >> suggesting > >> >> the following: > >> >> > >> >> > >> >> 0 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 > >> >> > >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >> |R|F| P|X| CC |M| PT recovery | sequence number > >> >> | > >> >> > >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >> | timestamp > >> >> | > >> >> > >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >> | SSRC > >> >> | > >> >> > >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >> > >> >> | Retx > >> >> | > >> >> > >> >> : > >> >> RTP payload : > >> >> > >> >> > >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >> > >> >> > >> >> > >> >> Just want to call out a few things here, comparing FEC payload > packets > >> >> > >> >> and Retx packets: > >> >> > >> >> > >> >> 1. R and F bits swapped places, which makes the retransmission bit > >> >> first, > >> >> > >> >> thus copying the retransmission packet as is, would work because the > >> >> > >> >> RTP V bit would align with R=1,F=0 and nothing special needs to be > >> >> > >> >> handled in this case. > >> >> > >> >> > >> >> 2. sequence number (SN base_i) replaces length recovery > >> >> > >> >> > >> >> 3. SSRCCount and the reserved field is removed, as retx contains just > >> >> > >> >> a single packet from an SSRC. > >> >> > >> >> > >> >> > >> >> Regards, > >> >> > >> >> Varun and Mo. > >> >> > >> >> > >> >> > >> >> > >> >> -- > >> >> http://www.callstats.io > >> >> _______________________________________________ > >> >> payload mailing list > >> >> payload@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/payload > >> > >> > >> > >> -- > >> Founder, CEO, callstats.io > >> http://www.callstats.io > >> Analytics and Optimizations for WebRTC. > >> > >> We are hiring: www.callstats.io/jobs/ > > > > -- > Founder, CEO, callstats.io > http://www.callstats.io > Analytics and Optimizations for WebRTC. > > We are hiring: www.callstats.io/jobs/ > --001a1144248852f1b5053abbbd8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu= , Aug 18, 2016 at 7:42 PM Varun Singh <varun@callstats.io> wrote:
Hi Stefan,

On Tue, Aug 16, 2016 at 2:09 PM, Stefan Holmer <stefan@webrtc.org> w= rote:
> I agree that we should have the sequence numbers in the flex fec heade= r, but
> timestamps I don't see why we need there. RFC 4588 does the same > optimization without running into problems, right?
>

see below.

Two follow-up questions:
1. What RTP timestamp frequency do we recommend for flexfec packets?= This doesn't seem to be specified in the draft.

2. What value do we think the current definition of the flexfec timestam= ps will provide (representing the transmission time of the flexfec packet)?= The possiblity of computing the trannsmission jitter? It's not immedia= tely obvious to me what value that adds.
=C2=A0

> I can see that it could be an issue if you retransmit packets from two=
> different rtp streams, where one is video and one is audio with a diff= erent
> rtp timestamp rate. Is that the reason for this not being possible, or= could
> those be differentiated via payload types?

Exactly. we can use the FEC stream to protect multiple RTP streams, in whic= h
case this would not make sense. And we need to identify the FEC stream,
the payload type for the FEC packet is set in the SDP.

Agree, it doesn't generalize well to protecting multipl= e streams. Thanks.
=C2=A0

>
> /Stefan
>
> On Tue, Aug 16, 2016 at 1:01 PM Varun Singh <varun@callstats.io&g= t; wrote:
>>
>> Hi Stefan,
>>
>> The RTP header will follow the timing and payload rules for the RT= P
>> stream. Further, an endpoint could intersperse retx and FEC packet= s,
>> which would make keeping track of sequence numbers difficult.
>>
>> Regards,
>> Varun
>>
>> On Tue, Aug 16, 2016 at 11:49 AM, Stefan Holmer <stefan@webrtc.org= > wrote:
>> > Sounds like good optimizations to me. Below are some, possibl= y naive,
>> > suggestions:
>> >
>> > Have we considered also reusing the timestamp field in the RT= P header to
>> > save another 4 bytes by not having the timestamp field in the= flex fec
>> > header when doing retransmits? Since the RTP timestamp should= represent
>> > the
>> > sampling instant of the first octet in the RTP data packet, i= t seems
>> > reasonable that it is the original timestamp and not somethin= g newly
>> > generated for the retransmit.
>> >
>> > The same thing might be possible to do with PT recovery.
>> >
>> > /Stefan
>> >
>> > On Thu, Jul 21, 2016 at 3:26 PM Varun Singh <vsingh.ietf@= gmail.com>
>> > wrote:
>> >>
>> >> Hi all,
>> >>
>> >> Following up on the discussion based in the Payload sessi= on at Berlin.
>> >>
>> >> The current draft has the following format
>> >>
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00 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
>> >>
>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |F|R| P|X|=C2=A0 CC=C2=A0 =C2= =A0|M| PT recovery |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0length recovery
>> >> |
>> >>
>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TS recovery<= br> >> >> |
>> >>
>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0SSRCCount=C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 reserved
>> >> |
>> >>
>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0SSRC_i
>> >> |
>> >>
>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0SN base_i=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|k|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mask [0-14]
>> >> |
>> >>
>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |k|=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mask [15-45] (optional)
>> >> |
>> >>
>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |k|
>> >> |
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mask [46-108] (optional)
>> >> |
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>> >> |
>> >>
>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0... next in SSRC_i ...
>> >> |
>> >>
>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>> >>
>> >>
>> >>
>> >> For retransmission, decomposes to (also in the draft): >> >>
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00 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
>> >>
>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |1|1| P|X|=C2=A0 CC=C2=A0 =C2= =A0|M| PT recovery |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0length recovery
>> >> |
>> >>
>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TS recovery<= br> >> >> |
>> >>
>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0SSRCCount=3D1 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 reser= ved
>> >> |
>> >>
>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0SSRC_i
>> >> |
>> >>
>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0SN base_i=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|0 0 0 0 0 0= 0 0 0 0 0 0 0 0 0
>> >> 0|
>> >>
>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>> >>
>> >>
>> >> The was called out to be suboptimal in Yokohama, and we a= re now
>> >> suggesting
>> >> the following:
>> >>
>> >>
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00 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
>> >>
>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |R|F| P|X|=C2=A0 CC=C2=A0 =C2= =A0|M| PT recovery |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sequence number
>> >> |
>> >>
>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 times= tamp
>> >> |
>> >>
>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0SSRC
>> >> |
>> >>
>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>> >>
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Retx
>> >> |
>> >>
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0:
>> >> RTP payload=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 :
>> >>
>> >>
>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
>> >>
>> >>
>> >>
>> >> Just want to call out a few things here, comparing FEC pa= yload packets
>> >>
>> >> and Retx packets:
>> >>
>> >>
>> >> 1. R and F bits swapped places, which makes the retransmi= ssion bit
>> >> first,
>> >>
>> >> thus copying the retransmission packet as is, would work = because the
>> >>
>> >> RTP V bit would align with R=3D1,F=3D0 and nothing specia= l needs to be
>> >>
>> >> handled in this case.
>> >>
>> >>
>> >> 2. sequence number (SN base_i) replaces length recovery >> >>
>> >>
>> >> 3. SSRCCount and the reserved field is removed, as retx c= ontains just
>> >>
>> >> a single packet from an SSRC.
>> >>
>> >>
>> >>
>> >> Regards,
>> >>
>> >> Varun and Mo.
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> http://www.callstats.io
>> >> _______________________________________________
>> >> payload mailing list
>> >> payload@ietf.org
>> >> https://www.ietf.org= /mailman/listinfo/payload
>>
>>
>>
>> --
>> Founder, CEO, callstats.io
>> http://www.callstats.io
>> Analytics and Optimizations for WebRTC.
>>
>> We are hiring: www.callstats.io/jobs/



--
Founder, CEO, callstats.io
http://www.callstats.io
Analytics and Optimizations for WebRTC.

We are hiring: www.callstats.io/jobs/
--001a1144248852f1b5053abbbd8e-- From nobody Thu Aug 25 15:45:33 2016 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 3370712D0C8; Thu, 25 Aug 2016 15:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=unavailable 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 I0jdiDfm7iUq; Thu, 25 Aug 2016 15:45:31 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 AF7EE12D13B; Thu, 25 Aug 2016 15:36:47 -0700 (PDT) Received: from [10.0.1.9] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u7PMakeW001266 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 25 Aug 2016 17:36:47 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.9] From: "Ben Campbell" To: draft-ietf-payload-rtp-ancillary.all@ietf.org, payload@ietf.org Date: Thu, 25 Aug 2016 17:36:46 -0500 Message-ID: <245276B7-8A49-450C-A98A-C3026BF0F9E5@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Subject: [payload] AD Evaluation of draft-ietf-payload-rtp-ancillary-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 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 Aug 2016 22:45:32 -0000 Hi, This is my AD evaluation of draft-ietf-payload-rtp-ancillary-05. I'd like to at least resolve the substantive comments before going to IETF last call. Thanks! Ben. ---------------- *** Substantive Comments *** : - General: There's a lot of use of 2119 keywords in situations where you talk more about definitions/ statements of fact than procedure. I mention some specific instances below, but may not have caught all of them. - Section 1: A quick mention of the meaning of horizontal and vertical ancillary spaces would be helpful. The 6th paragraph says ancillary data flag (ADF) word is not carried in this payload. But section 2.1, under "horizontal offset" says "A value of 0 means that the Ancillary Data Flag (ADF) of the ANC data packet begins immediately following SAV." These seem to conflict--are they talking about something different? - section 2: -- timestamp: "For progressive scan video, the timestamp SHALL denote the sampling instant of the frame to which the ancillary data in the RTP packet belongs." That's a definition. I suggest "... timestamp denotes..." (occurs twice) -- Marker Bit: "The marker bit set to "1" SHALL indicate the last ANC RTP packet ..." Consider "The marker bit set to "1" indicates..." - section 2.1: Am I correct to assume the various length or count fields are unsigned integers? Network byte order? -- ANC count: "A single ANC RTP packet payload SHALL NOT carry more than 255 ANC data packets." Isn't this a statement of fact, since the number is limited by the 8 bit ANC_Count field? If so, consider s/SHALL NOT/cannot On the other hand, the "may" in "additional RTP packets carrying ANC data may be sent with the same RTP timestamp but with different sequence numbers." seems to be an appropriate place for a 2119 "MAY" "ANC_Count of 0 SHALL indicate that there are no ANC data packets" Please consider s/SHALL indicate/indicates -- Horizontal Offset: All 3 instances of "SHALL" seem more like statements of fact. - 3.1, Required Parameters: "When an ANC RTP stream is to be associated with an RTP video stream, the RTP timestamp rates SHOULD be the same to ensure that ANC data packets can be associated with the appropriate frame or field." Why not MUST? Do you anticipate that there might be situations where it's reasonable for the rates not to match? -- intended usage: Is "Common" the right choice? Do you expect this to be widely used, or just in some very specific applications? - 3.2, encoding of the subtype name: It would be helpful to mention the "rate" parameter here as well. -- mapping of "DID_SDID" parameters: It would be helpful to mention the ability to carry multiple types earlier in the document (perhaps where types are first mentioned, or where DID_SDID was first mentioned.) - 5: The security considerations do not include the recommended text from draft-ietf-payload-rtp-howto-14, section A.13. Should it? - References: It seems like the references to [RFC3264] and [RFC5888] should be normative. *** Editorial Comments ***: - General: An early description of the meaning of ANC data packet types would be helpful. - section 1: A quick mention of the meaning of horizontal and vertical ancillary spaces would be helpful. - section 1.1, last paragraph: By "data model", does this talk about the packet format, or something else? -3.1, optional parameters: Is this link reasonably permanent? Also, consider moving this to the references section (perhaps in a separate "URLs" section) and citing it normally. It would be helpful to mention that DID_SDIS can occur multiple times (or be a list of values, depending on your perspective.) -- Change controller: I suspect this should say “ The IETF PAYLOAD working group, or other party as designated by the IESG.”" - 3.2.1 What does "essence" mean in the context of "video essence stream"? Am I correct to assume it refers to the actual video content?