From nobody Mon Feb 2 14:08:38 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477D31A0363 for ; Mon, 2 Feb 2015 14:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 1pc6pnzQJHao for ; Mon, 2 Feb 2015 14:08:34 -0800 (PST) Received: from BLU004-OMC2S15.hotmail.com (blu004-omc2s15.hotmail.com [65.55.111.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32EC71A00FF for ; Mon, 2 Feb 2015 14:08:34 -0800 (PST) Received: from BLU181-W93 ([65.55.111.73]) by BLU004-OMC2S15.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Mon, 2 Feb 2015 14:08:33 -0800 X-TMN: [TlyvDd1toBRqGfIqMBqib8Mrdn9W/oZ5] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_2f64a8ef-4361-445e-bfaf-d08056d1ec23_" From: Bernard Aboba To: "avtext@ietf.org" Date: Mon, 2 Feb 2015 14:08:32 -0800 Importance: Normal In-Reply-To: <54CBA5AF.7040006@ericsson.com> References: <54CBA5AF.7040006@ericsson.com> MIME-Version: 1.0 X-OriginalArrivalTime: 02 Feb 2015 22:08:33.0672 (UTC) FILETIME=[C8FE9080:01D03F34] Archived-At: Subject: Re: [avtext] Comments on draft-ietf-avtext-rtp-grouping-taxonomy-05 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 22:08:36 -0000 --_2f64a8ef-4361-445e-bfaf-d08056d1ec23_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have a comment on the use of the term "redundancy" in the draft. There= is no definition of the term in the document=2C and even after reading it= =2C I was not clear whether the term was referring specifically to redundan= t data (RFC 2198) or perhaps more generally to robustness mechanisms in gen= eral=2C including Forward Error Correction (FEC) (e.g. RFC 5109)=2C retrans= mission (e.g. RFC 4588)=2C etc.=20 =20 In particular=2C these mechanisms differ in a number of potentially relevan= t dimensions=2C such as their compatibility with BUNDLE.=20 = --_2f64a8ef-4361-445e-bfaf-d08056d1ec23_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I =3B have a comment on the = use of the term "redundancy" in the draft. =3B =3B There is no defi= nition of the term in the document=2C and even after reading it=2C I was no= t clear whether the term was referring specifically to redundant data (RFC = 2198) or perhaps more generally to robustness mechanisms in general=2C incl= uding Forward Error Correction (FEC) (e.g. RFC 5109)=2C retransmission (e.g= . RFC 4588)=2C etc.
 =3B
In particular=2C these mechanisms diffe= r in a number of potentially relevant dimensions=2C such as their compatibi= lity with BUNDLE.
= --_2f64a8ef-4361-445e-bfaf-d08056d1ec23_-- From nobody Tue Feb 3 00:20:49 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232031A86F3 for ; Tue, 3 Feb 2015 00:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 8q9Y4Y8BBF8J for ; Tue, 3 Feb 2015 00:20:45 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68CA11A86EF for ; Tue, 3 Feb 2015 00:20:44 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-ff-54d084daac28 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 0A.C1.04076.AD480D45; Tue, 3 Feb 2015 09:20:42 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.233]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0210.002; Tue, 3 Feb 2015 09:20:41 +0100 From: Bo Burman To: Bernard Aboba , "avtext@ietf.org" Thread-Topic: [avtext] Comments on draft-ietf-avtext-rtp-grouping-taxonomy-05 Thread-Index: AQHQPKL0EJzOHIEyRk2CgKznnjEnWZzd34YAgAC4xIA= Date: Tue, 3 Feb 2015 08:20:40 +0000 Message-ID: References: <54CBA5AF.7040006@ericsson.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22E46EEE8ESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+Jvje6tlgshBmv+iFh8vHeD1WL/ksvM Dkwej3vOsHksWfKTKYApissmJTUnsyy1SN8ugStj+5Hd7AVnEyuevHzL3MB4P6yLkYNDQsBE YvNt3i5GTiBTTOLCvfVsXYxcHEICRxglbr3dDuUsZpS41nOJFaSKTUBDYv6Ou4wgtohAiMSK tqVgcWEBH4mGzVOYIeK+El2LN0HZVhI7131kBlnGIqAi8XJtPkiYF6hk64L/7CBhIYFoiVX/ pEDCnEDVr2+tZQOxGQVkJe5/v8cCYjMLiEvcejKfCeJOAYkle84zQ9iiEi8f/2OFeEVJYtrW NIjyfIm9h9YzQ2wSlDg58wnLBEaRWUgmzUJSNgtJGURcR2LB7k9sELa2xLKFr5lh7DMHHjMh iy9gZF/FKFqcWlycm25kpJdalJlcXJyfp5eXWrKJERhRB7f8ttrBePC54yFGAQ5GJR7eDZYX QoRYE8uKK3MPMUpzsCiJ89oZHwoREkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwJi1Y5f0NtFF 0/OD50zz3dIh+0lk6aVU44q/3a/mRhari2W/czm4k226LhP3/NWXHOeeaJC+tM3+cDHXLRGu JZsivfX2iSz4nszysfeGurfiZLH5HExruU5vr2iX0mFRe+Xl9bPGoUNr/7w7Fz/8vHDm7V2B lE/r51r9P7KS214oXUv9UZKd/3olluKMREMt5qLiRABGTcdviQIAAA== Archived-At: Subject: Re: [avtext] Comments on draft-ietf-avtext-rtp-grouping-taxonomy-05 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 08:20:48 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22E46EEE8ESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It would of course be possible to define the use of the term "redundancy" i= n the document, but I think it should already be pretty clear from sections= 2.1.11 and 2.1.12 that the intention is to cover the more general robustne= ss mechanisms: 2.1.11. RTP-based Redundancy RTP-based Redundancy is defined here as a transformation that generates redundant or repair packets sent out as a Redundancy RTP Stream (Section 2.1.12) to mitigate network transport impairments, like packet loss and delay. The RTP-based Redundancy exists in many flavors; they may be generating independent Repair Streams that are used in addition to the Source Stream (like RTP Retransmission (Section 3.11) and some special types of Forward Error Correction, like RTP stream duplication (Section 3.9)), they may generate a new Source Stream by combining redundancy information with source information (Using XOR FEC (Section 3.12) as a redundancy payload (Section 3.10)), or completely replace the source information with only redundancy packets. 2.1.12. Redundancy RTP Stream A RTP Stream (Section 2.1.10) that contains no original source data, only redundant data that may be combined with one or more Received RTP Stream (Section 2.1.19) to produce Repaired RTP Streams (Section 2.1.22). Referring to the above text, can you please be more explicit in what you th= ink is unclear, or what could be changed to be more clear? /Bo From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: den 2 februari 2015 23:09 To: avtext@ietf.org Subject: Re: [avtext] Comments on draft-ietf-avtext-rtp-grouping-taxonomy-0= 5 I have a comment on the use of the term "redundancy" in the draft. There= is no definition of the term in the document, and even after reading it, I= was not clear whether the term was referring specifically to redundant dat= a (RFC 2198) or perhaps more generally to robustness mechanisms in general,= including Forward Error Correction (FEC) (e.g. RFC 5109), retransmission (= e.g. RFC 4588), etc. In particular, these mechanisms differ in a number of potentially relevant = dimensions, such as their compatibility with BUNDLE. --_000_BBE9739C2C302046BD34B42713A1E2A22E46EEE8ESESSMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It would of course be pos= sible to define the use of the term “redundancy” in the documen= t, but I think it should already be pretty clear from sections 2.1.11 and 2.1.12 that the intention is to cover the more general robustness mech= anisms:

 <= /p>

2.1.11.  RTP-based Redundancy<= /span>

 

   RTP-based Redundancy is defined h= ere as a transformation that

   generates redundant or repair pac= kets sent out as a Redundancy RTP

   Stream (Section 2.1.12) to mitiga= te network transport impairments,

   like packet loss and delay.<= /o:p>

 

   The RTP-based Redundancy exists i= n many flavors; they may be

   generating independent Repair Str= eams that are used in addition to

   the Source Stream (like RTP Retransmission (Section 3.11) and some

   special types of Forward Error Correction, like RTP stream

   duplication (Section 3= .9)), they may generate a new Source Stream by

   combining redundancy information = with source information (Using XOR

   FEC (Section 3.12) as a redundancy payload (Section 3.10)), or

   completely replace the source inf= ormation with only redundancy

   packets.

 

2.1.12.  Redundancy RTP Stream=

 

   A RTP Stream (Section 2.1.10) tha= t contains no original source data,

   only redundant data that may be c= ombined with one or more Received

   RTP Stream (Section 2.1.19) to pr= oduce Repaired RTP Streams

   (Section 2.1.22).

 <= /p>

Referring to the above te= xt, can you please be more explicit in what you think is unclear, or what c= ould be changed to be more clear?

 <= /p>

/Bo

 <= /p>

From: avtext [= mailto:avtext-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: den 2 februari 2015 23:09
To: avtext@ietf.org
Subject: Re: [avtext] Comments on draft-ietf-avtext-rtp-grouping-tax= onomy-05

 

I  have a comment on the use of the term "redu= ndancy" in the draft.   There is no definition of the term i= n the document, and even after reading it, I was not clear whether the term= was referring specifically to redundant data (RFC 2198) or perhaps more generally to rob= ustness mechanisms in general, including Forward Error Correction (FEC) (e.= g. RFC 5109), retransmission (e.g. RFC 4588), etc.
 
In particular, these mechanisms differ in a number of potentially relevant = dimensions, such as their compatibility with BUNDLE.

--_000_BBE9739C2C302046BD34B42713A1E2A22E46EEE8ESESSMB105erics_-- From nobody Mon Feb 9 03:33:59 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730A41A0358 for ; Mon, 9 Feb 2015 03:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 g9BP56f-m4lH for ; Mon, 9 Feb 2015 03:33:54 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A26DF1A02F1 for ; Mon, 9 Feb 2015 03:33:52 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-4e-54d89b1e1f03 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C0.EB.04076.E1B98D45; Mon, 9 Feb 2015 12:33:50 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.174]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0210.002; Mon, 9 Feb 2015 12:33:50 +0100 From: Bo Burman To: Magnus Westerlund , "avtext@ietf.org" Thread-Topic: [avtext] Comments on draft-ietf-avtext-rtp-grouping-taxonomy-05 Thread-Index: AQHQPKL0EJzOHIEyRk2CgKznnjEnWZzoGHXA Date: Mon, 9 Feb 2015 11:33:49 +0000 Message-ID: References: <54CBA5AF.7040006@ericsson.com> In-Reply-To: <54CBA5AF.7040006@ericsson.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+Jvja7c7BshBt1TzC0+3rvB6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujH3Xf7AXbKqpWP9BuoFxRmUXIyeHhICJxP6vH9ggbDGJC/fW A9lcHEICRxglpv5fyALhLGaUaLrVwQJSxSagITF/x11GEFtEIFbi4b1OMFtYwEeiYfMUZoi4 r0TX4k1ANgeQbSTx558eiMkioCKx85kwSAUvUMXE16vBOoUEtCXWn5rBBFLCKaAjsaqZGyTM KCArcf/7PbClzALiEreezGeCOFNAYsme88wQtqjEy8f/WCFsRYmr05eDjWEW0JRYv0sfolVR Ykr3Q3aIrYISJ2c+YZnAKDoLydRZCB2zkHTMQtKxgJFlFaNocWpxcW66kZFealFmcnFxfp5e XmrJJkZgJBzc8ttqB+PB546HGAU4GJV4eDco3QgRYk0sK67MPcQozcGiJM5rZ3woREggPbEk NTs1tSC1KL6oNCe1+BAjEwenVAPj6ns/lx7X55/48r5Rj4aM2k83r31ek6ruJ3/WDz1dkvjN cMcaxXu9UvNY2rftWjXlrOl5fR5Wy1vb3dZ9MWFLlO2f17M/MSLwWeX1sNx7335cLrt52nO/ yz95qzkvrc6YeC77w3l8zpOm3mVs1VEBk9v4dnyMK5rTMSX8V9p8vynryla3n+HtUGIpzkg0 1GIuKk4EADa6zQplAgAA Archived-At: Subject: Re: [avtext] Comments on draft-ietf-avtext-rtp-grouping-taxonomy-05 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 11:33:57 -0000 TXkgdmlld3MsIGlubGluZSBiZWxvdy4gL0JvDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogYXZ0ZXh0IFttYWlsdG86YXZ0ZXh0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBNYWdudXMgV2VzdGVybHVuZA0KPiBTZW50OiBkZW4gMzAgamFudWFyaSAyMDE1IDE2 OjM5DQo+IFRvOiBhdnRleHRAaWV0Zi5vcmcNCj4gU3ViamVjdDogW2F2dGV4dF0gQ29tbWVudHMg b24gZHJhZnQtaWV0Zi1hdnRleHQtcnRwLWdyb3VwaW5nLXRheG9ub215LTA1DQo+IA0KPiBIaSwN Cj4gDQo+IEkgaGF2ZSBqdXN0IHJldmlld2VkIGRyYWZ0LWlldGYtYXZ0ZXh0LXJ0cC1ncm91cGlu Zy10YXhvbm9teS0wNSBhbmQgdGhpbmsgaXQgaXMgaW4gZ29vZCBzaGFwZS4gSG93ZXZlciwgSSBk byBoYXZlIHNvbWUNCj4gZmV3IGNvbW1lbnRzIGFuZCByZWZsZWN0aW9ucyBmb3IgdGhlIFdHIHRv IGNvbnNpZGVyLg0KPiANCj4gMS4gVGhlIGNhc2Ugd2hlbiB0aGVyZSBhcmUgbm8gc291cmNlIFJU UCBzdHJlYW0sIG9ubHkgcmVkdW5kYW5jeSBSVFAgc3RyZWFtcy4gVGhpcyByZWxhdGVzIHRvIHR3 byBkaWZmZXJlbnQgc2VjdGlvbnM6DQo+IA0KPiAyLjEuMTIuICBSZWR1bmRhbmN5IFJUUCBTdHJl YW0NCj4gDQo+ICAgIEEgUlRQIFN0cmVhbSAoU2VjdGlvbiAyLjEuMTApIHRoYXQgY29udGFpbnMg bm8gb3JpZ2luYWwgc291cmNlIGRhdGEsDQo+ICAgIG9ubHkgcmVkdW5kYW50IGRhdGEgdGhhdCBt YXkgYmUgY29tYmluZWQgd2l0aCBvbmUgb3IgbW9yZSBSZWNlaXZlZA0KPiAgICBSVFAgU3RyZWFt IChTZWN0aW9uIDIuMS4xOSkgdG8gcHJvZHVjZSBSZXBhaXJlZCBSVFAgU3RyZWFtcw0KPiAgICAo U2VjdGlvbiAyLjEuMjIpLg0KPiANCj4gMi4xLjIxLiAgUlRQLWJhc2VkIFJlcGFpcg0KPiANCj4g ICAgUlRQLWJhc2VkIFJlcGFpciBpcyBhIFRyYW5zZm9ybWF0aW9uIHRoYXQgdGFrZXMgYXMgaW5w dXQgb25lIG9yIG1vcmUNCj4gICAgUmVjZWl2ZWQgUlRQIFN0cmVhbXMgKFNlY3Rpb24gMi4xLjE5 KSBhbmQgUmVjZWl2ZWQgUmVkdW5kYW5jeSBSVFANCj4gICAgU3RyZWFtcyAoU2VjdGlvbiAyLjEu MjApLCBhbmQgcHJvZHVjZXMgb25lIG9yIG1vcmUgUmVwYWlyZWQgUlRQDQo+ICAgIFN0cmVhbXMg KFNlY3Rpb24gMi4xLjIyKSB0aGF0IGFyZSBhcyBjbG9zZSB0byB0aGUgY29ycmVzcG9uZGluZyBz ZW50DQo+ICAgIFNvdXJjZSBSVFAgU3RyZWFtcyAoU2VjdGlvbiAyLjEuMTApIGFzIHBvc3NpYmxl LCB1c2luZyBkaWZmZXJlbnQgUlRQLQ0KPiAgICBiYXNlZCByZXBhaXIgbWV0aG9kcywgZm9yIGV4 YW1wbGUgdGhlIG9uZXMgcmVmZXJyZWQgaW4gUlRQLWJhc2VkDQo+ICAgIFJlZHVuZGFuY3kgKFNl Y3Rpb24gMi4xLjExKS4NCj4gDQo+IEkgdGhpbmsgdGhlIGZvcm11bGF0aW9uIGlzIGxpa2VseSB0 byBhbGxvdyBmb3IgdGhpcyBjYXNlIHdoZW4gb25lIGFwcGxpZXMgYSBGRUMgdHJhbnNmb3JtIHRo YXQgcmVzdWx0cyBpbiBubyBzb3VyY2UgUlRQDQo+IHN0cmVhbSBvbmx5IHJlZHVuZGFuY3kgc3lt Ym9scyB0aGF0IGFyZSBlbmNvZGVkIGludG8gYSBSZWR1bmRhbmN5IFJUUCBzdHJlYW0uDQo+IA0K PiBJbiAyLjEuMTIgdGhlIGltcG9ydGFudCBwYXJ0IGlzOiAuLi4gb25seSByZWR1bmRhbnQgZGF0 YSB0aGF0IG1heSBiZSBjb21iaW5lZCB3aXRoIG9uZSBvciBtb3JlIFJlY2VpdmVkIFJUUCBTdHJl YW0NCj4gKFNlY3Rpb24gMi4xLjE5KSAuLi4NCj4gVGhlICJtYXkiIGhlcmUgYWxsb3dzIHRoZSBj YXNlIGZvciBubyBvdGhlciBzdHJlYW0gdG8gY29tYmluZSBpdCB3aXRoLg0KPiANCj4gSW4gMi4x LjIxIHRoZSB0ZXh0IEkgcmVhY3QgdG8gaXM6ICIuLi4gdGhhdCB0YWtlcyBhcyBpbnB1dCBvbmUg b3IgbW9yZQ0KPiAgICBSZWNlaXZlZCBSVFAgU3RyZWFtcyAoU2VjdGlvbiAyLjEuMTkpIGFuZCBS ZWNlaXZlZCBSZWR1bmRhbmN5IFJUUA0KPiAgICBTdHJlYW1zIChTZWN0aW9uIDIuMS4yMCksIC4u LiINCj4gDQo+IFRoaXMgdGV4dCBpcyBub3Qgc3VwZXIgY2xlYXIgdGhhdCB3aGF0IHdlIGFyZSB0 YWxraW5nIGFib3V0IGFyZSAxKihSZWNldmllZF9SVFBfU3RyZWFtIHwNCj4gUmVjZWl2ZWRfUmVk dW5kYW5jeV9SVFBfU3RyZWFtKQ0KPiANCj4gSXQgaXMgbm90IHRoYXQgdGhlIGNhc2UgZm9yIG5v IHNvdXJjZSBzdHJlYW0gaXMgcnVsZWQgb3V0LCBidXQgaXQgYWxzbyBub3QgY2xlYXIgYW5kIHRo dXMgZWFzaWx5IG1pc3NlZCB0aGF0IHRoaXMgbWF5IG9jY3VyLiBTbw0KPiBlaXRoZXIgc29tZSBp bmZvcm1hdGl2ZSBzZW50ZW5jZSBhYm91dCB0aGlzIGNhc2UsIG9yIG1heWJlIGNsYXJpZnlpbmcg aW4gMi4xLjIxIHRoYXQgaXQgaXMgemVybyBvciBtb3JlIFJlY2VpdmVkIFJUUA0KPiBTdHJlYW1z IGFuZCAxIG9yIG1vcmUgUmVjZWl2ZWQgUmVkdW5kYW5jeSBSVFAgdG8gY3JlYXRlIGEgUmVwYWly ZWQgUlRQIHN0cmVhbS4NCg0KW0JvQl0gU28sIGNvdWxkIHdlIG1ha2UgdGhpcyBtb3JlIGNsZWFy IGJ5IGJlaW5nIGV4cGxpY2l0IGluIDIuMS4yMT8gOg0KICAgUlRQLWJhc2VkIFJlcGFpciBpcyBh IFRyYW5zZm9ybWF0aW9uIHRoYXQgdGFrZXMgYXMgaW5wdXQgemVybyBvciBtb3JlDQogICBSZWNl aXZlZCBSVFAgU3RyZWFtcyAoU2VjdGlvbiAyLjEuMTkpIGFuZCBvbmUgb3IgbW9yZSBSZWNlaXZl ZCBSZWR1bmRhbmN5IFJUUA0KICAgU3RyZWFtcyAoU2VjdGlvbiAyLjEuMjApLi4uDQoNCkluIHRo YXQgY2FzZSwgSSdkIGFsc28gc3VnZ2VzdCB0aGF0IHdlIGFyZSBzaW1pbGFybHkgZXhwbGljaXQg aW4gMi4xLjEyOg0KICAgQSBSVFAgU3RyZWFtIChTZWN0aW9uIDIuMS4xMCkgdGhhdCBjb250YWlu cyBubyBvcmlnaW5hbCBzb3VyY2UgZGF0YSwNCiAgIG9ubHkgcmVkdW5kYW50IGRhdGEsIHdoaWNo IG1heSBlaXRoZXIgYmUgdXNlZCBzdGFuZGFsb25lIG9yIGJlIGNvbWJpbmVkIHdpdGggb25lIG9y IG1vcmUgUmVjZWl2ZWQNCiAgIFJUUCBTdHJlYW1zIChTZWN0aW9uIDIuMS4xOSkgdG8gcHJvZHVj ZSBSZXBhaXJlZCBSVFAgU3RyZWFtcw0KICAgKFNlY3Rpb24gMi4xLjIyKS4NCg0KPiAyLiBGaWd1 cmUgNjoNCj4gDQo+ICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+ICAgICAgIHwgQ29tbXVuaWNhdGlvbiBTZXNzaW9u ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ ICAgICAgIHwgKy0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0t LS0tLS0tLS0tKyB8DQo+ICAgICAgIHwgfCBQYXJ0aWNpcGFudCBBICB8ICAgICstLS0tLS0tLS0t LS0rICAgIHwgUGFydGljaXBhbnQgQiAgfCB8DQo+ICAgICAgIHwgfCAgICAgICAgICAgICAgICB8 ICAgIHwgTXVsdGltZWRpYSB8ICAgIHwgICAgICAgICAgICAgICAgfCB8DQo+ICAgICAgIHwgfCAr LS0tLS0tLS0tLS0tLSt8PD09PnwgU2Vzc2lvbiAgICB8PD09PnwrLS0tLS0tLS0tLS0tLSsgfCB8 DQo+ICAgICAgIHwgfCB8IEVuZHBvaW50IEEgIHx8ICAgIHwgICAgICAgICAgICB8ICAgIHx8IEVu ZHBvaW50IEIgIHwgfCB8DQo+ICAgICAgIHwgfCB8ICAgICAgICAgICAgIHx8ICAgICstLS0tLS0t LS0tLS0rICAgIHx8ICAgICAgICAgICAgIHwgfCB8DQo+ICAgICAgIHwgfCB8ICstLS0tLS0tLS0t LSsrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsrLS0tLS0tLS0tLS0rIHwgfCB8DQo+ICAgICAgIHwg fCB8IHwgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICB8IHwg fCB8DQo+ICAgICAgIHwgfCB8IHwgUlRQIFNlc3Npb258LS0tTWVkaWEgVHJhbnNwb3J0LS0tPnwg ICAgICAgICAgICB8IHwgfCB8DQo+ICAgICAgIHwgfCB8IHwgQXVkaW8gICAgICB8PC0tLU1lZGlh IFRyYW5zcG9ydC0tLXwgICAgICAgICAgICB8IHwgfCB8DQo+ICAgICAgIHwgfCB8IHwgICAgICAg ICAgICB8ICAgICAgICAgIF4gICAgICAgICAgIHwgICAgICAgICAgICB8IHwgfCB8DQo+ICAgICAg IHwgfCB8ICstLS0tLS0tLS0tLSsrLS0tLS0tLS0tLXwtLS0tLS0tLS0tLSsrLS0tLS0tLS0tLS0r IHwgfCB8DQo+ICAgICAgIHwgfCB8ICAgICAgICAgICAgIHx8ICAgICAgICAgIHYgICAgICAgICAg IHx8ICAgICAgICAgICAgIHwgfCB8DQo+ICAgICAgIHwgfCB8ICAgICAgICAgICAgIHx8ICstLS0t LS0tLS0tLS0tLS0tLSsgIHx8ICAgICAgICAgICAgIHwgfCB8DQo+ICAgICAgIHwgfCB8ICAgICAg ICAgICAgIHx8IHwgU3luY2hyb25pemF0aW9uIHwgIHx8ICAgICAgICAgICAgIHwgfCB8DQo+ICAg ICAgIHwgfCB8ICAgICAgICAgICAgIHx8IHwgICAgIENvbnRleHQgICAgIHwgIHx8ICAgICAgICAg ICAgIHwgfCB8DQo+ICAgICAgIHwgfCB8ICAgICAgICAgICAgIHx8ICstLS0tLS0tLS0tLS0tLS0t LSsgIHx8ICAgICAgICAgICAgIHwgfCB8DQo+ICAgICAgIHwgfCB8ICAgICAgICAgICAgIHx8ICAg ICAgICAgIF4gICAgICAgICAgIHx8ICAgICAgICAgICAgIHwgfCB8DQo+ICAgICAgIHwgfCB8ICst LS0tLS0tLS0tLSsrLS0tLS0tLS0tLXwtLS0tLS0tLS0tLSsrLS0tLS0tLS0tLS0rIHwgfCB8DQo+ ICAgICAgIHwgfCB8IHwgICAgICAgICAgICB8ICAgICAgICAgIHYgICAgICAgICAgIHwgICAgICAg ICAgICB8IHwgfCB8DQo+ICAgICAgIHwgfCB8IHwgUlRQIFNlc3Npb258PC0tLU1lZGlhIFRyYW5z cG9ydC0tLXwgICAgICAgICAgICB8IHwgfCB8DQo+ICAgICAgIHwgfCB8IHwgVmlkZW8gICAgICB8 LS0tTWVkaWEgVHJhbnNwb3J0LS0tPnwgICAgICAgICAgICB8IHwgfCB8DQo+ICAgICAgIHwgfCB8 IHwgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICB8IHwgfCB8 DQo+ICAgICAgIHwgfCB8ICstLS0tLS0tLS0tLSsrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsrLS0t LS0tLS0tLS0rIHwgfCB8DQo+ICAgICAgIHwgfCArLS0tLS0tLS0tLS0tLSt8ICAgICAgICAgICAg ICAgICAgICAgIHwrLS0tLS0tLS0tLS0tLSsgfCB8DQo+ICAgICAgIHwgKy0tLS0tLS0tLS0tLS0t LS0rICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tKyB8DQo+ICAgICAgICst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rDQo+IA0KPiBXaGF0IEkgYW0gcmVhY3RpbmcgdG8gaXMgdGhhdCB0aGUgTWVkaWEgVHJhbnNw b3J0cyBhcmUgdGVybWluYXRlZCBhZ2FpbnN0IHRoZSBQYXJ0aWNpcGFudCBsaW5lIHJhdGhlciB0 aGFuIHRoZSBlbmRwb2ludA0KPiBsaW5lLiBJIHdvdWxkIHByZWZlciB0aGF0IHRoZXkgd291bGQg dGVybWluYXRlIGF0IHRoYXQgbGV2ZWwuDQo+IA0KPiBUaGlzIGNvdWxkIGxvb2sgbGlrZSB0aGlz Og0KPiANCj4gICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gICAgICAgfCBDb21tdW5pY2F0aW9uIFNlc3Npb24gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAg ICAgfCArLS0tLS0tLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0t LS0tLS0rIHwNCj4gICAgICAgfCB8IFBhcnRpY2lwYW50IEEgIHwgICAgKy0tLS0tLS0tLS0tLSsg ICAgfCBQYXJ0aWNpcGFudCBCICB8IHwNCj4gICAgICAgfCB8ICAgICAgICAgICAgICAgIHwgICAg fCBNdWx0aW1lZGlhIHwgICAgfCAgICAgICAgICAgICAgICB8IHwNCj4gICAgICAgfCB8ICstLS0t LS0tLS0tLS0tK3w8PT0+fCBTZXNzaW9uICAgIHw8PT0+fCstLS0tLS0tLS0tLS0tKyB8IHwNCj4g ICAgICAgfCB8IHwgRW5kcG9pbnQgQSAgfHwgICAgfCAgICAgICAgICAgIHwgICAgfHwgRW5kcG9p bnQgQiAgfCB8IHwNCj4gICAgICAgfCB8IHwgICAgICAgICAgICAgfHwgICAgKy0tLS0tLS0tLS0t LSsgICAgfHwgICAgICAgICAgICAgfCB8IHwNCj4gICAgICAgfCB8IHwgKy0tLS0tLS0tLS0tKyst LS0tLS0tLS0tLS0tLS0tLS0tLS0tKystLS0tLS0tLS0tLSsgfCB8IHwNCj4gICAgICAgfCB8IHwg fCAgICAgICAgICAgfHwgICAgICAgICAgICAgICAgICAgICAgfHwgICAgICAgICAgIHwgfCB8IHwN Cj4gICAgICAgfCB8IHwgfFJUUCBTZXNzaW9ufC0tLS1NZWRpYSBUcmFuc3BvcnQtLS0tPnwgICAg ICAgICAgIHwgfCB8IHwNCj4gICAgICAgfCB8IHwgfEF1ZGlvICAgICAgfDwtLS1NZWRpYSBUcmFu c3BvcnQtLS0tLXwgICAgICAgICAgIHwgfCB8IHwNCj4gICAgICAgfCB8IHwgfCAgICAgICAgICAg fHwgICAgICAgICAgXiAgICAgICAgICAgfHwgICAgICAgICAgIHwgfCB8IHwNCj4gICAgICAgfCB8 IHwgKy0tLS0tLS0tLS0tKystLS0tLS0tLS0tfC0tLS0tLS0tLS0tKystLS0tLS0tLS0tLSsgfCB8 IHwNCj4gICAgICAgfCB8IHwgICAgICAgICAgICAgfHwgICAgICAgICAgdiAgICAgICAgICAgfHwg ICAgICAgICAgICAgfCB8IHwNCj4gICAgICAgfCB8IHwgICAgICAgICAgICAgfHwgKy0tLS0tLS0t LS0tLS0tLS0tKyAgfHwgICAgICAgICAgICAgfCB8IHwNCj4gICAgICAgfCB8IHwgICAgICAgICAg ICAgfHwgfCBTeW5jaHJvbml6YXRpb24gfCAgfHwgICAgICAgICAgICAgfCB8IHwNCj4gICAgICAg fCB8IHwgICAgICAgICAgICAgfHwgfCAgICAgQ29udGV4dCAgICAgfCAgfHwgICAgICAgICAgICAg fCB8IHwNCj4gICAgICAgfCB8IHwgICAgICAgICAgICAgfHwgKy0tLS0tLS0tLS0tLS0tLS0tKyAg fHwgICAgICAgICAgICAgfCB8IHwNCj4gICAgICAgfCB8IHwgICAgICAgICAgICAgfHwgICAgICAg ICAgXiAgICAgICAgICAgfHwgICAgICAgICAgICAgfCB8IHwNCj4gICAgICAgfCB8IHwgKy0tLS0t LS0tLS0tKystLS0tLS0tLS0tfC0tLS0tLS0tLS0tKystLS0tLS0tLS0tLSsgfCB8IHwNCj4gICAg ICAgfCB8IHwgfCAgICAgICAgICAgfHwgICAgICAgICAgdiAgICAgICAgICAgfHwgICAgICAgICAg IHwgfCB8IHwNCj4gICAgICAgfCB8IHwgfFJUUCBTZXNzaW9ufDwtLS1NZWRpYSBUcmFuc3BvcnQt LS0tLXwgICAgICAgICAgIHwgfCB8IHwNCj4gICAgICAgfCB8IHwgfFZpZGVvICAgICAgfC0tLS1N ZWRpYSBUcmFuc3BvcnQtLS0tPnwgICAgICAgICAgIHwgfCB8IHwNCj4gICAgICAgfCB8IHwgfCAg ICAgICAgICAgfHwgICAgICAgICAgICAgICAgICAgICAgfHwgICAgICAgICAgIHwgfCB8IHwNCj4g ICAgICAgfCB8IHwgKy0tLS0tLS0tLS0tKystLS0tLS0tLS0tLS0tLS0tLS0tLS0tKystLS0tLS0t LS0tLSsgfCB8IHwNCj4gICAgICAgfCB8ICstLS0tLS0tLS0tLS0tK3wgICAgICAgICAgICAgICAg ICAgICAgfCstLS0tLS0tLS0tLS0tKyB8IHwNCj4gICAgICAgfCArLS0tLS0tLS0tLS0tLS0tLSsg ICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0rIHwNCj4gICAgICAgKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsN CltCb0JdIEkgaGF2ZSBubyBvYmplY3Rpb25zIHRvIG1ha2luZyB0aGF0IGNoYW5nZS4gDQoNCj4g DQo+IDMuIFNlY3Rpb24gMi4yLjENCj4gDQo+ICAgIG8gIEFuIEVuZHBvaW50IGNhbiBiZSBhc3Nv Y2lhdGVkIHdpdGggYXQgbW9zdCBvbmUgUGFydGljaXBhbnQNCj4gICAgICAgKFNlY3Rpb24gMi4y LjMpIGF0IGFueSBzaW5nbGUgcG9pbnQgaW4gdGltZS4NCj4gDQo+ICAgIG8gIEluIHNvbWUgY29u dGV4dHMsIGFuIEVuZHBvaW50IHdvdWxkIHR5cGljYWxseSBjb3JyZXNwb25kIHRvIGENCj4gICAg ICAgc2luZ2xlICJob3N0IiwgZm9yIGV4YW1wbGUgYSBjb21wdXRlciB1c2luZyBhIHNpbmdsZSBu ZXR3b3JrDQo+ICAgICAgIGludGVyZmFjZSBhbmQgYmVpbmcgdXNlZCBieSBhIHNpbmdsZSBodW1h biB1c2VyLg0KPiANCj4gSSB0aGluayB3ZSBtaWdodCBuZWVkIHRvIGNsYXJpZnkgaG93IG9uZSBz aG91bGQgY29uc2lkZXIgZW5kcG9pbnRzIGluIHRoZSBmb2xsb3dpbmcgc2NlbmFyaW8uDQo+IA0K PiBBIG11bHRpLXVzZXIgaG9zdCwgd2hlcmUgdHdvIHBhcnRpY2lwYW50cyBhcmUgY29tbXVuaWNh dGluZyB3aXRoIGVhY2ggb3RoZXIgdXNpbmcgVC4xNDAgdGV4dCAoVG8gYXZvaWQgaS9vIGlzc3Vl cyBvZg0KPiBtdWx0aS11c2VyIGVudmlyb25tZW50cykuDQo+IFRoZSBmaXJzdCBidWxsZXQgYWJv dmUgcmVxdWlyZXMgdGhlbiB0aGlzIGhvc3QgdHdvIGhhdmUgdHdvIGVuZHBvaW50cy4gSSB0aGlu ayB0aGUgY3VycmVudCBpbnR1aXRpdmUgZmVlbGluZyBmb3IgZW5kcG9pbnQgaXMNCj4gdGhhdCBp cyBpdCBjYW4gYmUgaWRlbnRpZmllZCBieSBhbiBuZXR3b3JrIGFkZHJlc3MuIEhvd2V2ZXIsIGlm IHRoZSBhYm92ZSBjYXNlIGFyZSB0d28gZW5kcG9pbnRzIHRoZXkgbWF5IGFjdHVhbGx5IGhhdmUN Cj4gdGhlIHNhbWUgbmV0d29yayBhZGRyZXNzLg0KPiANCj4gSSBiZWxpZXZlIHRoZSBtb3N0IHNp bXBsZSBzb2x1dGlvbiBnb2luZyBmb3J3YXJkIHdvdWxkIGJlIHRvIG1ha2UgaXQgY2xlYXIgdGhh dCBpbiBzb21lIGNhc2VzIHRoZXJlIGJlIG11bHRpcGxlDQo+IGVuZHBvaW50cyBhdCBhIHNpbmds ZSBob3N0LiBJIHdvdWxkIHByb3Bvc2UgdG8gYWRkIHRvIHRoZSBzZWNvbmQgYnVsbGV0IGFib3Zl IHRoZSBmb2xsb3dpbmc6DQo+IA0KPiAgICAgSW4gb3RoZXIgY29udGV4dHMsIGEgc2luZ2xlICdo b3N0JyBjYW4gc2VydmUgbXVsdGlwbGUgUGFydGljaXBhbnRzLA0KPiAgICAgaW4gd2hpY2ggY2Fz ZSBlYWNoIFBhcnRpY2lwYW50J3MgRW5kcG9pbnQgbWF5IHNoYXJlIHByb3BlcnRpZXMsIGZvcg0K PiAgICAgZXhhbXBsZSB0aGUgSVAgYWRkcmVzcyBwYXJ0IG9mIGEgdHJhbnNwb3J0IGFkZHJlc3Mu DQpbQm9CXSBMb29rcyBnb29kIHRvIG1lIChhZGRpbmcgYSBzZWVtaW5nbHkgbWlzc2luZyAiZXhh bXBsZSIgYXMgZmlyc3Qgd29yZCBvbiBsYXN0IGxpbmUgb2YgdGhlIHByb3Bvc2VkIHRleHQpDQoN Cj4gDQo+IA0KPiA0LiBzZWN0aW9uIDMuNToNCj4gDQo+ICAgIDIuICBJbiBNdWx0aS1TZXNzaW9u IFRyYW5zbWlzc2lvbiAoTVNUKSwgdGhlIFNWQyBNZWRpYSBFbmNvZGVyIHNlbmRzDQo+ICAgICAg ICBFbmNvZGVkIFN0cmVhbXMgYW5kIERlcGVuZGVudCBTdHJlYW1zIGRpc3RyaWJ1dGVkIGFjcm9z cyBtdWx0aXBsZQ0KPiAgICAgICAgUlRQIFN0cmVhbXMgaW4gb25lIG9yIG1vcmUgUlRQIFNlc3Np b25zLg0KPiANCj4gYW5kDQo+IA0KPiAgICBNU1QgZGVub3RlcyBvbmUgb3IgbW9yZSBSVFAgU3Ry ZWFtcyAoU1NSQykgcGVyIE1lZGlhIFNvdXJjZQ0KPiAgICBpbiBlYWNoIG9mIG11bHRpcGxlIFJU UCBTZXNzaW9ucy4NCj4gDQo+IElzIHRoZXNlIHR3byBzZW50ZW5jZSByZWFsbHkgY29uc2lzdGVu dC4gSXQgaXMgbGVzcyB0aGFuIGNsZWFyIHRoYXQgIm11bHRpcGxlIiBpcyBlcXVpdmFsZW50IHRv ICJvbmUgb3IgbW9yZSIuDQpbQm9CXSBJIHRoaW5rIGF0IGxlYXN0IHRoZSBmaXJzdCBzZW50ZW5j ZSBpcyBjbGVhciwgYnV0IEkgZG9uJ3QgdGhpbmsgIm11bHRpcGxlIiBzaG91bGQgYmUgcmVhZCBh cyAib25lIG9yIG1vcmUiLCByYXRoZXIgInR3byBvciBtb3JlIi4gVGhlIHNlY29uZCBzZW50ZW5j ZSBpcyBsZXNzIGNsZWFyLCBpbiB0aGF0IGl0IHNlZW1zIHRvIGFjdHVhbGx5IHJlcXVpcmUgdHdv IG9yIG1vcmUgUlRQIFNlc3Npb25zIChzdGlsbCBhc3N1bWluZyB0aGF0ICJtdWx0aXBsZSIgaXMg bm90ICJvbmUgb3IgbW9yZSIgYnV0IHJhdGhlciAidHdvIG9yIG1vcmUiKS4gVGhhdCBzaW5nbGUs IHNob3J0IHNlbnRlbmNlIHNlZW1pbmdseSB0cmllcyB0byBjb3ZlciB0d28gY2FzZXMgKGJvdGgg cGVyIE1lZGlhIFNvdXJjZSk6IDEpIFR3byBvciBtb3JlIFJUUCBTdHJlYW1zIGluIG9uZSBvciBt b3JlIFJUUCBTZXNzaW9ucywgYW5kIDIpIE9uZSBvciBtb3JlIFJUUCBTdHJlYW1zIGluIGVhY2gg b2YgdHdvIG9yIG1vcmUgUlRQIFNlc3Npb25zLiBJIHN1Z2dlc3QgdG8gbWFrZSB0aG9zZSBjbGFy aWZpY2F0aW9ucywgdXNpbmcgIm9uZSBvciBtb3JlIiBhbmQgInR3byBvciBtb3JlIiB3b3JkaW5n cyBpbnN0ZWFkIG9mICJtdWx0aXBsZSIuDQoNCj4gDQo+IA0KPiA1LiBzZWN0aW9uIDMuNToNCj4g DQo+IEkgd29uZGVyIGlmIHdlIHNob3VsZCBhdCB0aGlzIHN0YWdlIGNyZWF0ZSBhIHNwZWNpYWwg dmVyc2lvbiBvZiBNUk1UIHdoaWNoIGhhcyBvbmUgYW5kIG9ubHkgb25lIFJUUCBzdHJlYW0gcGVy IE1lZGlhDQo+IFNvdXJjZSBhbmQgbWVkaWEgdHJhbnNwb3J0PyBUaGUgcmVhc29uIGZvciBzdWNo IGEgb25lIGlzIGV4YWN0bHkgdGhlIGRpc2N1c3Npb24gaGVsZCBpbiBTZWN0aW9uIDMuOCBhYm91 dCB1c2luZyB0aGUgc2FtZQ0KPiBTU1JDIHZhbHVlIGluIG11bHRpcGxlIFJUUCBzZXNzaW9ucy4N CltCb0JdIEkgZG9uJ3Qgc2VlIGFueSBzdHJvbmcgbmVlZCB0byBpbnRyb2R1Y2UgYW55IG5ldyBh Y3JvbnltIGZvciB0aGlzLCBidXQgZW5jb3VyYWdlIG90aGVycyB0byBjb21tZW50Lg0KDQo+IA0K PiA2LiBTZWN0aW9uIDMuNzoNCj4gDQo+IEFzIE1EQyBpcyB1c2VkIGluIHRocmVlIHBsYWNlcyBv bmx5LCBJIHRoaW5rIGEgcmVmZXJlbmNlIGlzIG5lZWRlZCBmb3IgdGhlIG9jY3VycmVuY2UgaGVy ZSBpbiBTZWN0aW9uIDMuNyBiYWNrIHRvIFNlY3Rpb24NCj4gMi4xLjYuDQpbQm9CXSBJIGhhdmUg bm8gcHJvYmxlbXMgYWRkaW5nIGEgcmVmZXJlbmNlIGJhY2sgdG8gMi4xLjYuDQoNCj4gDQo+IA0K PiBJIHdpbGwgYmUgYXdheSBuZXh0IHdlZWssIHNvIEkgd2lsbCBmb2xsb3cgdXAgb24gdGhpcyBh ZnRlciB0aGUgOHRoIG9mIEZlYnJ1YXJ5Lg0KPiANCj4gQ2hlZXJzDQo+IA0KPiBNYWdudXMgV2Vz dGVybHVuZA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBTZXJ2aWNlcywgTWVkaWEgYW5kIE5ldHdv cmsgZmVhdHVyZXMsIEVyaWNzc29uIFJlc2VhcmNoIEVBQi9UWE0NCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiBFcmljc3NvbiBBQiAgICAgICAgICAgICAgICAgfCBQaG9uZSAgKzQ2IDEwIDcxNDgyODcNCj4g RsOkcsO2Z2F0YW4gNiAgICAgICAgICAgICAgICAgfCBNb2JpbGUgKzQ2IDczIDA5NDkwNzkNCj4g U0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVuIHwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBl cmljc3Nvbi5jb20NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gYXZ0ZXh0IG1haWxpbmcgbGlzdA0KPiBhdnRl eHRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnRl eHQNCg== From nobody Mon Feb 9 06:05:11 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE391A00A2 for ; Mon, 9 Feb 2015 06:04:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 BcKU0DBaEWht for ; Mon, 9 Feb 2015 06:04:27 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 442B51A040B for ; Mon, 9 Feb 2015 06:04:04 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-c4-54d8be51ec8b Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A7.2A.04484.15EB8D45; Mon, 9 Feb 2015 15:04:01 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.174]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0210.002; Mon, 9 Feb 2015 15:04:00 +0100 From: Bo Burman To: "avtext@ietf.org" Thread-Topic: Retransmission rules for RESUME in draft-ietf-avtext-rtp-stream-pause-05 Thread-Index: AdA2ImIR23jMWYBTRr2V5a7v5w6LQwOToTWw Date: Mon, 9 Feb 2015 14:04:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22E48CC85ESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM+JvjW7gvhshBrdvWVp8vHeD1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGSsmXWYt+G5U0TD3EmsDY4dOFyMnh4SAicTmN39ZIWwxiQv3 1rN1MXJxCAkcYZRYvPY0K4SzmFFi88brTCBVbAIaEvN33GUEsUUE1CXuTL/ABmILC4RLnJx6 ngUiHiFxt7efDcI2kphw8SbYBhYBFYmtLyeC9fIK+EqsWn4ErEYIyL788B87iM0p4CfRP/E6 WA2jgKzE/e/3wGYyC4hL3HoynwniUgGJJXvOM0PYohIvH/+D+kBJ4seGS1D1+RIbr8xlg9gl KHFy5hOWCYwis5CMmoWkbBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KUbQ4tTgp N93ISC+1KDO5uDg/Ty8vtWQTIzCKDm75bbCD8eVzx0OMAhyMSjy8G5RuhAixJpYVV+YeYpTm YFES57UzPhQiJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdFOI0X5u36jkIjjzTwpv2tLpUtn FFyLmO0S6LktZkXiNdHYFR32vsqGJ28Ix/t3R7GYf9b6/X7vpg0p0x/Pu5Vg4SFjbddRYq6l n35qtV/5pe+KnVt6rv5oXlS9yWn3vj/O244mNdjzLl2q7h4+q6nlHkNC1aLSSZM+K530C5+h vLF++ebEdiWW4oxEQy3mouJEAClBwuiDAgAA Archived-At: Subject: Re: [avtext] Retransmission rules for RESUME in draft-ietf-avtext-rtp-stream-pause-05 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 14:04:35 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22E48CC85ESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I did not see any objections to this proposal, and assuming this means it i= s acceptable, I will make these clarifications in the next version of the d= ocument. Cheers, Bo From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Bo Burman Sent: den 22 januari 2015 10:22 To: avtext@ietf.org Subject: [avtext] Retransmission rules for RESUME in draft-ietf-avtext-rtp-= stream-pause-05 While adding text on retransmission of PAUSED ("to increase the probability= that the message reaches the receiver in a timely fashion") into the Messa= ge Details section, according to comments received at AVTEXT session in Hon= olulu, I realize it would probably be appropriate to have similar text also= for RESUME. There is already text saying that RESUME can be time critical,= but there is no specific text mentioning that retransmission can be used t= o handle possible loss. For PAUSED, there is no obvious trigger when to stop sending the message as= long as the pause condition remains. As commented in Honolulu, I thus adde= d text that while the pause condition remains, PAUSED MAY be sent in every = compound RTCP, as long as the negotiated RTCP bandwidth is not exceeded. For RESUME, there are clear triggers when to stop any retransmissions: when= receiving RTP packets from the targeted stream, or when a REFUSED with a v= alid PauseID for the targeted RTP stream is received, and I suggest clearly= stating that too. Comments? Cheers, Bo --_000_BBE9739C2C302046BD34B42713A1E2A22E48CC85ESESSMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I did not see any obje= ctions to this proposal, and assuming this means it is acceptable, I will m= ake these clarifications in the next version of the document.

 

Cheers,

Bo

 

From: avtext [= mailto:avtext-bounces@ietf.org] On Behalf Of Bo Burman
Sent: den 22 januari 2015 10:22
To: avtext@ietf.org
Subject: [avtext] Retransmission rules for RESUME in draft-ietf-avte= xt-rtp-stream-pause-05

 

While adding text on retransmission of PAUSED (̶= 0;to increase the probability that the message reaches the receiver in a ti= mely fashion”) into the Message Details section, according to comment= s received at AVTEXT session in Honolulu, I realize it would probably be appropriate to have similar text also for RESUME. The= re is already text saying that RESUME can be time critical, but there is no= specific text mentioning that retransmission can be used to handle possibl= e loss.

 

For PAUSED, there is no obvious trigger when to stop= sending the message as long as the pause condition remains. As commented i= n Honolulu, I thus added text that while the pause condition remains, PAUSE= D MAY be sent in every compound RTCP, as long as the negotiated RTCP bandwidth is not exceeded.

 

For RESUME, there are clear triggers when to stop an= y retransmissions: when receiving RTP packets from the targeted stream, or = when a REFUSED with a valid PauseID for the targeted RTP stream is received= , and I suggest clearly stating that too.

 

Comments?

 

Cheers,

Bo

 

--_000_BBE9739C2C302046BD34B42713A1E2A22E48CC85ESESSMB105erics_-- From nobody Mon Feb 9 07:52:15 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED021A1A62 for ; Mon, 9 Feb 2015 07:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 6zkiB41dBppB for ; Mon, 9 Feb 2015 07:49:13 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F9501A1A27 for ; Mon, 9 Feb 2015 07:49:13 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-92-54d8d6f72618 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 31.02.04231.7F6D8D45; Mon, 9 Feb 2015 16:49:11 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.210.2; Mon, 9 Feb 2015 16:49:10 +0100 Message-ID: <54D8D6F6.4070104@ericsson.com> Date: Mon, 9 Feb 2015 16:49:10 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Bo Burman , "avtext@ietf.org" References: <54CBA5AF.7040006@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjluLIzCtJLcpLzFFi42KZGfG3Rvf7tRshBrNmqVp8vHeD1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGXMO9bAUPDStuHSwh72BcbVWFyMnh4SAicTT342sELaYxIV7 69m6GLk4hASOMEoser+OBcJZxihxctNEFpAqXgFtie+bPzCB2CwCKhI7Js8Cs9kELCRu/mhk A7FFBYIlFj9/ygpRLyhxcuYTsF4RAW+Je3PfMoLYwgI+Ent33mIHsYUEciWO3d0DZnMK+EnM vHYZqIaDg1lAU2L9Ln2QMLOAvETz1tnMEOXaEg1NHawTGAVmIdkwC6FjFpKOBYzMqxhFi1OL i3PTjYz1Uosyk4uL8/P08lJLNjECA/Dglt+6OxhXv3Y8xCjAwajEw7tB6UaIEGtiWXFl7iFG aQ4WJXFeO+NDIUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY1WX54iyVn+5mZ3SPT8ze86Fb 44KDdeq3sOsvxXZyrlORWxF3vHzOpR9cv1TTXE48VVDt4tD/f0HQtrsrY9/9zrZczTNsPDPP rw8+0Ol580jQbhcNFQvf5ea+pk9OHri/ct12sWIJVcHgvy9dtkY1/VNruP5v+3dvfZGIqakX 5B4lzAwLZdBSYinOSDTUYi4qTgQAp1V9fCECAAA= Archived-At: Subject: Re: [avtext] Comments on draft-ietf-avtext-rtp-grouping-taxonomy-05 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 15:49:16 -0000 Hi, Please see inline for responses. On 2015-02-09 12:33, Bo Burman wrote: > My views, inline below. /Bo > >> -----Original Message----- >> From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Magnus Westerlund >> Sent: den 30 januari 2015 16:39 >> To: avtext@ietf.org >> Subject: [avtext] Comments on draft-ietf-avtext-rtp-grouping-taxonomy-05 >> >> Hi, >> >> I have just reviewed draft-ietf-avtext-rtp-grouping-taxonomy-05 and think it is in good shape. However, I do have some >> few comments and reflections for the WG to consider. >> >> 1. The case when there are no source RTP stream, only redundancy RTP streams. This relates to two different sections: >> >> 2.1.12. Redundancy RTP Stream >> >> A RTP Stream (Section 2.1.10) that contains no original source data, >> only redundant data that may be combined with one or more Received >> RTP Stream (Section 2.1.19) to produce Repaired RTP Streams >> (Section 2.1.22). >> >> 2.1.21. RTP-based Repair >> >> RTP-based Repair is a Transformation that takes as input one or more >> Received RTP Streams (Section 2.1.19) and Received Redundancy RTP >> Streams (Section 2.1.20), and produces one or more Repaired RTP >> Streams (Section 2.1.22) that are as close to the corresponding sent >> Source RTP Streams (Section 2.1.10) as possible, using different RTP- >> based repair methods, for example the ones referred in RTP-based >> Redundancy (Section 2.1.11). >> >> I think the formulation is likely to allow for this case when one applies a FEC transform that results in no source RTP >> stream only redundancy symbols that are encoded into a Redundancy RTP stream. >> >> In 2.1.12 the important part is: ... only redundant data that may be combined with one or more Received RTP Stream >> (Section 2.1.19) ... >> The "may" here allows the case for no other stream to combine it with. >> >> In 2.1.21 the text I react to is: "... that takes as input one or more >> Received RTP Streams (Section 2.1.19) and Received Redundancy RTP >> Streams (Section 2.1.20), ..." >> >> This text is not super clear that what we are talking about are 1*(Recevied_RTP_Stream | >> Received_Redundancy_RTP_Stream) >> >> It is not that the case for no source stream is ruled out, but it also not clear and thus easily missed that this may occur. So >> either some informative sentence about this case, or maybe clarifying in 2.1.21 that it is zero or more Received RTP >> Streams and 1 or more Received Redundancy RTP to create a Repaired RTP stream. > > [BoB] So, could we make this more clear by being explicit in 2.1.21? : > RTP-based Repair is a Transformation that takes as input zero or more > Received RTP Streams (Section 2.1.19) and one or more Received Redundancy RTP > Streams (Section 2.1.20)... Sounds good! > > In that case, I'd also suggest that we are similarly explicit in 2.1.12: > A RTP Stream (Section 2.1.10) that contains no original source data, > only redundant data, which may either be used standalone or be combined with one or more Received > RTP Streams (Section 2.1.19) to produce Repaired RTP Streams > (Section 2.1.22). > Yes, that would work. > >> >> 3. Section 2.2.1 >> >> o An Endpoint can be associated with at most one Participant >> (Section 2.2.3) at any single point in time. >> >> o In some contexts, an Endpoint would typically correspond to a >> single "host", for example a computer using a single network >> interface and being used by a single human user. >> >> I think we might need to clarify how one should consider endpoints in the following scenario. >> >> A multi-user host, where two participants are communicating with each other using T.140 text (To avoid i/o issues of >> multi-user environments). >> The first bullet above requires then this host two have two endpoints. I think the current intuitive feeling for endpoint is >> that is it can be identified by an network address. However, if the above case are two endpoints they may actually have >> the same network address. >> >> I believe the most simple solution going forward would be to make it clear that in some cases there be multiple >> endpoints at a single host. I would propose to add to the second bullet above the following: >> >> In other contexts, a single 'host' can serve multiple Participants, >> in which case each Participant's Endpoint may share properties, for >> example the IP address part of a transport address. > > [BoB] Looks good to me (adding a seemingly missing "example" as first word on last line of the proposed text) > Good! >> >> >> 4. section 3.5: >> >> 2. In Multi-Session Transmission (MST), the SVC Media Encoder sends >> Encoded Streams and Dependent Streams distributed across multiple >> RTP Streams in one or more RTP Sessions. >> >> and >> >> MST denotes one or more RTP Streams (SSRC) per Media Source >> in each of multiple RTP Sessions. >> >> Is these two sentence really consistent. It is less than clear that "multiple" is equivalent to "one or more". > > [BoB] I think at least the first sentence is clear, but I don't > think "multiple" should be read as "one or more", rather "two or more". The > second sentence is less clear, in that it seems to actually require two > or more RTP Sessions (still assuming that "multiple" is not "one or > more" but rather "two or more"). That single, short sentence seemingly > tries to cover two cases (both per Media Source): 1) Two or more RTP > Streams in one or more RTP Sessions, and 2) One or more RTP Streams in > each of two or more RTP Sessions. I suggest to make those > clarifications, using "one or more" and "two or more" wordings instead > of "multiple". Sounds okay to me. > >> >> >> 5. section 3.5: >> >> I wonder if we should at this stage create a special version of MRMT which has one and only one RTP stream per Media >> Source and media transport? The reason for such a one is exactly the discussion held in Section 3.8 about using the same >> SSRC value in multiple RTP sessions. > [BoB] I don't see any strong need to introduce any new acronym for this, but encourage others to comment. > Yes, please provide input into this question. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Feb 11 05:28:30 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E508D1A020B; Wed, 11 Feb 2015 05:28:23 -0800 (PST) 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] autolearn=ham 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 KaIDQm9F99Pm; Wed, 11 Feb 2015 05:28:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7051A889A; Wed, 11 Feb 2015 05:28:21 -0800 (PST) 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: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150211132821.13453.55796.idtracker@ietfa.amsl.com> Date: Wed, 11 Feb 2015 05:28:21 -0800 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-stream-pause-06.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 13:28:24 -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 Extensions Working Group of the IETF. Title : RTP Stream Pause and Resume Authors : Bo Burman Azam Akram Roni Even Magnus Westerlund Filename : draft-ietf-avtext-rtp-stream-pause-06.txt Pages : 51 Date : 2015-02-11 Abstract: With the increased popularity of real-time multimedia applications, it is desirable to provide good control of resource usage, and users also demand more control over communication sessions. This document describes how a receiver in a multimedia conversation can pause and resume incoming data from a sender by sending real-time feedback messages when using Real-time Transport Protocol (RTP) for real time data transport. This document extends the Codec Control Messages (CCM) RTCP feedback package by explicitly allowing and describing specific use of existing CCM messages and adding a group of new real- time feedback messages used to pause and resume RTP data streams. This document updates RFC 5104. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtext-rtp-stream-pause-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rtp-stream-pause-06 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 Wed Feb 11 05:53:39 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDA81A8889 for ; Wed, 11 Feb 2015 05:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 Wxv-IbWPX-3Y for ; Wed, 11 Feb 2015 05:53:36 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FA241A8886 for ; Wed, 11 Feb 2015 05:53:35 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-39-54db5ede3303 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 35.3F.04231.EDE5BD45; Wed, 11 Feb 2015 14:53:34 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.174]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0210.002; Wed, 11 Feb 2015 14:53:33 +0100 From: Bo Burman To: "avtext@ietf.org" Thread-Topic: I-D Action: draft-ietf-avtext-rtp-stream-pause-06.txt Thread-Index: AQHQRf6muGDNJRu1ckS2NPKsEfKkGpzrdqZQ Date: Wed, 11 Feb 2015 13:53:33 +0000 Message-ID: References: <20150211132821.13453.55796.idtracker@ietfa.amsl.com> In-Reply-To: <20150211132821.13453.55796.idtracker@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvje69uNshBqfWK1p8vHeD1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGctObWIrWCZf0b6kk7GBsVuii5GTQ0LAROLy1L+MELaYxIV7 69m6GLk4hASOMEoc3zCZBcJZwiixcs0hNpAqNgENifk77oJ1iAioS9yZfgEsLizgJNE2cSEz RNxZYvOBPewQtpHEqY6TTCA2i4CqxNP+SWD1vAK+Ek++n2IBsYUEHCVez+8H6+UEmtP5+SlY PaOArMT97/fAapgFxCVuPZnPBHGpgMSSPeeZIWxRiZeP/7FC2IoSV6cvZ4Ko15FYsPsTG4St LbFs4WtmiL2CEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypG0eLU4uLcdCNjvdSizOTi4vw8 vbzUkk2MwKg4uOW37g7G1a8dDzEKcDAq8fBuOHorRIg1say4MvcQozQHi5I4r53xoRAhgfTE ktTs1NSC1KL4otKc1OJDjEwcnFINjEV+n7gt1767LMgtyGVytGtPvsqXY4+L9mspBTFNFYtd ybJumsqXK3evvbl/7ZrA/k7FfZdnLthT9S5JMKOD6XDML0Vel1NJ3t84r5vHd+95+mf7gb0R AceLv39+dkDe5+QyC+E3ulUqM+utDQN+fdXdO8XRo+2UVzSvfsCV34vDgjW/LtuWxaXEUpyR aKjFXFScCADrnYpSawIAAA== Archived-At: Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rtp-stream-pause-06.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 13:53:38 -0000 This version should address all comments received during IETF 91, and also = includes a few sentences on RESUME retransmission, as suggested on the list= . Summary of changes, for your convenience (also in document): o Clarified in Message Details section for PAUSED that retransmission of the message can be used to increase the probability that the message reaches the receiver in a timely fashion, and also added text that says the number of repetitions can be tuned to observed loss rate and the desired loss probability. Also removed Editor's notes on potential ACK for unsolicited PAUSED, since the issue is solved by the above. o In the same section as above, added that PAUSED may be included in all compound RTCP reports, as long as the negotiated RTCP bandwidth is not exceeded. o In Message Details section for RESUME, added text on retransmission similar to the one mentioned for PAUSED above. Also included text that says such retransmission SHOULD stop as soon as RTP packets or a REFUSED with a valid PauseID from the targeted stream are received. o Changed simulcast reference, since that draft was moved from AVTCORE to MMUSIC and made WG draft. o Changed End Point to Endpoint to reflect change in RTP Grouping Taxonomy draft. o Editorial improvements. Cheers, Bo > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of in= ternet-drafts@ietf.org > Sent: den 11 februari 2015 14:28 > To: i-d-announce@ietf.org > Cc: avtext@ietf.org > Subject: I-D Action: draft-ietf-avtext-rtp-stream-pause-06.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Audio/Video Transport Extensions Workin= g Group of the IETF. >=20 > Title : RTP Stream Pause and Resume > Authors : Bo Burman > Azam Akram > Roni Even > Magnus Westerlund > Filename : draft-ietf-avtext-rtp-stream-pause-06.txt > Pages : 51 > Date : 2015-02-11 >=20 > Abstract: > With the increased popularity of real-time multimedia applications, > it is desirable to provide good control of resource usage, and users > also demand more control over communication sessions. This document > describes how a receiver in a multimedia conversation can pause and > resume incoming data from a sender by sending real-time feedback > messages when using Real-time Transport Protocol (RTP) for real time > data transport. This document extends the Codec Control Messages > (CCM) RTCP feedback package by explicitly allowing and describing > specific use of existing CCM messages and adding a group of new real- > time feedback messages used to pause and resume RTP data streams. > This document updates RFC 5104. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtext-rtp-stream-pause-06 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-rtp-stream-pause-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are > available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.= ietf.org/ietf/1shadow-sites.txt From nobody Fri Feb 20 00:14:23 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C661A7025 for ; Fri, 20 Feb 2015 00:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 FflemH4ql0ix for ; Fri, 20 Feb 2015 00:14:19 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE06E1A7021 for ; Fri, 20 Feb 2015 00:14:18 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-91-54e6ecd86c42 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 7A.14.04076.8DCE6E45; Fri, 20 Feb 2015 09:14:16 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.118]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0210.002; Fri, 20 Feb 2015 09:14:15 +0100 From: Bo Burman To: "avtext@ietf.org" Thread-Topic: [avtext] Comments on draft-ietf-avtext-rtp-grouping-taxonomy-05 Thread-Index: AQHQPKL0EJzOHIEyRk2CgKznnjEnWZzoGHXAgABdZACAENoP4A== Date: Fri, 20 Feb 2015 08:14:15 +0000 Message-ID: References: <54CBA5AF.7040006@ericsson.com> <54D8D6F6.4070104@ericsson.com> In-Reply-To: <54D8D6F6.4070104@ericsson.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje6NN89CDM6sk7P4eO8GqwOjx5Il P5kCGKO4bFJSczLLUov07RK4MrY1/WcvmMdfsaPzMmMD4xu+LkZODgkBE4ntr1sYIWwxiQv3 1rN1MXJxCAkcYZR4+PgRO4SzhFHiyPJmdpAqNgENifk77oJ1iAioS9yZfoENxBYW8JFo2DyF GSLuK9G1eBOU7SRx8P1MsF4WAVWJK0cmgsV5gWqaW7czQSyYyCjRO7UBrIhTQEfi9P81YEMZ BWQl7n+/xwJiMwuIS9x6Mp8J4lQBiSV7zjND2KISLx//Y+1i5ACyFSWW98uBmMwCmhLrd+lD dCpKTOl+yA6xVlDi5MwnLBMYRWchGToLoWMWko5ZSDoWMLKsYhQtTi0uzk03MtJLLcpMLi7O z9PLSy3ZxAiMiINbflvtYDz43PEQowAHoxIPr8HiZyFCrIllxZW5hxilOViUxHntjA+FCAmk J5akZqemFqQWxReV5qQWH2Jk4uCUamD03Pa8Z8ZTae/kmf/cZsT/2aoWbs5kE3P0wZkni/c9 XxewJG2Zs+yL9utPZr04pbPnm8K030zf1CfFtMyV5n+8an1ERfrOu26nTcRdF9y6G+2evqPC 6CUb8/IUC+8I/75k122eEnuezPM+u2zmyXWqvWvXBLBsNrAzKza89zh4PuO/8oTd2fOYlViK MxINtZiLihMB59J1GGkCAAA= Archived-At: Subject: Re: [avtext] Comments on draft-ietf-avtext-rtp-grouping-taxonomy-05 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 08:14:20 -0000 V0csIEkgYW0gYWJvdXQgdG8gbWFrZSBhIC0wNiB2ZXJzaW9uIHRha2luZyBNYWdudXMnIGNvbW1l bnRzIGludG8gYWNjb3VudCwgYW5kIHdvdWxkIGxpa2UgeW91ciBndWlkYW5jZSBvbiBob3cgdG8g cHJvY2VlZCB3aXRoIE1hZ251cycgcXVlc3Rpb24gYmVsb3cgKGluY2x1ZGVkIG1haWwgc2hvcnRl bmVkKS4NCg0KQ2hlZXJzLA0KQm8NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBNYWdudXMgV2VzdGVybHVuZA0KPiBTZW50OiBkZW4gOSBmZWJydWFyaSAyMDE1IDE2OjQ5 DQo+IFRvOiBCbyBCdXJtYW47IGF2dGV4dEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2F2dGV4 dF0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1hdnRleHQtcnRwLWdyb3VwaW5nLXRheG9ub215LTA1 DQo+IA0KIDxzbmlwPg0KPiA+PiA1LiBzZWN0aW9uIDMuNToNCj4gPj4NCj4gPj4gSSB3b25kZXIg aWYgd2Ugc2hvdWxkIGF0IHRoaXMgc3RhZ2UgY3JlYXRlIGEgc3BlY2lhbCB2ZXJzaW9uIG9mIE1S TVQNCj4gPj4gd2hpY2ggaGFzIG9uZSBhbmQgb25seSBvbmUgUlRQIHN0cmVhbSBwZXIgTWVkaWEg U291cmNlIGFuZCBtZWRpYQ0KPiA+PiB0cmFuc3BvcnQ/IFRoZSByZWFzb24gZm9yIHN1Y2ggYSBv bmUgaXMgZXhhY3RseSB0aGUgZGlzY3Vzc2lvbiBoZWxkIGluIFNlY3Rpb24gMy44IGFib3V0IHVz aW5nIHRoZSBzYW1lIFNTUkMgdmFsdWUgaW4NCj4gbXVsdGlwbGUgUlRQIHNlc3Npb25zLg0KPiA+ IFtCb0JdIEkgZG9uJ3Qgc2VlIGFueSBzdHJvbmcgbmVlZCB0byBpbnRyb2R1Y2UgYW55IG5ldyBh Y3JvbnltIGZvciB0aGlzLCBidXQgZW5jb3VyYWdlIG90aGVycyB0byBjb21tZW50Lg0KPiA+DQo+ IA0KPiBZZXMsIHBsZWFzZSBwcm92aWRlIGlucHV0IGludG8gdGhpcyBxdWVzdGlvbi4NCj4gDQo+ IENoZWVycw0KPiANCj4gTWFnbnVzIFdlc3Rlcmx1bmQNCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g U2VydmljZXMsIE1lZGlhIGFuZCBOZXR3b3JrIGZlYXR1cmVzLCBFcmljc3NvbiBSZXNlYXJjaCBF QUIvVFhNDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRXJpY3Nzb24gQUIgICAgICAgICAgICAgICAgIHwg UGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQo+IEbDpHLDtmdhdGFuIDYgICAgICAgICAgICAgICAgIHwg TW9iaWxlICs0NiA3MyAwOTQ5MDc5DQo+IFNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbiB8IG1h aWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K From nobody Fri Feb 20 07:54:46 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2E31A87C9 for ; Fri, 20 Feb 2015 07:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 GIg_MYgxCNYZ for ; Fri, 20 Feb 2015 07:54:38 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E37961A87BD for ; Fri, 20 Feb 2015 07:54:36 -0800 (PST) X-AuditID: c1b4fb30-f791a6d000007827-31-54e758b9a3bc Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 9B.AE.30759.9B857E45; Fri, 20 Feb 2015 16:54:34 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.210.2; Fri, 20 Feb 2015 16:54:33 +0100 Message-ID: <54E758B8.50807@ericsson.com> Date: Fri, 20 Feb 2015 16:54:32 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "avtext@ietf.org" Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3RndXxPMQg/Zf3BYf791gtXjS8oPZ gcljyZKfTB47Nj9gDWCK4rJJSc3JLEst0rdL4Mp433+NreDeZsaKU/cPMzcwPuxh7GLk5JAQ MJHY8bEdyhaTuHBvPVsXIxeHkMARRok1L5rYIZzljBL/bj9hAqniFdCUWHRuCwuIzSKgKvF8 wyo2EJtNwELi5o9GMFtUIFhi8fOnrBD1ghInZz4BqxcRUJe4M/0CUA0HB7NAjMSVTiWQsLCA rcSPFU/AjmAWMJA4smgOK4QtL9G8dTYziC0koC3R0NTBOoGRfxaSqbOQtMxC0rKAkXkVo2hx anFSbrqRkV5qUWZycXF+nl5easkmRmAIHtzy22AH48vnjocYBTgYlXh4DRY/CxFiTSwrrsw9 xCjNwaIkzmtnfChESCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+PEyyF9d46+bXrB/363tL2R FZ/5BqFpp58lX3vZymH7fm1uYkRsZ6x04uMsq4sGx49+Nv5z9uMd1ly+HU1TzuTFyBxZ1LFR Zul3LfPfu/8Eni1rlIxO4lG8JqHyucSG/eXXw3dDC763FZ0v2vynfaH6kyuK5gbJDC+/l1w9 dsE9szth/cHVsoeUWIozEg21mIuKEwGnUjNMIgIAAA== Archived-At: Subject: [avtext] My comments on draft-ietf-avtext-rtp-stream-pause-06 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 15:54:43 -0000 Hi, This is one more case of me trying to catch up with what has happened to my documents during by parental leave. The benefit is that I do read them with less than usual home-blindness. I may also contradict previous consensus agreements, in those case just tell me so. Here are some comments on the draft: 1. Section 2.2: Feedback Messages: CCM [RFC5104] categorized different RTCP feedback messages into four types, Request, Command, Indication and Notification. This document places the PAUSE and RESUME messages into Request category, PAUSED as Indication and REFUSED as Notification. PAUSE Request from an RTP stream receiver to pause a stream RESUME Request from an RTP stream receiver to resume a paused stream PAUSED Indication from an RTP stream sender that a stream is paused REFUSED Indication from an RTP stream sender that a PAUSE or RESUME request will not be honored I think there need to be some separator character between the message name and the explanation. Maybe ":" is the simplest but I guess " - " would also work. There is also an inconsistency here about the usage of Indication vs Notification that for PAUSE and REFUSED that needs to be addressed. 2. Section 5.4: There may be local considerations at the RTP stream sender, for example that the media device is not ready, making it temporarily impossible to resume the stream at that point in time, and the RTP stream sender MAY then respond with a REFUSED containing the same PauseID as in the RESUME. When receiving such REFUSED with a PauseID identical to the one in the sent RESUME, RTP stream receivers SHOULD then avoid sending further RESUME requests for some reasonable amount of time, to allow the condition to clear. I see a potential issue in this text regarding the case ones RESUME request is refused. The participant sending the RESUME has clearly indicated that it desires the media stream, given that it was available. However, there is no recommendation here that the media sender actually starts sending by making a local decision to resume if the reason for refusing a resume is removed. That is however clearer in Section 6.4 that it is a local consideration. The requesting party being remote has no or little insight into the reason and can thus not determine when it really suitable to request a resume again. I would propose that we add to this a recommendation for the media sender that REFUSED a RESUME request to make a local decision to resume upon it being able to resume again. I would propose to add the following sentence to end of the above paragraph: A RTP stream sender having sent a REFUSED, is responsible to resume the media stream through local consideration upon the disappearance of the reason for sending that REFUSE. 3. Handling of TMMBR/TMMBN bounding set and who becomes the owner of the limitations. I think we have a potential issue with the handling of the bounding set for TMMBR/TMMBN when one sets the maximum total-bitrate to 0. Looking at the suggested algorithm (Section 3.5.4 in RFC 5104) for how to handle this, I draw the conclusion that this bounding set will become a single value. It will be the TMMBR value with the highest overhead value that will survive in this matching among any with a bit-rate value of 0. This will impact who becomes the owner (a single SSRC) and the handling of Local Pause. Lets look at the passage which are impacted by this: Section 5.2: There may be local considerations making it impossible or infeasible to pause the stream, and the RTP stream sender can then respond with a REFUSED. In this case, if the used PauseID would otherwise have been effective, REFUSED contains the same PauseID as in the PAUSE request, and the PauseID is kept as available. Note that when using TMMBR 0 as PAUSE, that request cannot be refused (TMMBN > 0) due to the existing restriction in section 4.2.2.2 of [RFC5104] that TMMBN shall contain the current bounding set, and the fact that a TMMBR 0 will always be the most restrictive point in any bounding set. This note is not completely correct and should be modify to clarify that the bounding set will be a single point from a TMMBR 0 with the higher measured average overhead. Section 5.4: A pausing RTP stream sender can apply local considerations and MAY resume a paused RTP stream at any time. If TMMBR 0 was used to pause the RTP stream, it cannot be resumed due to local considerations, unless the RTP stream is paused only due to local considerations (Section 5.3) and thus no RTP stream receiver has requested to pause the stream with TMMBR 0. That last sentence is mostly right, with the exception of a loop-hole that a local pause could become owner if and only if its measured over-head is larger than what is currently in the bounding set. The implication of applying this loop-hole is that the peer endpoint will become unable to send any type of resume message, as the Media Sender has become the owner of the restriction. But, this is a general limitation of the TMMBR 0 usage of pausing. Section 5.5: TMMBN 0: Corresponds to PAUSED when the RTP stream was paused with TMMBR 0, but may, just as PAUSED, also be used unsolicited. An unsolicited RTP stream pause based on local sender considerations uses the RTP stream's own SSRC as TMMBR restriction owner in the TMMBN message bounding set. Also corresponds to a REFUSED indication when a stream is requested to be resumed with TMMBR >0. I think there are two potential issues around this paragraph that needs clarification. First, is the remote peer allowed to send a TMMBR 0 when the TMMBN 0 with a bounding set owned by the media sender, when the receiver has a Overhead value that is bigger than what is in the TMMBN 0 message? Secondly, I think it should be further clarified that in the last case, if one media sender refuses to Resume the media sending, it becomes the owner of the TMMBR restriction by sending that TMMBN 0. That clarification could be as simple as: Also corresponds to a REFUSED indication when a stream is requested to be resumed with TMMBR >0, thus resulting the stream sender becoming the owner of the bounding set in the TMMBN message. Section 6.4: When using TMMBN 0 as PAUSED indication, being in paused state, and entering local paused state, the RTP stream sender SHALL send TMMBN 0 with itself included in the TMMBN bounding set. The SHALL as currently formulated is in conflict with RFC5104 in those cases when the local limitation point is not the one selected by the algorithm. Based on the above, I think the most reasonable way forward is simply to define the behaviour that is desirable and have this specification update the TMMBR specification. I think the important thing is to avoid enabling stealing of the bounding set by simple changing the overhead parameter as this is completely meaningless when one declared the total bandwidth as 0. Thus, allowing a peer SSRC that has paused to keep owning the bounding set, and then if a RESUME (TMMBR >0) is to be REFUSED have the media sender take over the limitation by sending a TMMBN with itself as owner of the TMMBR 0 limitation. 4. Section 6.2: The hold- off period MAY be set to 0 by some signaling (Section 9) means when it can be determined that there is only a single receiver, for example in point-to-point or some unicast situations. I think we should clarify what we really means with a "single receiver" in this context. Are we talking about Endpoints or what defines a receiver in this context. This becomes especially important in the next paragraph: If the RTP stream sender has set the hold-off period to 0 and receives information that it was an incorrect decision and that there are in fact several receivers of the stream, for example by RTCP RR, it MUST change the hold-off to instead be based on the above formula. How does the media sender determine that there is not only a single receiver. Fortunately we have already had a bit of private discussion around this with my co-authors for draft-ietf-avtcore-rtp-multi-stream where we have the same issue when addressing open issues in the -06. What we intended to propose is a solution that is: Only one CNAME in use among all SSRCs received (CSRC do not matter if they have different CNAMES) unless reporting groups (draft-ietf-avtcore-rtp-multi-stream-optimisation) is used, in which case a single report group is what matters to determine that it is still point to point, even in mixer or SFM middlebox cases. The report group addition is to deal with cases of SFMs and multi-synchronization context endpoints which are the cases that fails to be correctly classified when using CNAME. Thus, I suggest aligning the solutions here. 5. Section 6.3: When entering the state, the RTP stream sender SHALL send a PAUSED indication to all known RTP stream receivers, and SHALL also repeat PAUSED in the next two regular RTCP reports. I think the later part of the sentence needs an escape clause for the case when a RESUME request is received prior to having sent the two regular RTCP reports, this due to the fact that this is a sentence with a SHALL. 6. Section 6.3.2: Any streams that were paused by that removed participant SHALL be resumed. I think a SSRC should be added or replace "participant" in the above sentence. 7. Section 6.4: This state can be entered at any time, based on local decision from the RTP stream sender. As for Paused State (Section 6.3), the RTP stream sender SHALL send a PAUSED indication to all known RTP stream receivers, when entering the state, and repeat it a sufficient number of times to reach a high probability that the message is correctly delivered, unless the stream was already in paused state (Section 6.3). The exception of a RESUME prior to having concluded on the repetition of the PAUSED Indication? 8. Section 6.4: When leaving the state, the stream state SHALL become Playing, regardless whether or not there were any RTP stream receivers that sent PAUSE for that stream, effectively clearing the RTP stream sender's memory for that stream. I think it needs to be clarified what "leaving the state" means and who is performing this leaving in this case. Yes, that is the media sender, but its responsibility for doing this should be clarified. See issue 2, so this does not become a dead lock situation. 9. Section 8.1: When an RTP stream sender in Playing State (Section 6.1) receives a valid PAUSE, and unless local considerations currently makes it impossible to pause the stream, it SHALL enter Pausing State (Section 6.2) when reaching an appropriate place to pause in the stream, and act accordingly. I wonder why "when reaching an appropriate place to pause in the stream," is relevant for moving to PAUSING state? It appears much more relevant for having text along this line when entering "PAUSED" or "Local PAUSED" as that is when media transmission ceases, and it is that ceasing that should be done on media boundaries to avoid leaving receivers hanging in repair or perform concealment. 10. Section 8.2: PAUSED SHALL contain a 32 bit parameter with the RTP extended highest sequence number valid when the RTP stream was paused. Parameter Len MUST be set to 1. I think "RTP extended highest sequence number" shall contain a reference to Section 6.4.1 of RFC 3550. In addition I wonder if it is so good to write like this: "Parameter Len MUST be set to 1." what about any future extension parameters? 11. Section 7: I wonder if there should be some definitions that ensure that one can extended the parameter space in the future. The reason I am raising this is that if one like to extend for example PAUSED with an optional information field, unless a clear definition of what a first gen implementation does with unknown parameters this is going to be impossible. Instead one will have to define new sub-message types which the implementation doesn't know of. I would also note that the specification is not clear on that a implementation SHALL ignore FCIs with unknown types, that should be added. 12. Section 9. This specification follows all the rules defined in AVPF [RFC4585] and CCM [RFC5104] for an rtcp-fb attribute relating to payload type in a session description. I think the relation between this being a general transport mechanism and specific payload types might need a bit more discussion. From a basic perspective one can in most case assume a general capability to pause. Then there might be cases where the pausing of specific payload types are more complex due to media boundary alignment requirements and thus a differentiation in capabilities may arise. 13. Section 9: Note: When TMMBR 0 / TMMBN 0 are used to implement pause and resume functionality (with the restrictions described in this specification), signaling rtcp-fb attribute with ccm tmmbr parameter is sufficient and no further signaling is necessary. There is however no guarantee that TMMBR/TMMBN implementations pre-dating this specification work exactly as described here when used with a bitrate value of 0. I was wondering if there is a point to define that if one signals both "tmmbr" and "pause" one MUST be capable of handling pause functionality where applicable using TMMBR 0? 14. Section 9: When signaling a config value other than 1, an implementation MAY ignore non-supported messages on reception, and MAY omit sending non- supported messages. I wonder if the first "MAY" should be a "MUST" instead. I think it is reasonable that implementation are cable of ignoring messages that they declared they can't support. In multi-endpoint cases there might be some sub-set that perform certain operations and others that do a fuller set, when this do not collide. 15. Section 9, Figure 7: rtcp-fb-ccm-param =/ SP "pause" [SP pause-attr] pause-attr = [pause-config] [SP "nowait"] [SP byte-string] pause-config = "config=" pause-config-value pause-config-value = %x31-38 ; byte-string as defined in RFC 4566, for future extensions I think there is an error in this specification. If one excludes the "pause-config" then one ends up with "pause nowait", i.e. two spaces between the pause type and its other parameters. I think the ABNF could be adjusted to read like this: rtcp-fb-ccm-param =/ SP "pause" [pause-attr] pause-attr = [SP pause-config] [SP "nowait"] [SP byte-string] pause-config = "config=" pause-config-value pause-config-value = %x31-38 ; Config value 1-8 ; byte-string as defined in RFC 4566, for future extensions That would ensure that there is one and only one space between each parameter. I also note that this definition ends up with a strict ordering requirement. Further I wonder if the "pause-config-value = %x31-38" would benefit from being defined as pause-config-value = 1*2DIGIT instead? That way future new values for the config could be added up to the full space of 0-99. Of course that also means that one needs to define what it means to a receiver to see a config value it doesn't know of. I also think there be missing specification what do with any unknown (Future defined) parameters in a implementation according to this spec. 16. Section 9.1 and 9.2: I am missing a discussion of the meaning of PAUSE and TMMBR methods when both are present in a SDP. 17. Section 9.2: First, the "config" attribute and its message directions are interpreted based on the node receiving the SDP. I am think this is missing words on what requirement levels it means to have included a particular config value for the declarative usage. Is that the RECOMMENDED operation configuration or is a mandated one and if one doesn't support it one SHALL NOT join the session? 18. Section 10.2: Figure 11 and Figure 12: As the example include a PAUSE at t6, shouldn't the corresponding PAUSED be included as it is a mandated response? 19. Section 10.4: A transport Translator in an RTP session forwards the message from one peer to all the others. I think this text should use the word "Relay" for this type to make it clearer in relation to the updated topologies draft. 20. Section 12: This document extends the CCM [RFC5104] and defines new messages, i.e. PAUSE and RESUME. The exchange of these new messages MAY have some security implications, which need to be addressed by the user. Following are some important implications, 1. Identity spoofing - An attacker can spoof him/herself as an authenticated user and can falsely pause or resume any source transmission. In order to prevent this type of attack, a strong authentication and integrity protection mechanism is needed. 2. Denial of Service (DoS) - An attacker can falsely pause all source streams which MAY result in Denial of Service (DoS). An Authentication protocol may prevent this attack. 3. Man-in-Middle Attack (MiMT) - The pausing and resuming of an RTP source is prone to a Man-in-Middle attack. Public key authentication may be used to prevent MiMT. I think this section needs some work. In regards to 2. If we start on a none secured session, then anyone, even off-path attackers can spoof PAUSE message. Thus, integrity protection with at least group source authentication needs be used. I think a pointer to 7201 is suitable here. That should be the starting point. This leads to the current 1. Which is in cases where only group authentication, i.e. SRTP with symmetric crypto, then anyone in the group can perform identity spoofing and claim to be another user. This can be combated either using a stronger source authentication and in case of middlebox based groups, the middlebox can police against impersonations. Thirdly, I don't understand the man-in-the-middle attack here. The only addition on the two first points is the trust likely placed in the middlebox. To avoid third parties to inject a middlebox the signalling and security establishment needs to have sufficient security functionalities to prevent modification and provide identities that can be used in source authentication of any signalling messages. My initial proposal for a new section is below. 12. Security Considerations This document extends the CCM [RFC5104] and defines new messages, i.e. PAUSE, RESUME, PAUSED and REFUSED. The exchange of these new messages have some security implications, which need to be addressed by the user. The messages defined in this specification can have substantial impact on the perceived media quality if used in a malicious way. First of all is the risk for Denial of Service (DoS) on any RTP session that uses the PAUSE-RESUME functionality. By injecting one or more PAUSE requests into the RTP Session an attacker can potentially prevent any media from flowing, especially when the hold- off period is zero. The injection of PAUSE messages is quite simple, requiring knowledge of the SSRC and the PauseID. Information visible to an on-path attacker unless RTCP messages are encrypted. Even off- path attacks are possible as signalling messages often carry the SSRC value, while the 16-bit PauseID have to be guessed or tried. The way of protecting the RTP session from these injections are perform source authentication combined with message integrity to prevent other than intended session participants from sending these messages. There exist several different choices for securing RTP sessions to prevent this type of attack. SRTP is the the most common, but also other methods exists as discussed in "Options for Securing RTP Sessions" [RFC7201]. Most of the methods for securing RTP however, does not provide source authentication of each individual participant in a multi-party use case. In case one of the session participants are malicious they can wreck significant havoc within the RTP session and similarly cause a DoS on the RTP session from within. That damage can also be attempted to be obfuscated by having the attacker impersonate other endpoints within the session. These attacks can be mitigated by using a solution that provides true source authentication of all participant's RTCP packets. However, that has other implications. For multi-party sessions which includes a middlebox, that middlebox is RECOMMENDED to perform checks on all forwarded RTCP packets so that each participant only uses its set of SSRCs, to prevent the attacker utilizing other participants SSRCs. The above text has been focused on using the PAUSE message as the tool for malicious impact on the RTP session. That is because of the greater impact from denying users access to RTP media streams. In contrast if an attacker attempts to use RESUME in a malicious purpose it will result in that the media streams are delivered. However, such an attack basically prevents the use the Pause and Resume functionality. Thus, potentially forcing a reduction of the media quality due to limitation in available resources, like bandwidth that must be shared. The session establishment signalling is also a potential venue of attack as that can be used to prevent the enabling of Pause and Resume functionality by modifying the signalling messages. The above mitigation of attacks based on source authentication also requires the signalling system to securely handle identities and assert that only the intended identities are allowed into the RTP session and provided the relevant security contexts. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Feb 20 14:58:42 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF96A1A0354 for ; Fri, 20 Feb 2015 14:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.509 X-Spam-Level: X-Spam-Status: No, score=-0.509 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 G_DXSbuz4dpd for ; Fri, 20 Feb 2015 14:58:40 -0800 (PST) Received: from BLU004-OMC1S12.hotmail.com (blu004-omc1s12.hotmail.com [65.55.116.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27F11A0276 for ; Fri, 20 Feb 2015 14:58:39 -0800 (PST) Received: from BLU181-W54 ([65.55.116.9]) by BLU004-OMC1S12.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Fri, 20 Feb 2015 14:58:39 -0800 X-TMN: [72Kk5NaIu7TJIcSAVO9CvVakJpEjC3DQ8SkDcsQg45g=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_ef3a7881-9c78-4ae6-9186-725a1b0c675c_" From: Bernard Aboba To: Bo Burman , "avtext@ietf.org" Date: Fri, 20 Feb 2015 14:58:38 -0800 Importance: Normal In-Reply-To: References: <54CBA5AF.7040006@ericsson.com>, , <54D8D6F6.4070104@ericsson.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 20 Feb 2015 22:58:39.0576 (UTC) FILETIME=[C4169D80:01D04D60] Archived-At: Subject: Re: [avtext] Comments on draft-ietf-avtext-rtp-grouping-taxonomy-05 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 22:58:42 -0000 --_ef3a7881-9c78-4ae6-9186-725a1b0c675c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > >> I wonder if we should at this stage create a special version of MRMT > > >> which has one and only one RTP stream per Media Source and media > > >> transport? The reason for such a one is exactly the discussion held = in Section 3.8 about using the same SSRC value in > > multiple RTP sessions. > > > [BoB] I don't see any strong need to introduce any new acronym for th= is=2C but encourage others to comment. [BA] I don't see the need either. = --_ef3a7881-9c78-4ae6-9186-725a1b0c675c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>=3B >=3B >=3B>= =3B I wonder if we should at this stage create a special version of MRMT>=3B >=3B >=3B>=3B which has one and only one RTP stream per Media= Source and media
>=3B >=3B >=3B>=3B transport? The reason for s= uch a one is exactly the discussion held in Section 3.8 about using the sam= e SSRC value in
>=3B >=3B multiple RTP sessions.
>=3B >=3B &g= t=3B [BoB] I don't see any strong need to introduce any new acronym for thi= s=2C but encourage others to comment.

[BA] I don't see th= e need either.  =3B
= --_ef3a7881-9c78-4ae6-9186-725a1b0c675c_-- From nobody Sun Feb 22 11:24:48 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB531A044D for ; Sun, 22 Feb 2015 11:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 RuZVJfkFagIq for ; Sun, 22 Feb 2015 11:24:45 -0800 (PST) Received: from BLU004-OMC2S22.hotmail.com (blu004-omc2s22.hotmail.com [65.55.111.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 559531A0145 for ; Sun, 22 Feb 2015 11:24:45 -0800 (PST) Received: from BLU181-W64 ([65.55.111.72]) by BLU004-OMC2S22.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Sun, 22 Feb 2015 11:24:44 -0800 X-TMN: [YSKsQucSJd+jMTxlB9EKSnDWHu91SMFW] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_b88f5190-b350-4b16-ac2d-33e4425aaadd_" From: Bernard Aboba To: "avtext@ietf.org" Date: Sun, 22 Feb 2015 11:24:43 -0800 Importance: Normal In-Reply-To: References: <54CBA5AF.7040006@ericsson.com>, , <54D8D6F6.4070104@ericsson.com>, , MIME-Version: 1.0 X-OriginalArrivalTime: 22 Feb 2015 19:24:44.0410 (UTC) FILETIME=[368F35A0:01D04ED5] Archived-At: Subject: Re: [avtext] Comments on transport terminology in draft-ietf-avtext-rtp-grouping-taxonomy-05 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 19:24:47 -0000 --_b88f5190-b350-4b16-ac2d-33e4425aaadd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A few comments on Section 3.5: =20 3.5. Single- and Multi-Session Transmission of Dependent Streams=0A= =0A= Scalable media coding formats such as=2C for example=2C H.264 based SVC= =0A= [RFC6190] has two modes of operation:=0A= =0A= 1. In Single Session Transmission (SST)=2C the SVC Media Encoder sends= =0A= Encoded Streams (Section 2.1.7) and Dependent Streams=0A= (Section 2.1.8) as a single RTP Stream (Section 2.1.10) in a=0A= single RTP Session (Section 2.2.2)=2C using the SVC RTP Payload=0A= format.=0A= =0A= [BA] I do not believe this is accurate. The term SST as defined in RFC 619= 0 appears to have different meanings within different sections of the docum= ent. In sections relating to packetization=2C it appears to be synonymous = with a single RTP Stream=2C since use of multiple streams requires support = for the DON field. However=2C in other sections (such in referring to SDP)= =2C the SST/MST terminology really does appear to refer to single versus mu= ltiple RTP sessions. =0A= =0A= 2. In Multi-Session Transmission (MST)=2C the SVC Media Encoder sends= =0A= Encoded Streams and Dependent Streams distributed across multiple=0A= RTP Streams in one or more RTP Sessions. [BA] The meaning of MST in RFC 6190 is not really that clear. If you are re= ferring to use of the DON field=2C this is needed whenever multiple RTP str= eams are used regardless of whether we are talking about multiple RTP sessi= ons or not. =0A= SST denotes one RTP Stream (SSRC) per Media Source in a single RTP=0A= Session. MST denotes one or more RTP Streams (SSRC) per Media Source=0A= in each of multiple RTP Sessions. The above is not unambiguously=0A= specified in the SVC payload format text [RFC6190]=2C but it is what=0A= existing deployments of that RFC have implemented.=0A= [BA] The use of multiple RTP streams within a single RTP session is in fact= implemented - this is what was implemented in Lync 2013. =0A= The use of the term "RTP Session" in the SST/MST definition is=0A= somewhat misleading=2C since a single RTP Session can contain multiple= =0A= RTP Streams. [BA] My advice would be to point out the ambiguities in RFC 6190 SST/MST te= rminology=2C while not attempting to fix them retroactively. Overall=2C it= is more productiveto focus this document on the new SRST/MRST/MRMT termin= ology. Also=2C it is sometimes useful to make a distinction=0A= between using a single Media Transport or multiple separate Media=0A= Transports when (in both cases) using multiple RTP Streams to carry=0A= Encoded Streams and Dependent Streams for a Media Source. Therefore=2C= =0A= herein the following new terminology is defined:=0A= =0A= SRST: Single RTP Stream on a Single Media Transport=0A= =0A= MRST: Multiple RTP Streams on a Single Media Transport=0A= =0A= MRMT: Multiple RTP Streams on Multiple Media Transports=0A= = --_b88f5190-b350-4b16-ac2d-33e4425aaadd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
A few comm= ents on Section 3.5: =3B 

3.5.  Single=
- and Multi-Session Transmission of Dependent Streams
=0A=
=0A=
   Scalable media coding formats such as=2C for example=2C H.264 based SVC=
=0A=
   [RFC6190] has two modes =
of operation:=0A=
=0A=
   1.  In Single Session Transmission (SST)=2C the SVC Media Encoder sends=
=0A=
       Encoded Streams (Section 2.1.7) and Depend=
ent Streams=0A=
       (Section 2.1.8) as a single RTP Stream (Section 2.1.10) in a=0A=
       single RTP Session (Section 2.2.2)=2C usin=
g the SVC RTP Payload=0A=
       format.=0A=
=0A=
[BA] I do not believe this is accurate.  The term SST as defined in RFC 619=
0 appears to have different meanings within different sections of the docum=
ent.  In sections relating to packetization=2C it appears to be synonymous =
with a single RTP Stream=2C since use of multiple streams requires support =
for the DON field.  However=2C in other sections (such in referring to SDP)=
=2C the SST/MST terminology really does appear to refer to single versus mu=
ltiple RTP sessions. =3B 
=0A=
=0A=
   2.  In Multi-Session Transmission (MST)=2C the SVC Media Encoder sends=
=0A=
       Encoded Streams and Dependent Streams distributed across multiple=0A=
       RTP Streams in one or more RTP Sessions.

[BA] The meaning of MST in RFC 6190 is not really that clear. If you a=
re referring to use of the DON field=2C this is needed whenever multiple RT=
P streams are used regardless of whether we are talking about multiple RTP =
sessions or not.      
=0A=
   SST denotes one RTP Stream (SSRC) per Media Source in a single RTP=0A=
   Session.  MST denotes one or more RTP Streams (SSRC) per Media Source=0A=
   in each of multiple RTP Sessions.  The above is not unambiguously=0A=
   specified in the SVC payload format text [RFC6190]=2C but it is what=0A=
   existing deployments of that RFC have implemented.=0A=

[BA] The use of mul=
tiple RTP streams within a single RTP session is in fact implemented - this i=
s what was implemented in Lync 2013. 
=0A=
   The use of the term "RTP Session" in the SST/MST definition is=0A=
   somewhat misleading=2C since a single RTP Session can contain multiple=
=0A=
   RTP Streams.

[BA] My advice would be to =
point out the ambiguities in RFC 6190 SST/MST terminology=2C while not atte=
mpting to fix them retroactively.  =3BOverall=2C it is more productive<=
/pre>
to focus this document o=
n the new  SRST/MRST/MRMT terminology.

   Also=2C it is sometimes useful to make a distinction=0A=
   between using a single Media Transport or multiple separate Media=0A=
   Transports when (in both cases) using multiple RTP Streams to carry=0A=
   Encoded Streams and Dependent Streams for a Media Source.  Therefore=2C=
=0A=
   herein the following new terminology is defined:=0A=
=0A=
   SRST:  Single RTP Stream on a Single Media Transport=0A=
=0A=
   MRST:  Multiple RTP Streams on a Single Media Transport=0A=
=0A=
   MRMT:  Multiple RTP Streams on Multiple Media Transports=0A=

= --_b88f5190-b350-4b16-ac2d-33e4425aaadd_--