From nobody Mon Mar 2 02:50:50 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 C07411A86F7 for ; Mon, 2 Mar 2015 02:50: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 dfk8Mj6PCJuY for ; Mon, 2 Mar 2015 02:50:44 -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 6BAC61A86F3 for ; Mon, 2 Mar 2015 02:50:43 -0800 (PST) X-AuditID: c1b4fb3a-f79036d000001e94-15-54f44081e35e Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 5E.45.07828.18044F45; Mon, 2 Mar 2015 11:50:41 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.118]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0210.002; Mon, 2 Mar 2015 11:50:40 +0100 From: Bo Burman To: Bernard Aboba , "avtext@ietf.org" Thread-Topic: [avtext] Comments on transport terminology in draft-ietf-avtext-rtp-grouping-taxonomy-05 Thread-Index: AQHQTtU74ArKVgsRhUyTOAP0z2nQCJ0I/0ag Date: Mon, 2 Mar 2015 10:50:39 +0000 Message-ID: References: <54CBA5AF.7040006@ericsson.com>, , <54D8D6F6.4070104@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_BBE9739C2C302046BD34B42713A1E2A22E4E0999ESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM+JvjW6jw5cQg6ZjshYf791gtdi/5DKz A5PH454zbB5LlvxkCmCK4rJJSc3JLEst0rdL4Mr4t/YGY8G1/YwVp3o/sTQw9qxg7GLk5JAQ MJG4M2EZE4QtJnHh3nq2LkYuDiGBI4wSk/d2sEM4ixklXt7oBetgE9CQmL/jLpgtIhAisaJt KSuILSyQLrHo21YmiHiGxLXNV6BqjCR2vJrJDGKzCKhITPw4HSzOK+Ar8XzBa6gFO5kkDl7r AWvmFLCSmPz7GthQRgFZifvf77GA2MwC4hK3nsyHOlVAYsme88wQtqjEy8f/gOo5gGwliWlb 00BMZoF8id2HmCBWCUqcnPmEZQKjyCwkg2YhVM1CUgVRoiOxYPcnNghbW2LZwtfMMPaZA4+Z kMUXMLKvYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3ZxAiMrINbflvtYDz43PEQowAHoxIPr8Gl zyFCrIllxZW5hxilOViUxHntjA+FCAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCc+5z/sXvH fPEfqp2Sc3j/eBj6ZPNElzjopffOXMy3z5mDT9txiq1uc+W0xVfCWqZ5Gd1aVc+70NE4Ui68 wffGvTMeagtYdJ237fwbpugTkXso8fCDmdc8gmzfc0gGyT5TX7Lgr9aT4g5Bn54Ztr+7awQ3 fToZXfRr87vKo/WblcLtzIT3sCmxFGckGmoxFxUnAgA+a4jWjQIAAA== 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: Mon, 02 Mar 2015 10:50:48 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22E4E0999ESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I wonder if your comments below at least partially relates to the fact that= the text in the first part of 3.5 can be read as stating a design fact for= "scalable media codecs", rather than describing a non-wanted and ambiguous= definition in RFC 6190 that this draft would like to clarify and enhance? Would it help if the text is changed to more clearly state what is the curr= ent situation, in what way it is ambiguous (maybe using words similar to yo= urs below), and somehow makes it even more clear (text suggestion would be = highly appreciated) that this draft suggests to use other terminology? Further responses inline. Cheers, Bo From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: den 22 februari 2015 20:25 To: avtext@ietf.org Subject: Re: [avtext] Comments on transport terminology in draft-ietf-avtex= t-rtp-grouping-taxonomy-05 A few comments on Section 3.5: 3.5. Single- and Multi-Session Transmission of Dependent Streams Scalable media coding formats such as, for example, H.264 based SVC [RFC6190] has two modes of operatio= n: 1. In Single Session Transmission (SST), the SVC Media Encoder sends Encoded Streams (Section 2.1.7) and Dependent Streams (Section 2.1.8) as a single RTP Stream (Section 2.1.10) in a single RTP Session (Section 2.2.2), using the SVC RTP Pay= load format. [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, it appears to be synonymous wi= th a single RTP Stream, since use of multiple streams requires support for = the DON field. However, in other sections (such in referring to SDP), the = SST/MST terminology really does appear to refer to single versus multiple R= TP sessions. [BoB] I agree that use of SST/MST in RFC 6190 is unclear, no argument there= . :) I'm however not sure I understand what you believe to be inaccurate o= r how you would like to see the text changed? Is the text maybe unclear tha= t both Encoded Streams and Dependent Streams are sent within one and the sa= me RTP Stream for SST? That is at least what is meant, and I can amend the = text to say that. I also see no problem to add something similar to your te= xt above, describing in what sense SST is unclear in RFC 6190. 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. [BA] The meaning of MST in RFC 6190 is not really that clear. If you are re= ferring to use of the DON field, this is needed whenever multiple RTP strea= ms are used regardless of whether we are talking about multiple RTP session= s or not. [BoB] Yes. It was already suggested to use "two or more" instead of "multip= le" above, which should be clearer and make the sentence more correct. Also= here, I see no problems being more explicit in what is unclear with MST. SST denotes one RTP Stream (SSRC) per Media Source in a single RTP Session. MST denotes one or more RTP Streams (SSRC) per Media Source in each of multiple RTP Sessions. The above is not unambiguously specified in the SVC payload format text [RFC6190], but it is what existing deployments of that RFC have implemented. [BA] The use of multiple RTP streams within a single RTP session is in fact= implemented - this is what was implemented in Lync 2013. [BoB] Then the text should be changed accordingly! Maybe we should just ref= rain from talking about what "existing deployments" do or don't do, and rem= ove this paragraph entirely, as text on the ambiguities with SST/MST should= , with the suggested changes, now be addressed directly in items 1 and 2? The use of the term "RTP Session" in the SST/MST definition is somewhat misleading, since a single RTP Session can contain multiple RTP Streams. [BA] My advice would be to point out the ambiguities in RFC 6190 SST/MST te= rminology, while not attempting to fix them retroactively. Overall, it is = more productive to focus this document on the new SRST/MRST/MRMT terminology. [BoB] Fully agree! Would the changes suggested above address your concerns = of not fixing SST/MST, but rather describe what is unclear with SST/MST, an= d focus on the new terminology? Also, it is sometimes useful to make a distinction between using a single Media Transport or multiple separate Media Transports when (in both cases) using multiple RTP Streams to carry Encoded Streams and Dependent Streams for a Media Source. Therefore, herein the following new terminology is defined: SRST: Single RTP Stream on a Single Media Transport MRST: Multiple RTP Streams on a Single Media Transport MRMT: Multiple RTP Streams on Multiple Media Transports --_000_BBE9739C2C302046BD34B42713A1E2A22E4E0999ESESSMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I wonder if your comments= below at least partially relates to the fact that the text in the first pa= rt of 3.5 can be read as stating a design fact for “scalable media codecs”, rather than describing a non-wanted and ambiguous def= inition in RFC 6190 that this draft would like to clarify and enhance?=

 <= /p>

Would it help if the text= is changed to more clearly state what is the current situation, in what wa= y it is ambiguous (maybe using words similar to yours below), and somehow makes it even more clear (text suggestion would be highly appr= eciated) that this draft suggests to use other terminology?

 <= /p>

Further responses inline.=

 <= /p>

Cheers,=

Bo

 <= /p>

From: avtext [= mailto:avtext-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: den 22 februari 2015 20:25
To: avtext@ietf.org
Subject: Re: [avtext] Comments on transport terminology in draft-iet= f-avtext-rtp-grouping-taxonomy-05

 

A few comments on Section 3.5: 

 

3.5.&nb= sp; Single- and Multi-Session Transmission of Dependent Streams

 
 
&n=
bsp;  Scalable media coding formats such as, for example, H.264 based =
SVC
&n=
bsp;  [RFC6190] has two mo=
des of operation:
 
&n=
bsp;  1.  In Single Session Transmission (SST), the SVC Media Enc=
oder sends
&n=
bsp;      Encoded Streams (S=
ection 2.1.7) and Dependent Streams
&n=
bsp;      (Section 2.1.8=
) as a single RTP Stream (Section 2.1.10) in a
&n=
bsp;      single RTP Session (&n=
bsp;      format.
 
[B=
A] I do not believe this is accurate.  The term SST as defined in RFC =
6190 appears to have different meanings within different sections of the do=
cument.  In sections relating to packetization, it appears to be synon=
ymous with a single RTP Stream, since use of multiple streams requires supp=
ort for the DON field.  However, in other sections (such in referring =
to SDP), the SST/MST terminology really does appear to refer to single vers=
us multiple RTP sessions.  

[B=
oB] I agree that use of SST/MST in RFC 6190 is unclear, no argument there. =
:)  I’m however not sure I understand what you believe to be ina=
ccurate or how you would like to see the text changed? Is the text maybe un=
clear that both Encoded Streams and Dependent Streams are sent within one a=
nd the same RTP Stream for SST? That is at least what is meant, and I can a=
mend the text to say that. I also see no problem to add something similar t=
o your text above, describing in what sense SST is unclear in RFC 6190.


 


 


&n=
bsp;  2.  In Multi-Session Transmission (MST), the SVC Media Enco=
der sends


&n=
bsp;      Encoded Streams and Dependent Streams di=
stributed across multiple


&n=
bsp;      RTP Streams in one or more RTP Sessions.=






[B=
A] The meaning of MST in RFC 6190 is not really that clear. If you are refe=
rring to use of the DON field, this is needed whenever multiple RTP streams=
 are used regardless of whether we are talking about multiple RTP sessions =
or not.    


[B=
oB] Yes. It was already suggested to use “two or more” instead =
of “multiple” above, which should be clearer and make the sente=
nce more correct. Also here, I see no problems being more explicit in what =
is unclear with MST.


  


 


&n=
bsp;  SST denotes one RTP Stream (SSRC) per Media Source in a single R=
TP


&n=
bsp;  Session.  MST denotes one or more RTP Streams (SSRC) per Me=
dia Source


&n=
bsp;  in each of multiple RTP Sessions.  The above is not unambig=
uously


&n=
bsp;  specified in the SVC payload format text [RFC6190], but it is what


&n=
bsp;  existing deployments of that RFC have implemented.





[B=
A] The use of multiple RTP streams within a single RTP =
session is in fact implemented - this is what was implemented in Lync 2013.=
 


[B=
oB] Then the text should be changed accordingly! Maybe we should just refra=
in from talking about what “existing deployments” do or donR=
17;t do, and remove this paragraph entirely, as text on the ambiguities wit=
h SST/MST should, with the suggested changes, now be addressed directly in =
items 1 and 2?


 


 


&n=
bsp;  The use of the term "RTP Session" in the SST/MST defin=
ition is


&n=
bsp;  somewhat misleading, since a single RTP Session can contain mult=
iple


&n=
bsp;  RTP Streams.





[B=
A] My advice would be to point out the ambiguities in RFC 6190 SST/MST term=
inology, while not attempting to fix them retroactively.  Overall, it =
is more productive


to=
 focus this document on the new  SRST/MRST/MRMT te=
rminology.


[B=
oB] Fully agree! Would the changes suggested above address your concerns of=
 not fixing SST/MST, but rather describe what is unclear with SST/MST, and =
focus on the new terminology?





&n=
bsp;  Also, it is sometimes useful to make a distinction


&n=
bsp;  between using a single Media Transport or multiple separate Medi=
a


&n=
bsp;  Transports when (in both cases) using multiple RTP Streams to ca=
rry


&n=
bsp;  Encoded Streams and Dependent Streams for a Media Source.  =
Therefore,


&n=
bsp;  herein the following new terminology is defined:


 


&n=
bsp;  SRST:  Single RTP Stream on a Single Media Transport


 


&n=
bsp;  MRST:  Multiple RTP Streams on a Single Media Transport


 


&n=
bsp;  MRMT:  Multiple RTP Streams on Multiple Media Transports




 
--_000_BBE9739C2C302046BD34B42713A1E2A22E4E0999ESESSMB105erics_-- From nobody Mon Mar 2 05:27:05 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 F1C891A8755 for ; Mon, 2 Mar 2015 05:27:03 -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 6mF8aC4S8T5T for ; Mon, 2 Mar 2015 05:27:02 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A951A8763 for ; Mon, 2 Mar 2015 05:27:01 -0800 (PST) X-AuditID: c1b4fb25-f79446d000003f3f-f7-54f46523e851 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 60.19.16191.32564F45; Mon, 2 Mar 2015 14:26:59 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.3.210.2; Mon, 2 Mar 2015 14:26:58 +0100 Message-ID: <54F46514.8050905@ericsson.com> Date: Mon, 2 Mar 2015 14:26:44 +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 , Bernard Aboba , "avtext@ietf.org" References: <54CBA5AF.7040006@ericsson.com>, , <54D8D6F6.4070104@ericsson.com>, , In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM+Jvja5y6pcQg4+HhCw+3rvBarF/yWVm ByaPxz1n2DyWLPnJFMAUxWWTkpqTWZZapG+XwJUxs6eVteCDWUX3lpWMDYyvtboYOTkkBEwk pq86ywJhi0lcuLeerYuRi0NI4AijxI0fh9ghnGWMEvNXfGUGqeIV0Jb41vOOtYuRg4NFQEVi 4xtHkDCbgIXEzR+NbCC2qECwxOLnT1khygUlTs58ArZARKBCYuqbHUwgrcICqRLLp5iChIUE PjJJbP1iD2JzCvhJfNjxmhHEZhYwkDiyaA4rhC0v0bx1NjNEvbZEQ1MH6wRGgVlINsxC0jIL ScsCRuZVjKLFqcVJuelGxnqpRZnJxcX5eXp5qSWbGIFBeXDLb9UdjJffOB5iFOBgVOLhNbj0 OUSINbGsuDL3EKM0B4uSOK+d8aEQIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYx9vx8XNa10 25OrfrHg4dm41RfcajmPG1jPWdRR1junNv/tNkdOmzeBrY+WT3zrcPxE8/m+dXd2bP1yv6e4 /EPw/YKlMx7WzagQMY178D+YobE8Kfrzj+UKrMY5UUqCeQdkD33R22uh2y8pHJOg880uW6rm FI+uU/acLS5fmK64v5hx77w/p5ASS3FGoqEWc1FxIgBd/fdHKwIAAA== 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: Mon, 02 Mar 2015 13:27:04 -0000 Hi, Having reviewed the text in 3.5 and 3.8 I think it is very reasonable to go the proposed and focusing on defining the terms to use in the future for these configurations. I must however note that 3.8 has significant overlap, and thus I think one should combine 3.5 and 3.8 into a Scalable Coding Transport, and have the definition and the example figure etc. in one section. Views on this? /Magnus On 2015-03-02 11:50, Bo Burman wrote: > I wonder if your comments below at least partially relates to the fact > that the text in the first part of 3.5 can be read as stating a design > fact for “scalable media codecs”, rather than describing a non-wanted > and ambiguous definition in RFC 6190 that this draft would like to > clarify and enhance? > > > > Would it help if the text is changed to more clearly state what is the > current situation, in what way it is ambiguous (maybe using words > similar to yours below), and somehow makes it even more clear (text > suggestion would be highly appreciated) that this draft suggests to use > other terminology? > > > > Further responses inline. > > > > Cheers, > > Bo > > > > *From:*avtext [mailto:avtext-bounces@ietf.org] *On Behalf Of *Bernard Aboba > *Sent:* den 22 februari 2015 20:25 > *To:* avtext@ietf.org > *Subject:* Re: [avtext] Comments on transport terminology in > draft-ietf-avtext-rtp-grouping-taxonomy-05 > > > > A few comments on Section 3.5: > > > > > 3.5 > . > Single- and Multi-Session Transmission of Dependent Streams > > > > > > Scalable media coding formats such as, for example, H.264 based SVC > > [RFC6190 ] has two modes of operation: > > > > 1. In Single Session Transmission (SST), the SVC Media Encoder sends > > Encoded Streams (Section 2.1.7 ) and Dependent Streams > > (Section 2.1.8 ) as a single RTP Stream (Section 2.1.10 ) in a > > single RTP Session (Section 2.2.2 ), using the SVC RTP Payload > > format. > > > > [BA] I do not believe this is accurate. The term SST as defined in RFC 6190 appears to have different meanings within different sections of the document. In sections relating to packetization, it appears to be synonymous with a single RTP Stream, since use of multiple streams requires support for the DON field. However, in other sections (such in referring to SDP), the SST/MST terminology really does appear to refer to single versus multiple RTP sessions. > > */[BoB] I agree that use of SST/MST in RFC 6190 is unclear, no argument there. :) I’m however not sure I understand what you believe to be inaccurate or how you would like to see the text changed? Is the text maybe unclear that both Encoded Streams and Dependent Streams are sent within one and the same RTP Stream for SST? That is at least what is meant, and I can amend the text to say that. I also see no problem to add something similar to your text above, describing in what sense SST is unclear in RFC 6190./* > > > > > > 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. > > > [BA] The meaning of MST in RFC 6190 is not really that clear. If you are referring to use of the DON field, this is needed whenever multiple RTP streams are used regardless of whether we are talking about multiple RTP sessions or not. > > */[BoB] Yes. It was already suggested to use “two or more” instead of “multiple” above, which should be clearer and make the sentence more correct. Also here, I see no problems being more explicit in what is unclear with MST./* > > > > > > SST denotes one RTP Stream (SSRC) per Media Source in a single RTP > > Session. MST denotes one or more RTP Streams (SSRC) per Media Source > > in each of multiple RTP Sessions. The above is not unambiguously > > specified in the SVC payload format text [RFC6190 ], but it is what > > existing deployments of that RFC have implemented. > > > [BA] The use of multiple RTP streams within a single RTP session is in fact implemented - this is what was implemented in Lync 2013. > > */[BoB] Then the text should be changed accordingly! Maybe we should just refrain from talking about what “existing deployments” do or don’t do, and remove this paragraph entirely, as text on the ambiguities with SST/MST should, with the suggested changes, now be addressed directly in items 1 and 2?/* > > */ /* > > > > The use of the term "RTP Session" in the SST/MST definition is > > somewhat misleading, since a single RTP Session can contain multiple > > RTP Streams. > > > [BA] My advice would be to point out the ambiguities in RFC 6190 SST/MST terminology, while not attempting to fix them retroactively. Overall, it is more productive > > to focus this document on the new SRST/MRST/MRMT terminology. > > */[BoB] Fully agree! Would the changes suggested above address your concerns of not fixing SST/MST, but rather describe what is unclear with SST/MST, and focus on the new terminology?/* > > > Also, it is sometimes useful to make a distinction > > between using a single Media Transport or multiple separate Media > > Transports when (in both cases) using multiple RTP Streams to carry > > Encoded Streams and Dependent Streams for a Media Source. Therefore, > > herein the following new terminology is defined: > > > > SRST: Single RTP Stream on a Single Media Transport > > > > MRST: Multiple RTP Streams on a Single Media Transport > > > > MRMT: Multiple RTP Streams on Multiple Media Transports > > > > > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > -- 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 Tue Mar 3 04:06:06 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 221B71A6F17 for ; Tue, 3 Mar 2015 04:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 DNemLbPPR8Hc for ; Tue, 3 Mar 2015 04:05:57 -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 AD2F71A6ED9 for ; Tue, 3 Mar 2015 04:01:34 -0800 (PST) X-AuditID: c1b4fb30-f79c86d000000fc0-e4-54f5a29c24b1 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 3C.D6.04032.C92A5F45; Tue, 3 Mar 2015 13:01:32 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.118]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0210.002; Tue, 3 Mar 2015 13:01:32 +0100 From: Bo Burman To: Magnus Westerlund , "avtext@ietf.org" Thread-Topic: My comments on draft-ietf-avtext-rtp-stream-pause-06 Thread-Index: AQHQTSWFAC/609cwC0yMx88n5zneNpz/d+GQ Date: Tue, 3 Mar 2015 12:01:31 +0000 Message-ID: References: <54E758B8.50807@ericsson.com> In-Reply-To: <54E758B8.50807@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM+Jvje6cRV9DDN590rP4eO8Gq8WTlh/M DkweS5b8ZPLYsfkBawBTFJdNSmpOZllqkb5dAlfGt5VTGAtOTGCqOPe0hamBsekqYxcjJ4eE gInEwtPbmCBsMYkL99azdTFycQgJHGGU6Pl2kQXCWcwocf/kTTaQKjYBDYn5O+6CdYsIxEo8 vNcJZjMLaEu8+NEIViMs4CixqO8LVI2TxOOnk9ggbCOJvW8WsIPYLAIqEq+f3Qar4RXwlVgx 8xOYLSSgKbFtdzfYRZwCWhLnV8wAsxkFZCXuf7/HArFLXOLWk/lQVwtILNlznhnCFpV4+fgf K4StKHF1+nImiHo9iRtTp7DB3Lls4WtmiL2CEidnPmGZwCg2C8nYWUhaZiFpmYWkZQEjyypG 0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwCg6uOW3wQ7Gl88dDzEKcDAq8fBuUP4aIsSaWFZc mXuIUZqDRUmc1874UIiQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxjzVKXmV6bkrZz3vdjh7 XK85tTl26vtuweTIsOMrbSov6F2b9en6WQ7PBWZz2RebNEYcOfJssoucUsr7OoP1T9b5B7wT 3erYKtr/0oCtK3H9w/vHwuKzGmd3Tkrnqww+u3hCWPkRvZTPsjq3wqwX/lH/63Dy0sm3Qf+3 vZaQPxzWr/x99os2FyWW4oxEQy3mouJEAO6J5cuDAgAA Archived-At: Subject: Re: [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: Tue, 03 Mar 2015 12:06:04 -0000 Thank you for this thorough review! Please find my responses inline. Note that I specifically would like others to comment on a few of Magnus' i= tems: - Item 3: How much elaborative text on TMMBR/TMMBN bounding set overhead va= lue considerations do we want to add into section 5.2 (see my response to t= hat item 3 below to get the context)? - Item 13: Is there a point to define that if both "ccm tmmbr" and "ccm pau= se" is included in the SDP, the part sending that SDP MUST be capable of ha= ndling corresponding pause functionality using TMMBR/TMMBN 0, as defined in= this specification? Cheers, Bo > -----Original Message----- > From: Magnus Westerlund > Sent: den 20 februari 2015 16:55 > To: avtext@ietf.org > Cc: Bo Burman; Roni Even > Subject: My comments on draft-ietf-avtext-rtp-stream-pause-06 >=20 > Hi, >=20 > 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. >=20 >=20 > Here are some comments on the draft: >=20 > 1. Section 2.2: >=20 > 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. >=20 > PAUSE Request from an RTP stream receiver to pause a stream >=20 > RESUME Request from an RTP stream receiver to resume a paused > stream >=20 > PAUSED Indication from an RTP stream sender that a stream is > paused >=20 > REFUSED Indication from an RTP stream sender that a PAUSE or > RESUME request will not be honored >=20 > I think there need to be some separator character between the message nam= e and the explanation. Maybe ":" is the > simplest but I guess " - " > would also work. [BoB] OK >=20 > There is also an inconsistency here about the usage of Indication vs Noti= fication that for PAUSE and REFUSED that needs > to be addressed. [BoB] REFUSED should be a Notification, so this is a typo. OK. Should be co= rrected throughout the document, if there are more places using indication. >=20 > 2. Section 5.4: >=20 > 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. >=20 >=20 > I see a potential issue in this text regarding the case ones RESUME reque= st 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 s= tarts sending by making a local decision to > resume if the reason for refusing a resume is removed. That is however cl= earer 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. >=20 > 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 prop= ose to add the following sentence to end of the > above paragraph: >=20 > 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. [BoB] What about "An RTP stream sender having sent a REFUSED SHOULD resume the stream through local considerations (see below) when the condition that caused the REFUSED is no longer true."? The "see below" is meant to refer to the text two clauses further down, sta= ting "A pausing RTP stream sender can apply local considerations and MAY resume = a paused RTP stream at any time". >=20 >=20 > 3. Handling of TMMBR/TMMBN bounding set and who becomes the owner of the = limitations. >=20 > I think we have a potential issue with the handling of the bounding set f= or 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. >=20 > This will impact who becomes the owner (a single SSRC) and the handling o= f Local Pause. Lets look at the passage which > are impacted by this: >=20 > Section 5.2: >=20 > 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. >=20 > 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. [BoB] While I agree that the current text does not mention overhead, I thin= k that the text _is_ in fact strictly correct, because _a_ TMMBR 0 _will_ b= e the most restrictive point in any bounding set, regardless of its overhea= d value, and cannot be refused with any TMMBN >0. One TMMBR {0, overhead1} = could in principle be "refused" with a TMMBN {0, overhead2} if overhead2 > = overhead1 from an RFC 5104 perspective, but I so far thought that detail ne= ed not be considered in this specification. I may be wrong here. Note that TMMBN 0 (regardless of overhead) is defined to correspond to a PA= USED, so a PAUSE through TMMBR 0 can in principle never be refused (cause a= TMMBN >0), even if a specific TMMBR 0 may not actually enter the bounding = set. Even if the returned TMMBN 0 has a different overhead value, it is sti= ll a PAUSED and thus a "successful outcome" of the TMMBR 0 (PAUSE), and con= firms that the stream is already paused from the perspective of this specif= ication. What can actually happen when TMMBR/TMMBN is used and when local and remote= have different overhead values, is the party having the larger overhead "t= akes over" the bounding set when combining a PAUSE request with local pause= d state. This can in turn impact who can lift the restriction and resume, a= nd I believe that requires a discussion. The cases where a local party A has larger overhead than a remote party B a= lready work as specified in Section 6.4: * When A is already paused by B, and A decides to go into local pause, A ca= n (as mandated by 6.4) send a (new) TMMBN (PAUSED) with itself in the bound= ing set, meaning that A even from a TMMBR/TMMBN perspective is allowed to d= ecide when to leave local paused state. * When A is in local pause and receives a TMMBR 0 (PAUSE) from B, the recei= ved TMMBR 0 is less restrictive and will be ignored, just as a PAUSE would = be ignored while already in paused or local paused state. * When A is in local pause and decides to resume it can do that based on a = local decision, since it is in the bounding set and just as described for l= ocal paused state in this specification. The cases where a local party A has less overhead than a remote party B do = not work as currently specified in Section 6.4, taking the TMMBR/TMMBN over= head rule into account: * When A is already paused by B, and A decides to go into local pause, A fo= rmally cannot send any new TMMBN 0 with itself owning the bounding set, due= to the overhead rules you point out. * When A is in local pause and receives a TMMBR 0 from B, the new TMMBR wil= l replace the one from local pause, B effectively taking over ownership of = the bounding set; as seen from this specification it can still be in local = pause, although a TMMBN will not be able to explicitly indicate this becaus= e the media senders SSRC is not in the bounding set, but that is in any cas= e specific to TMMBR/TMMBN usage and while it should be mentioned in the tex= t, it does not break anything * When A is in local pause, and has received a TMMBR 0 from a B that has la= rger overhead, as above, and when B lifts that restriction with a TMMBR 0 (= RESUME), but A cannot resume at this time due to continued local considerat= ions, it can stay in local paused state and simply send a new TMMBN 0 with = itself in the bounding set. * When A is in local pause and wishes to resume it cannot do that simply on= a local decision since the restriction is owned by B, which is a deviation= from what is currently specified; suggest describing this case as specific= to the use of TMMBR/TMMBN. Specifically, the state machine described at th= e beginning of Section 6 is not really correct for use in TMMBR/TMMBN, sinc= e a TMMBR 0 (PAUSE) can effectively take a media sender from Local Paused t= o Paused state. In terms of media flows, this has very minor impact. For the cases where local party A has same overhead as remote party B, and = from re-reading the algorithm in RFC 5104, which party is chosen to be incl= uded in the bounding set is either random or implementation-specific. In an= y case, the situation formally depends on who paused: * If A decides to go to local pause, it will own the bounding set, B cannot= "take over" by sending a TMMBR, and it will be the same as when A has the = larger overhead above. * If B pauses A, and A later decides to go to local pause, it cannot effect= ively go to (or rather, signal) local paused state, because B owns the boun= ding set and the situation is the same as when B has the larger overhead ab= ove. How much of the above elaborative text and clarifications do we need in the= draft text? >=20 > Section 5.4: >=20 > 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. >=20 > That last sentence is mostly right, with the exception of a loop-hole tha= t a local pause could become owner if and only if > its measured over-head is larger than what is currently in the bounding s= et. The implication of applying this loop-hole is > that the peer endpoint will become unable to send any type of resume mess= age, as the Media Sender has become the > owner of the restriction. But, this is a general limitation of the TMMBR = 0 usage of pausing. [BoB] Agree that this is a general limitation of TMMBR 0 usage. However, I = don't think that the peer is _unable_ to send TMMBR >0 (RESUME) and it is n= ot in any way forbidden to send it; the media sender can still see this mes= sage, but it will not be effective. The media sender can resume whenever th= e situation that caused the local paused state clears, which is entirely in= line with how local paused state is currently described. >=20 > Section 5.5: >=20 > 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. >=20 > I think there are two potential issues around this paragraph that needs c= larification. First, is the remote peer allowed to > send a TMMBR 0 when the TMMBN 0 with a bounding set owned by the media se= nder, when the receiver has a > Overhead value that is bigger than what is in the TMMBN 0 message? [BoB] Yes, of course, and fully in line with RFC 5104, but it is not really= clear to me what reason the remote peer would have to send a TMMBR 0 when = it is already pausing (sending TMMBN 0). That will, as elaborated above, ma= ke the remote peer become owner of the bounding set and will prohibit the m= edia sender from going out of local paused state. >=20 > Secondly, I think it should be further clarified that in the last case, i= f one media sender refuses to Resume the media > sending, it becomes the owner of the TMMBR restriction by sending that TM= MBN 0. [BoB] Agreed. Just as stated in my long text above. >=20 > That clarification could be as simple as: >=20 > 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. [BoB] OK, with an "in" after "resulting". :) >=20 > Section 6.4: >=20 > 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. >=20 > The SHALL as currently formulated is in conflict with RFC5104 in those ca= ses when the local limitation point is not the one > selected by the algorithm. [BoB] Yes, when taking overhead into account that becomes the conclusion, a= nd I think we should follow RFC5104. >=20 > 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 complet= ely 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 limitatio= n by sending a TMMBN with itself as owner > of the TMMBR 0 limitation. [BoB] Agreed. This is conformant to RFC5014. I will try to find some good t= ext for it in the next version. See also my question above on how much clar= ifying text we want to add. >=20 >=20 > 4. Section 6.2: >=20 > 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. >=20 > 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 receive= r in this context. This becomes especially > important in the next > paragraph: >=20 > 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. >=20 > How does the media sender determine that there is not only a single recei= ver. 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: >=20 > Only one CNAME in use among all SSRCs received (CSRC do not matter if the= y 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 c= ases that fails to be correctly classified when > using CNAME. >=20 > Thus, I suggest aligning the solutions here. [BoB] Agree. This sounds like a good approach and very reasonable! >=20 > 5. Section 6.3: >=20 > 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. >=20 > I think the later part of the sentence needs an escape clause for the cas= e 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. [BoB] If it receives a RESUME it is no longer in the described state, but I= can add clarifying text for that. >=20 > 6. Section 6.3.2: > Any > streams that were paused by that removed participant SHALL be > resumed. >=20 > I think a SSRC should be added or replace "participant" in the above sent= ence. [BoB] OK, suggest SSRC is added. >=20 > 7. Section 6.4: >=20 > 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). >=20 > The exception of a RESUME prior to having concluded on the repetition of = the PAUSED Indication? [BoB] OK. As a similar comment above, then it is no longer in that state, b= ut I can add clarifying text. >=20 > 8. Section 6.4: >=20 > 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. >=20 > I think it needs to be clarified what "leaving the state" means and who i= s performing this leaving in this case. Yes, that is > the media sender, but its responsibility for doing this should be clarifi= ed. See issue 2, so this does not become a dead lock > situation. [BoB] OK. The intent is that since local paused state is entered based on l= ocal considerations, the state can similarly only be left through local con= sideration, and it is thus a local decision in the media sender. I can add = some text that the state SHOULD be left (becoming Playing) as soon as the c= ondition that caused the local pause clears. That way, the text will not be= dependent on what the remote peer(s) sent during the local pause, or requi= re that the local peer remembers how many of the remote peers that (ineffec= tively) tried to PAUSE or RESUME while in local pause. The exception to tha= t is when using TMMBR/TMMBN and when the remote peer sent a TMMBR 0 with a = higher overhead value than the local peer has, in which case the local part= y cannot (formally) exit the paused state until remote sends a TMMBR >0. Wo= uld that address your concerns? >=20 > 9. Section 8.1: >=20 > 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. >=20 > 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. [BoB] Reasonable. OK. >=20 > 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. >=20 > I think "RTP extended highest sequence number" shall contain a reference = to Section 6.4.1 of RFC 3550. [BoB] OK. >=20 > 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? [BoB] OK. I can re-formulate to allow for extensions, especially since we a= lready have hooks for such in the document. >=20 > 11. Section 7: >=20 > I wonder if there should be some definitions that ensure that one can ext= ended 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 parameter= s this is going to be impossible. Instead one > will have to define new sub-message types which the implementation doesn'= t know of. >=20 > I would also note that the specification is not clear on that an implemen= tation SHALL ignore FCIs with unknown types, that > should be added. [BoB] OK. >=20 > 12. Section 9. >=20 > 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. >=20 > 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 genera= l 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. [BoB] Seems reasonable. Would you consider suggesting some text? >=20 > 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. >=20 > I was wondering if there is a point to define that if one signals both "t= mmbr" and "pause" one MUST be capable of > handling pause functionality where applicable using TMMBR 0? [BoB] Sounds reasonable to me. What do others think? >=20 > 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. >=20 > I wonder if the first "MAY" should be a "MUST" instead. I think it is rea= sonable that implementation are cable of ignoring > messages that they declared they can't support. In multi-endpoint cases t= here might be some sub-set that perform > certain operations and others that do a fuller set, when this do not coll= ide. [BoB] Agree. OK. >=20 > 15. Section 9, Figure 7: > rtcp-fb-ccm-param =3D/ SP "pause" [SP pause-attr] > pause-attr =3D [pause-config] [SP "nowait"] [SP byte-string] > pause-config =3D "config=3D" pause-config-value > pause-config-value =3D %x31-38 > ; byte-string as defined in RFC 4566, for future extensions >=20 > I think there is an error in this specification. If one excludes the "pau= se-config" then one ends up with "pause nowait", > i.e. two spaces between the pause type and its other parameters. >=20 > I think the ABNF could be adjusted to read like this: >=20 > rtcp-fb-ccm-param =3D/ SP "pause" [pause-attr] > pause-attr =3D [SP pause-config] [SP "nowait"] [SP byte-string= ] > pause-config =3D "config=3D" pause-config-value > pause-config-value =3D %x31-38 ; Config value 1-8 > ; byte-string as defined in RFC 4566, for future extensions >=20 > That would ensure that there is one and only one space between each param= eter. I also note that this definition ends up > with a strict ordering requirement. [BoB] OK. AFAIK we did not intend any ordering requirement by design, but I= also don't think an ordering requirement does any harm to the current text= . Could maybe an ordering requirement make it difficult to add extensions i= n the future? >=20 > Further I wonder if the "pause-config-value =3D %x31-38" would benefit fr= om being defined as pause-config-value =3D > 1*2DIGIT instead? That way future new values for the config could be adde= d 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. [BoB] Receive unknown config value: MUST remove the pause line in the answe= r (not use pause at all)? Do we also need to restrict the sender in an extensible way, like "Implemen= tations of this specification MUST NOT use any other config value than the = ones defined here"? Do you also need to say "but implementations of updates= to this specification MAY use other values" to allow for extensibility? >=20 > I also think there be missing specification what do with any unknown (Fut= ure defined) parameters in a implementation > according to this spec. [BoB] Yes. Suggest MUST ignore and exclude from answer. >=20 > 16. Section 9.1 and 9.2: >=20 > I am missing a discussion of the meaning of PAUSE and TMMBR methods when = both are present in a SDP. [BoB] Agree that this is missing. Suggest that if both are accepted in the = SDP answer, TMMBR/TMMBN MUST NOT be used for pause/resume purposes (with a = bitrate value of 0), to avoid signaling ambiguity. >=20 > 17. Section 9.2: >=20 > First, the "config" attribute and its message directions are > interpreted based on the node receiving the SDP. >=20 > I am think this is missing words on what requirement levels it means to h= ave 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? [BoB] Agree that some text should be added. It is a RECOMMENDED operation c= onfiguration. Nothing will break in such session if streams (from the joining client not = supporting PAUSE) are not paused when requested, since pause/resume is a ba= ndwidth optimization. If a joining client does not support RESUME, it will not be able to prevent= streams from being paused, or receive paused streams until someone else re= sumes them, but such restricted client will also not impact the rest of the= session in any negative way. >=20 > 18. Section 10.2: >=20 > Figure 11 and Figure 12: >=20 > As the example include a PAUSE at t6, shouldn't the corresponding PAUSED = be included as it is a mandated response? [BoB] Yes. Will add it. >=20 > 19. Section 10.4: >=20 > A transport Translator in an RTP session forwards the message from > one peer to all the others. >=20 > I think this text should use the word "Relay" for this type to make it cl= earer in relation to the updated topologies draft. [BoB] OK >=20 > 20. Section 12: >=20 > 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, >=20 > 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. >=20 > 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. >=20 > 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. >=20 >=20 > I think this section needs some work. >=20 > 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 need= s be used. I think a pointer to 7201 is suitable > here. That should be the starting point. >=20 > This leads to the current 1. Which is in cases where only group authentic= ation, 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. >=20 > Thirdly, I don't understand the man-in-the-middle attack here. The only a= ddition 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 prov= ide identities that can be used in source > authentication of any signalling messages. >=20 > My initial proposal for a new section is below. >=20 > 12. Security Considerations >=20 > 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. >=20 > 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]. >=20 > 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. >=20 > 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. >=20 > 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. [BoB] I think this text is significantly better than the previous one. Will= add into next version. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 From nobody Tue Mar 3 04:28:44 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 440F31A00F7 for ; Tue, 3 Mar 2015 04:28:42 -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 TP2JZBkGlrVe for ; Tue, 3 Mar 2015 04:28:40 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 500101A1F02 for ; Tue, 3 Mar 2015 04:28:39 -0800 (PST) X-AuditID: c1b4fb25-f79446d000003f3f-05-54f5a8f5f70c Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 3C.36.16191.5F8A5F45; Tue, 3 Mar 2015 13:28:37 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.118]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0210.002; Tue, 3 Mar 2015 13:28:36 +0100 From: Bo Burman To: Magnus Westerlund , Bernard Aboba , "avtext@ietf.org" Thread-Topic: [avtext] Comments on transport terminology in draft-ietf-avtext-rtp-grouping-taxonomy-05 Thread-Index: AQHQTtU74ArKVgsRhUyTOAP0z2nQCJ0I/0aggAArWQCAAYvL0A== Date: Tue, 3 Mar 2015 12:28:35 +0000 Message-ID: References: <54CBA5AF.7040006@ericsson.com>, , <54D8D6F6.4070104@ericsson.com>, , <54F46514.8050905@ericsson.com> In-Reply-To: <54F46514.8050905@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvje7XFV9DDB48kLb4eO8Gq8X+JZeZ HZg8HvecYfNYsuQnUwBTFJdNSmpOZllqkb5dAlfGrVmn2Qs+O1Wc7vjD3sD4ybiLkYNDQsBE 4ugq5S5GTiBTTOLCvfVsXYxcHEICRxglFsy8yQzhLGaUaNl/iAWkik1AQ2L+jruMIAkRgQ5G iY8v/zOBJIQF0iUWfdsKZosIZEhc23yFEcJ2kvi6dAY7iM0ioCLx4+srZhCbV8BX4siWw2wg tpDAfGaJZxfrQS7iFNCR+NUoBBJmFJCVuP/9HtheZgFxiVtP5jNBXCogsWTPeWYIW1Ti5eN/ rBC2osTV6cuZIOr1JG5MncIGYWtLLFv4GmqtoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKK UbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQTIzBODm75rbqD8fIbx0OMAhyMSjy8G5S/hgixJpYV V+YeYpTmYFES57UzPhQiJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVElvqX/j8hjQe/UOwrP br5d5rPbc3vHyc6Nl4yKqnl2LhHjK+Rbe51t3ZGSNo5Xcw+Jzk7annq9dM/H9Tvfs0w5/kn1 Ov/6Zb5cb8zeybgbGiUa/WRKvaUV+eTNbrGqc6vmvn17OZN/94I6s7f31eNUrm2NP9rXKs/0 w2LB1PqWi1OzpvU80IhWYinOSDTUYi4qTgQAK+/S3HQCAAA= 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: Tue, 03 Mar 2015 12:28:42 -0000 I can agree that 3.5 and 3.8 have significant overlap and would probably be= nefit from a merge (into a new 3.7, then). I don't think "Scalable Coding Transport" is a good heading in a section de= scribing "Concepts of Inter-Relations". Would keeping "Layered Multi-Stream= ", changing it to "Scalable Encoding", or something else (what?) be a good = heading for that new 3.7? When thinking about it, I wonder if that merged new section should preferab= ly refrain as much as possible from mentioning the unclear MST/SST terminol= ogy, concentrating on the new terms? The type of descriptive text on MST/SS= T suggested by Bernard should perhaps rather be included in sub-section(s) = in section 4, describing them as existing terms, and probably refer back to= the new 3.7? Cheers, Bo > -----Original Message----- > From: Magnus Westerlund > Sent: den 2 mars 2015 14:27 > To: Bo Burman; Bernard Aboba; avtext@ietf.org > Subject: Re: [avtext] Comments on transport terminology in draft-ietf-avt= ext-rtp-grouping-taxonomy-05 >=20 > Hi, >=20 > Having reviewed the text in 3.5 and 3.8 I think it is very reasonable to = go the proposed and focusing on defining the terms > to use in the future for these configurations. I must however note that 3= .8 has significant overlap, and thus I think one > should combine 3.5 and 3.8 into a Scalable Coding Transport, and have the= definition and the example figure etc. in one > section. >=20 > Views on this? >=20 > /Magnus >=20 >=20 > On 2015-03-02 11:50, Bo Burman wrote: > > I wonder if your comments below at least partially relates to the fact > > that the text in the first part of 3.5 can be read as stating a design > > fact for "scalable media codecs", rather than describing a non-wanted > > and ambiguous definition in RFC 6190 that this draft would like to > > clarify and enhance? > > > > > > > > Would it help if the text is changed to more clearly state what is the > > current situation, in what way it is ambiguous (maybe using words > > similar to yours below), and somehow makes it even more clear (text > > suggestion would be highly appreciated) that this draft suggests to > > use other terminology? > > > > > > > > Further responses inline. > > > > > > > > Cheers, > > > > Bo > > > > > > > > *From:*avtext [mailto:avtext-bounces@ietf.org] *On Behalf Of *Bernard > > Aboba > > *Sent:* den 22 februari 2015 20:25 > > *To:* avtext@ietf.org > > *Subject:* Re: [avtext] Comments on transport terminology in > > draft-ietf-avtext-rtp-grouping-taxonomy-05 > > > > > > > > A few comments on Section 3.5: > > > > > > > > > > 3.5 > > . > > Single- and Multi-Session Transmission of Dependent Streams > > > > > > > > > > > > Scalable media coding formats such as, for example, H.264 based SVC > > > > [RFC6190 ] has two modes of ope= ration: > > > > > > > > 1. In Single Session Transmission (SST), the SVC Media Encoder > > sends > > > > Encoded Streams (Section 2.1.7 > > > 5#section-2.1.7>) and Dependent Streams > > > > (Section 2.1.8 > > > 5#section-2.1.8>) as a single RTP Stream (Section 2.1.10 > > > 5#section-2.1.10>) in a > > > > single RTP Session (Section 2.2.2 > > > 5#section-2.2.2>), using the SVC RTP Payload > > > > format. > > > > > > > > [BA] I do not believe this is accurate. The term SST as defined in RFC= 6190 appears to have different meanings within > different sections of the document. In sections relating to packetizatio= n, it appears to be synonymous with a single RTP > Stream, since use of multiple streams requires support for the DON field.= However, in other sections (such in referring to > SDP), the SST/MST terminology really does appear to refer to single versu= s multiple RTP sessions. > > > > */[BoB] I agree that use of SST/MST in RFC 6190 is unclear, no > > argument there. :) I'm however not sure I understand what you believe > > to be inaccurate or how you would like to see the text changed? Is the > > text maybe unclear that both Encoded Streams and Dependent Streams are > > sent within one and the same RTP Stream for SST? That is at least what > > is meant, and I can amend the text to say that. I also see no problem > > to add something similar to your text above, describing in what sense > > SST is unclear in RFC 6190./* > > > > > > > > > > > > 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. > > > > > > [BA] The meaning of MST in RFC 6190 is not really that clear. If you ar= e referring to use of the DON field, this is needed > whenever multiple RTP streams are used regardless of whether we are talki= ng about multiple RTP sessions or not. > > > > */[BoB] Yes. It was already suggested to use "two or more" instead of > > "multiple" above, which should be clearer and make the sentence more > > correct. Also here, I see no problems being more explicit in what is > > unclear with MST./* > > > > > > > > > > > > SST denotes one RTP Stream (SSRC) per Media Source in a single RTP > > > > Session. MST denotes one or more RTP Streams (SSRC) per Media > > Source > > > > in each of multiple RTP Sessions. The above is not unambiguously > > > > specified in the SVC payload format text [RFC6190 > > ], but it is what > > > > existing deployments of that RFC have implemented. > > > > > > [BA] The use of multiple RTP streams within a single RTP session is in = fact implemented - this is what was implemented > in Lync 2013. > > > > */[BoB] Then the text should be changed accordingly! Maybe we should > > just refrain from talking about what "existing deployments" do or > > don't do, and remove this paragraph entirely, as text on the > > ambiguities with SST/MST should, with the suggested changes, now be > > addressed directly in items 1 and 2?/* > > > > */ /* > > > > > > > > The use of the term "RTP Session" in the SST/MST definition is > > > > somewhat misleading, since a single RTP Session can contain > > multiple > > > > RTP Streams. > > > > > > [BA] My advice would be to point out the ambiguities in RFC 6190 > > SST/MST terminology, while not attempting to fix them retroactively. > > Overall, it is more productive > > > > to focus this document on the new SRST/MRST/MRMT terminology. > > > > */[BoB] Fully agree! Would the changes suggested above address your > > concerns of not fixing SST/MST, but rather describe what is unclear > > with SST/MST, and focus on the new terminology?/* > > > > > > Also, it is sometimes useful to make a distinction > > > > between using a single Media Transport or multiple separate Media > > > > Transports when (in both cases) using multiple RTP Streams to carry > > > > Encoded Streams and Dependent Streams for a Media Source. > > Therefore, > > > > herein the following new terminology is defined: > > > > > > > > SRST: Single RTP Stream on a Single Media Transport > > > > > > > > MRST: Multiple RTP Streams on a Single Media Transport > > > > > > > > MRMT: Multiple RTP Streams on Multiple Media Transports > > > > > > > > > > > > _______________________________________________ > > avtext mailing list > > avtext@ietf.org > > https://www.ietf.org/mailman/listinfo/avtext > > >=20 >=20 > -- >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From nobody Tue Mar 3 06:52:55 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 4DB941A87A6 for ; Tue, 3 Mar 2015 06:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=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 0_rstcGOTKPv for ; Tue, 3 Mar 2015 06:52:51 -0800 (PST) Received: from BLU004-OMC3S25.hotmail.com (blu004-omc3s25.hotmail.com [65.55.116.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FF761A6F38 for ; Tue, 3 Mar 2015 06:52:51 -0800 (PST) Received: from BLU406-EAS172 ([65.55.116.72]) by BLU004-OMC3S25.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 3 Mar 2015 06:52:50 -0800 X-TMN: [A+B4MLpX/bgTdWEIMGqe2sdvjubQ1MEE] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 References: <54CBA5AF.7040006@ericsson.com> <54D8D6F6.4070104@ericsson.com> <54F46514.8050905@ericsson.com> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: Date: Tue, 3 Mar 2015 09:52:44 -0500 To: Bo Burman X-OriginalArrivalTime: 03 Mar 2015 14:52:50.0255 (UTC) FILETIME=[B84875F0:01D055C1] Archived-At: Cc: "avtext@ietf.org" 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: Tue, 03 Mar 2015 14:52:54 -0000 Rm9jdXNpbmcgb24gdGhlIG5ldyB0ZXJtcyBzZWVtcyBsaWtlIGEgYmV0dGVyIGlkZWEgdG8gbWUu IA0KDQoNCg0KPiBPbiBNYXIgMywgMjAxNSwgYXQgNzoyOCBBTSwgQm8gQnVybWFuIDxiby5idXJt YW5AZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gDQo+IEkgY2FuIGFncmVlIHRoYXQgMy41IGFuZCAz LjggaGF2ZSBzaWduaWZpY2FudCBvdmVybGFwIGFuZCB3b3VsZCBwcm9iYWJseSBiZW5lZml0IGZy b20gYSBtZXJnZSAoaW50byBhIG5ldyAzLjcsIHRoZW4pLg0KPiANCj4gSSBkb24ndCB0aGluayAi U2NhbGFibGUgQ29kaW5nIFRyYW5zcG9ydCIgaXMgYSBnb29kIGhlYWRpbmcgaW4gYSBzZWN0aW9u IGRlc2NyaWJpbmcgIkNvbmNlcHRzIG9mIEludGVyLVJlbGF0aW9ucyIuIFdvdWxkIGtlZXBpbmcg IkxheWVyZWQgTXVsdGktU3RyZWFtIiwgY2hhbmdpbmcgaXQgdG8gIlNjYWxhYmxlIEVuY29kaW5n Iiwgb3Igc29tZXRoaW5nIGVsc2UgKHdoYXQ/KSBiZSBhIGdvb2QgaGVhZGluZyBmb3IgdGhhdCBu ZXcgMy43Pw0KPiANCj4gV2hlbiB0aGlua2luZyBhYm91dCBpdCwgSSB3b25kZXIgaWYgdGhhdCBt ZXJnZWQgbmV3IHNlY3Rpb24gc2hvdWxkIHByZWZlcmFibHkgcmVmcmFpbiBhcyBtdWNoIGFzIHBv c3NpYmxlIGZyb20gbWVudGlvbmluZyB0aGUgdW5jbGVhciBNU1QvU1NUIHRlcm1pbm9sb2d5LCBj b25jZW50cmF0aW5nIG9uIHRoZSBuZXcgdGVybXM/IFRoZSB0eXBlIG9mIGRlc2NyaXB0aXZlIHRl eHQgb24gTVNUL1NTVCBzdWdnZXN0ZWQgYnkgQmVybmFyZCBzaG91bGQgcGVyaGFwcyByYXRoZXIg YmUgaW5jbHVkZWQgaW4gc3ViLXNlY3Rpb24ocykgaW4gc2VjdGlvbiA0LCBkZXNjcmliaW5nIHRo ZW0gYXMgZXhpc3RpbmcgdGVybXMsIGFuZCBwcm9iYWJseSByZWZlciBiYWNrIHRvIHRoZSBuZXcg My43Pw0KPiANCj4gQ2hlZXJzLA0KPiBCbw0KPiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+PiBGcm9tOiBNYWdudXMgV2VzdGVybHVuZA0KPj4gU2VudDogZGVuIDIgbWFycyAyMDE1 IDE0OjI3DQo+PiBUbzogQm8gQnVybWFuOyBCZXJuYXJkIEFib2JhOyBhdnRleHRAaWV0Zi5vcmcN Cj4+IFN1YmplY3Q6IFJlOiBbYXZ0ZXh0XSBDb21tZW50cyBvbiB0cmFuc3BvcnQgdGVybWlub2xv Z3kgaW4gZHJhZnQtaWV0Zi1hdnRleHQtcnRwLWdyb3VwaW5nLXRheG9ub215LTA1DQo+PiANCj4+ IEhpLA0KPj4gDQo+PiBIYXZpbmcgcmV2aWV3ZWQgdGhlIHRleHQgaW4gMy41IGFuZCAzLjggSSB0 aGluayBpdCBpcyB2ZXJ5IHJlYXNvbmFibGUgdG8gZ28gdGhlIHByb3Bvc2VkIGFuZCBmb2N1c2lu ZyBvbiBkZWZpbmluZyB0aGUgdGVybXMNCj4+IHRvIHVzZSBpbiB0aGUgZnV0dXJlIGZvciB0aGVz ZSBjb25maWd1cmF0aW9ucy4gSSBtdXN0IGhvd2V2ZXIgbm90ZSB0aGF0IDMuOCBoYXMgc2lnbmlm aWNhbnQgb3ZlcmxhcCwgYW5kIHRodXMgSSB0aGluayBvbmUNCj4+IHNob3VsZCBjb21iaW5lIDMu NSBhbmQgMy44IGludG8gYSBTY2FsYWJsZSBDb2RpbmcgVHJhbnNwb3J0LCBhbmQgaGF2ZSB0aGUg ZGVmaW5pdGlvbiBhbmQgdGhlIGV4YW1wbGUgZmlndXJlIGV0Yy4gaW4gb25lDQo+PiBzZWN0aW9u Lg0KPj4gDQo+PiBWaWV3cyBvbiB0aGlzPw0KPj4gDQo+PiAvTWFnbnVzDQo+PiANCj4+IA0KPj4+ IE9uIDIwMTUtMDMtMDIgMTE6NTAsIEJvIEJ1cm1hbiB3cm90ZToNCj4+PiBJIHdvbmRlciBpZiB5 b3VyIGNvbW1lbnRzIGJlbG93IGF0IGxlYXN0IHBhcnRpYWxseSByZWxhdGVzIHRvIHRoZSBmYWN0 DQo+Pj4gdGhhdCB0aGUgdGV4dCBpbiB0aGUgZmlyc3QgcGFydCBvZiAzLjUgY2FuIGJlIHJlYWQg YXMgc3RhdGluZyBhIGRlc2lnbg0KPj4+IGZhY3QgZm9yICJzY2FsYWJsZSBtZWRpYSBjb2RlY3Mi LCByYXRoZXIgdGhhbiBkZXNjcmliaW5nIGEgbm9uLXdhbnRlZA0KPj4+IGFuZCBhbWJpZ3VvdXMg ZGVmaW5pdGlvbiBpbiBSRkMgNjE5MCB0aGF0IHRoaXMgZHJhZnQgd291bGQgbGlrZSB0bw0KPj4+ IGNsYXJpZnkgYW5kIGVuaGFuY2U/DQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gV291bGQgaXQgaGVs cCBpZiB0aGUgdGV4dCBpcyBjaGFuZ2VkIHRvIG1vcmUgY2xlYXJseSBzdGF0ZSB3aGF0IGlzIHRo ZQ0KPj4+IGN1cnJlbnQgc2l0dWF0aW9uLCBpbiB3aGF0IHdheSBpdCBpcyBhbWJpZ3VvdXMgKG1h eWJlIHVzaW5nIHdvcmRzDQo+Pj4gc2ltaWxhciB0byB5b3VycyBiZWxvdyksIGFuZCBzb21laG93 IG1ha2VzIGl0IGV2ZW4gbW9yZSBjbGVhciAodGV4dA0KPj4+IHN1Z2dlc3Rpb24gd291bGQgYmUg aGlnaGx5IGFwcHJlY2lhdGVkKSB0aGF0IHRoaXMgZHJhZnQgc3VnZ2VzdHMgdG8NCj4+PiB1c2Ug b3RoZXIgdGVybWlub2xvZ3k/DQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gRnVydGhlciByZXNwb25z ZXMgaW5saW5lLg0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IENoZWVycywNCj4+PiANCj4+PiBCbw0K Pj4+IA0KPj4+IA0KPj4+IA0KPj4+ICpGcm9tOiphdnRleHQgW21haWx0bzphdnRleHQtYm91bmNl c0BpZXRmLm9yZ10gKk9uIEJlaGFsZiBPZiAqQmVybmFyZA0KPj4+IEFib2JhDQo+Pj4gKlNlbnQ6 KiBkZW4gMjIgZmVicnVhcmkgMjAxNSAyMDoyNQ0KPj4+ICpUbzoqIGF2dGV4dEBpZXRmLm9yZw0K Pj4+ICpTdWJqZWN0OiogUmU6IFthdnRleHRdIENvbW1lbnRzIG9uIHRyYW5zcG9ydCB0ZXJtaW5v bG9neSBpbg0KPj4+IGRyYWZ0LWlldGYtYXZ0ZXh0LXJ0cC1ncm91cGluZy10YXhvbm9teS0wNQ0K Pj4+IA0KPj4+IA0KPj4+IA0KPj4+IEEgZmV3IGNvbW1lbnRzIG9uIFNlY3Rpb24gMy41Og0KPj4+ IA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+ICAgICAgMy41DQo+Pj4gICAgICA8aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYXZ0ZXh0LXJ0cC1ncm91cGluZy10YXhvbm9teS0w NSNzZWN0aW9uLTMuNT4uDQo+Pj4gICAgICBTaW5nbGUtIGFuZCBNdWx0aS1TZXNzaW9uIFRyYW5z bWlzc2lvbiBvZiBEZXBlbmRlbnQgU3RyZWFtcw0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+ IA0KPj4+ICAgU2NhbGFibGUgbWVkaWEgY29kaW5nIGZvcm1hdHMgc3VjaCBhcywgZm9yIGV4YW1w bGUsIEguMjY0IGJhc2VkIFNWQw0KPj4+IA0KPj4+ICAgW1JGQzYxOTAgPGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM2MTkwPl0gaGFzIHR3byBtb2RlcyBvZiBvcGVyYXRpb246DQo+Pj4g DQo+Pj4gDQo+Pj4gDQo+Pj4gICAxLiAgSW4gU2luZ2xlIFNlc3Npb24gVHJhbnNtaXNzaW9uIChT U1QpLCB0aGUgU1ZDIE1lZGlhIEVuY29kZXINCj4+PiBzZW5kcw0KPj4+IA0KPj4+ICAgICAgIEVu Y29kZWQgU3RyZWFtcyAoU2VjdGlvbiAyLjEuNw0KPj4+IDxodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1hdnRleHQtcnRwLWdyb3VwaW5nLXRheG9ub215LTANCj4+PiA1I3Nl Y3Rpb24tMi4xLjc+KSBhbmQgRGVwZW5kZW50IFN0cmVhbXMNCj4+PiANCj4+PiAgICAgICAoU2Vj dGlvbiAyLjEuOA0KPj4+IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1h dnRleHQtcnRwLWdyb3VwaW5nLXRheG9ub215LTANCj4+PiA1I3NlY3Rpb24tMi4xLjg+KSBhcyBh IHNpbmdsZSBSVFAgU3RyZWFtIChTZWN0aW9uIDIuMS4xMA0KPj4+IDxodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hdnRleHQtcnRwLWdyb3VwaW5nLXRheG9ub215LTANCj4+ PiA1I3NlY3Rpb24tMi4xLjEwPikgaW4gYQ0KPj4+IA0KPj4+ICAgICAgIHNpbmdsZSBSVFAgU2Vz c2lvbiAoU2VjdGlvbiAyLjIuMg0KPj4+IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1hdnRleHQtcnRwLWdyb3VwaW5nLXRheG9ub215LTANCj4+PiA1I3NlY3Rpb24tMi4y LjI+KSwgdXNpbmcgdGhlIFNWQyBSVFAgUGF5bG9hZA0KPj4+IA0KPj4+ICAgICAgIGZvcm1hdC4N Cj4+PiANCj4+PiANCj4+PiANCj4+PiBbQkFdIEkgZG8gbm90IGJlbGlldmUgdGhpcyBpcyBhY2N1 cmF0ZS4gIFRoZSB0ZXJtIFNTVCBhcyBkZWZpbmVkIGluIFJGQyA2MTkwIGFwcGVhcnMgdG8gaGF2 ZSBkaWZmZXJlbnQgbWVhbmluZ3Mgd2l0aGluDQo+PiBkaWZmZXJlbnQgc2VjdGlvbnMgb2YgdGhl IGRvY3VtZW50LiAgSW4gc2VjdGlvbnMgcmVsYXRpbmcgdG8gcGFja2V0aXphdGlvbiwgaXQgYXBw ZWFycyB0byBiZSBzeW5vbnltb3VzIHdpdGggYSBzaW5nbGUgUlRQDQo+PiBTdHJlYW0sIHNpbmNl IHVzZSBvZiBtdWx0aXBsZSBzdHJlYW1zIHJlcXVpcmVzIHN1cHBvcnQgZm9yIHRoZSBET04gZmll bGQuICBIb3dldmVyLCBpbiBvdGhlciBzZWN0aW9ucyAoc3VjaCBpbiByZWZlcnJpbmcgdG8NCj4+ IFNEUCksIHRoZSBTU1QvTVNUIHRlcm1pbm9sb2d5IHJlYWxseSBkb2VzIGFwcGVhciB0byByZWZl ciB0byBzaW5nbGUgdmVyc3VzIG11bHRpcGxlIFJUUCBzZXNzaW9ucy4NCj4+PiANCj4+PiAqL1tC b0JdIEkgYWdyZWUgdGhhdCB1c2Ugb2YgU1NUL01TVCBpbiBSRkMgNjE5MCBpcyB1bmNsZWFyLCBu bw0KPj4+IGFyZ3VtZW50IHRoZXJlLiA6KSAgSSdtIGhvd2V2ZXIgbm90IHN1cmUgSSB1bmRlcnN0 YW5kIHdoYXQgeW91IGJlbGlldmUNCj4+PiB0byBiZSBpbmFjY3VyYXRlIG9yIGhvdyB5b3Ugd291 bGQgbGlrZSB0byBzZWUgdGhlIHRleHQgY2hhbmdlZD8gSXMgdGhlDQo+Pj4gdGV4dCBtYXliZSB1 bmNsZWFyIHRoYXQgYm90aCBFbmNvZGVkIFN0cmVhbXMgYW5kIERlcGVuZGVudCBTdHJlYW1zIGFy ZQ0KPj4+IHNlbnQgd2l0aGluIG9uZSBhbmQgdGhlIHNhbWUgUlRQIFN0cmVhbSBmb3IgU1NUPyBU aGF0IGlzIGF0IGxlYXN0IHdoYXQNCj4+PiBpcyBtZWFudCwgYW5kIEkgY2FuIGFtZW5kIHRoZSB0 ZXh0IHRvIHNheSB0aGF0LiBJIGFsc28gc2VlIG5vIHByb2JsZW0NCj4+PiB0byBhZGQgc29tZXRo aW5nIHNpbWlsYXIgdG8geW91ciB0ZXh0IGFib3ZlLCBkZXNjcmliaW5nIGluIHdoYXQgc2Vuc2UN Cj4+PiBTU1QgaXMgdW5jbGVhciBpbiBSRkMgNjE5MC4vKg0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+ IA0KPj4+IA0KPj4+ICAgMi4gIEluIE11bHRpLVNlc3Npb24gVHJhbnNtaXNzaW9uIChNU1QpLCB0 aGUgU1ZDIE1lZGlhIEVuY29kZXINCj4+PiBzZW5kcw0KPj4+IA0KPj4+ICAgICAgIEVuY29kZWQg U3RyZWFtcyBhbmQgRGVwZW5kZW50IFN0cmVhbXMgZGlzdHJpYnV0ZWQgYWNyb3NzDQo+Pj4gbXVs dGlwbGUNCj4+PiANCj4+PiAgICAgICBSVFAgU3RyZWFtcyBpbiBvbmUgb3IgbW9yZSBSVFAgU2Vz c2lvbnMuDQo+Pj4gDQo+Pj4gDQo+Pj4gW0JBXSBUaGUgbWVhbmluZyBvZiBNU1QgaW4gUkZDIDYx OTAgaXMgbm90IHJlYWxseSB0aGF0IGNsZWFyLiBJZiB5b3UgYXJlIHJlZmVycmluZyB0byB1c2Ug b2YgdGhlIERPTiBmaWVsZCwgdGhpcyBpcyBuZWVkZWQNCj4+IHdoZW5ldmVyIG11bHRpcGxlIFJU UCBzdHJlYW1zIGFyZSB1c2VkIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciB3ZSBhcmUgdGFsa2luZyBh Ym91dCBtdWx0aXBsZSBSVFAgc2Vzc2lvbnMgb3Igbm90Lg0KPj4+IA0KPj4+ICovW0JvQl0gWWVz LiBJdCB3YXMgYWxyZWFkeSBzdWdnZXN0ZWQgdG8gdXNlICJ0d28gb3IgbW9yZSIgaW5zdGVhZCBv Zg0KPj4+ICJtdWx0aXBsZSIgYWJvdmUsIHdoaWNoIHNob3VsZCBiZSBjbGVhcmVyIGFuZCBtYWtl IHRoZSBzZW50ZW5jZSBtb3JlDQo+Pj4gY29ycmVjdC4gQWxzbyBoZXJlLCBJIHNlZSBubyBwcm9i bGVtcyBiZWluZyBtb3JlIGV4cGxpY2l0IGluIHdoYXQgaXMNCj4+PiB1bmNsZWFyIHdpdGggTVNU Li8qDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gICBTU1QgZGVub3RlcyBvbmUg UlRQIFN0cmVhbSAoU1NSQykgcGVyIE1lZGlhIFNvdXJjZSBpbiBhIHNpbmdsZSBSVFANCj4+PiAN Cj4+PiAgIFNlc3Npb24uICBNU1QgZGVub3RlcyBvbmUgb3IgbW9yZSBSVFAgU3RyZWFtcyAoU1NS QykgcGVyIE1lZGlhDQo+Pj4gU291cmNlDQo+Pj4gDQo+Pj4gICBpbiBlYWNoIG9mIG11bHRpcGxl IFJUUCBTZXNzaW9ucy4gIFRoZSBhYm92ZSBpcyBub3QgdW5hbWJpZ3VvdXNseQ0KPj4+IA0KPj4+ ICAgc3BlY2lmaWVkIGluIHRoZSBTVkMgcGF5bG9hZCBmb3JtYXQgdGV4dCBbUkZDNjE5MA0KPj4+ IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjE5MD5dLCBidXQgaXQgaXMgd2hhdA0K Pj4+IA0KPj4+ICAgZXhpc3RpbmcgZGVwbG95bWVudHMgb2YgdGhhdCBSRkMgaGF2ZSBpbXBsZW1l bnRlZC4NCj4+PiANCj4+PiANCj4+PiBbQkFdIFRoZSB1c2Ugb2YgbXVsdGlwbGUgUlRQIHN0cmVh bXMgd2l0aGluIGEgc2luZ2xlIFJUUCBzZXNzaW9uIGlzIGluIGZhY3QgaW1wbGVtZW50ZWQgLSB0 aGlzIGlzIHdoYXQgd2FzIGltcGxlbWVudGVkDQo+PiBpbiBMeW5jIDIwMTMuDQo+Pj4gDQo+Pj4g Ki9bQm9CXSBUaGVuIHRoZSB0ZXh0IHNob3VsZCBiZSBjaGFuZ2VkIGFjY29yZGluZ2x5ISBNYXli ZSB3ZSBzaG91bGQNCj4+PiBqdXN0IHJlZnJhaW4gZnJvbSB0YWxraW5nIGFib3V0IHdoYXQgImV4 aXN0aW5nIGRlcGxveW1lbnRzIiBkbyBvcg0KPj4+IGRvbid0IGRvLCBhbmQgcmVtb3ZlIHRoaXMg cGFyYWdyYXBoIGVudGlyZWx5LCBhcyB0ZXh0IG9uIHRoZQ0KPj4+IGFtYmlndWl0aWVzIHdpdGgg U1NUL01TVCBzaG91bGQsIHdpdGggdGhlIHN1Z2dlc3RlZCBjaGFuZ2VzLCBub3cgYmUNCj4+PiBh ZGRyZXNzZWQgZGlyZWN0bHkgaW4gaXRlbXMgMSBhbmQgMj8vKg0KPj4+IA0KPj4+ICovIC8qDQo+ Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gICBUaGUgdXNlIG9mIHRoZSB0ZXJtICJSVFAgU2Vzc2lvbiIg aW4gdGhlIFNTVC9NU1QgZGVmaW5pdGlvbiBpcw0KPj4+IA0KPj4+ICAgc29tZXdoYXQgbWlzbGVh ZGluZywgc2luY2UgYSBzaW5nbGUgUlRQIFNlc3Npb24gY2FuIGNvbnRhaW4NCj4+PiBtdWx0aXBs ZQ0KPj4+IA0KPj4+ICAgUlRQIFN0cmVhbXMuDQo+Pj4gDQo+Pj4gDQo+Pj4gW0JBXSBNeSBhZHZp Y2Ugd291bGQgYmUgdG8gcG9pbnQgb3V0IHRoZSBhbWJpZ3VpdGllcyBpbiBSRkMgNjE5MA0KPj4+ IFNTVC9NU1QgdGVybWlub2xvZ3ksIHdoaWxlIG5vdCBhdHRlbXB0aW5nIHRvIGZpeCB0aGVtIHJl dHJvYWN0aXZlbHkuDQo+Pj4gT3ZlcmFsbCwgaXQgaXMgbW9yZSBwcm9kdWN0aXZlDQo+Pj4gDQo+ Pj4gdG8gZm9jdXMgdGhpcyBkb2N1bWVudCBvbiB0aGUgbmV3ICBTUlNUL01SU1QvTVJNVCB0ZXJt aW5vbG9neS4NCj4+PiANCj4+PiAqL1tCb0JdIEZ1bGx5IGFncmVlISBXb3VsZCB0aGUgY2hhbmdl cyBzdWdnZXN0ZWQgYWJvdmUgYWRkcmVzcyB5b3VyDQo+Pj4gY29uY2VybnMgb2Ygbm90IGZpeGlu ZyBTU1QvTVNULCBidXQgcmF0aGVyIGRlc2NyaWJlIHdoYXQgaXMgdW5jbGVhcg0KPj4+IHdpdGgg U1NUL01TVCwgYW5kIGZvY3VzIG9uIHRoZSBuZXcgdGVybWlub2xvZ3k/LyoNCj4+PiANCj4+PiAN Cj4+PiAgIEFsc28sIGl0IGlzIHNvbWV0aW1lcyB1c2VmdWwgdG8gbWFrZSBhIGRpc3RpbmN0aW9u DQo+Pj4gDQo+Pj4gICBiZXR3ZWVuIHVzaW5nIGEgc2luZ2xlIE1lZGlhIFRyYW5zcG9ydCBvciBt dWx0aXBsZSBzZXBhcmF0ZSBNZWRpYQ0KPj4+IA0KPj4+ICAgVHJhbnNwb3J0cyB3aGVuIChpbiBi b3RoIGNhc2VzKSB1c2luZyBtdWx0aXBsZSBSVFAgU3RyZWFtcyB0byBjYXJyeQ0KPj4+IA0KPj4+ ICAgRW5jb2RlZCBTdHJlYW1zIGFuZCBEZXBlbmRlbnQgU3RyZWFtcyBmb3IgYSBNZWRpYSBTb3Vy Y2UuDQo+Pj4gVGhlcmVmb3JlLA0KPj4+IA0KPj4+ICAgaGVyZWluIHRoZSBmb2xsb3dpbmcgbmV3 IHRlcm1pbm9sb2d5IGlzIGRlZmluZWQ6DQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gICBTUlNUOiAg U2luZ2xlIFJUUCBTdHJlYW0gb24gYSBTaW5nbGUgTWVkaWEgVHJhbnNwb3J0DQo+Pj4gDQo+Pj4g DQo+Pj4gDQo+Pj4gICBNUlNUOiAgTXVsdGlwbGUgUlRQIFN0cmVhbXMgb24gYSBTaW5nbGUgTWVk aWEgVHJhbnNwb3J0DQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gICBNUk1UOiAgTXVsdGlwbGUgUlRQ IFN0cmVhbXMgb24gTXVsdGlwbGUgTWVkaWEgVHJhbnNwb3J0cw0KPj4+IA0KPj4+IA0KPj4+IA0K Pj4+IA0KPj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+Pj4gYXZ0ZXh0IG1haWxpbmcgbGlzdA0KPj4+IGF2dGV4dEBpZXRmLm9yZw0KPj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0ZXh0DQo+PiANCj4+IA0K Pj4gLS0NCj4+IA0KPj4gTWFnbnVzIFdlc3Rlcmx1bmQNCj4+IA0KPj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Pj4gU2VydmljZXMsIE1lZGlhIGFuZCBOZXR3b3JrIGZlYXR1cmVzLCBFcmljc3NvbiBSZXNlYXJj aCBFQUIvVFhNDQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiBFcmljc3NvbiBBQiAgICAgICAgICAgICAg ICAgfCBQaG9uZSAgKzQ2IDEwIDcxNDgyODcNCj4+IEbDpHLDtmdhdGFuIDYgICAgICAgICAgICAg ICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5DQo+PiBTRS0xNjQgODAgU3RvY2tob2xtLCBTd2Vk ZW4gfCBtYWlsdG86IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KPj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiANCg== From nobody Thu Mar 5 04:57:18 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 15FDF1A01A9 for ; Thu, 5 Mar 2015 04:57:17 -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 9I4n4w_PlfQ5 for ; Thu, 5 Mar 2015 04:57:15 -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 5AA881A0419 for ; Thu, 5 Mar 2015 04:57:15 -0800 (PST) X-AuditID: c1b4fb2d-f79aa6d00000359d-55-54f852a90e12 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 0F.5F.13725.9A258F45; Thu, 5 Mar 2015 13:57:13 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.210.2; Thu, 5 Mar 2015 13:57:12 +0100 Message-ID: <54F852A7.10503@ericsson.com> Date: Thu, 5 Mar 2015 13:57:11 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Bo Burman , "avtext@ietf.org" References: <54E758B8.50807@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUyM+Jvje7KoB8hBjveK1h8vHeD1eJJyw9m ByaPJUt+Mnns2PyANYApissmJTUnsyy1SN8ugStj7ZRuxoL5/BVnD8U1MM7g6WLk5JAQMJG4 teUPK4QtJnHh3nq2LkYuDiGBI4wSPeenMoMkhASWMUocepEGYvMKaEqcPrqUEcRmEVCROLP+ Algzm4CFxM0fjWwgtqhAsMTP9t1MEPWCEidnPmEBsUUEvCXuzX0L1sssoC3xAqpeWMBRYtX5 VawQu7Ilfu2BsDkF/CRWznjPBFFvIHFk0RxWCFteonnrbKjbtCUamjpYJzAKzkKybhaSlllI WhYwMq9iFC1OLS7OTTcy1kstykwuLs7P08tLLdnECAzWg1t+6+5gXP3a8RCjAAejEg/vhmPf Q4RYE8uKK3MPMUpzsCiJ89oZHwoREkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwJjJkVcy03SN 21z1wJZvB1VFlubOmbO+uerW62wbS71b93YfP95TLLrkmPuzmREC9nml8w0FKt5t26U24+qq c42/KrJuKTkqLZ/w1sy0aKOa7hfmFTsDPs6U/aS/U6K9OmbtK7XErXeuSq6J/1DW6+XeEbX8 3h2pFvXH5ps/tbzdZSIhM+cku6gSS3FGoqEWc1FxIgDwpbNYNwIAAA== Archived-At: Subject: Re: [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: Thu, 05 Mar 2015 12:57:17 -0000 WG, Here is my text proposal for issue 12. On 2015-03-03 13:01, Bo Burman wrote: >> >> 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. > [BoB] Seems reasonable. Would you consider suggesting some text? > > Here is my proposal to add before the last paragraph in Section 9. The pause functionality can normally be expected to work independent of the payload type. However, there might exist situations where an endpoint likes to restrict or at least differently configure the capabilities depending on the payload type carrying the media stream. Reasons for this might relate to capabilities to correctly handle media boundaries and avoid any pause or resume operation to occur where it would leave an receiver or decoder with no choice than to attempt to repair or discard the media received just prior or at the point of resuming. 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 Thu Mar 5 05:07: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 74BD21A8776; Thu, 5 Mar 2015 05:07:43 -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 ly5qeLuYjkjE; Thu, 5 Mar 2015 05:07:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1E71A1A6C; Thu, 5 Mar 2015 05:07:40 -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.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305130740.7455.14158.idtracker@ietfa.amsl.com> Date: Thu, 05 Mar 2015 05:07:40 -0800 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-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: Thu, 05 Mar 2015 13:07:43 -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 : A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources Authors : Jonathan Lennox Kevin Gross Suhas Nandakumar Gonzalo Salgueiro Bo Burman Filename : draft-ietf-avtext-rtp-grouping-taxonomy-06.txt Pages : 44 Date : 2015-03-05 Abstract: The terminology about, and associations among, Real-Time Transport Protocol (RTP) sources can be complex and somewhat opaque. This document describes a number of existing and proposed relationships among RTP sources, and attempts to define common terminology for discussing protocol entities and their relationships. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxonomy/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rtp-grouping-taxonomy-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 Thu Mar 5 05:19:50 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 2775B1B2A15 for ; Thu, 5 Mar 2015 05:19:50 -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 HIsRVooGj91G for ; Thu, 5 Mar 2015 05:19:48 -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 24ADE1B2A34 for ; Thu, 5 Mar 2015 05:19:47 -0800 (PST) X-AuditID: c1b4fb3a-f79036d000001e94-83-54f857f23e93 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 2A.9B.07828.2F758F45; Thu, 5 Mar 2015 14:19:46 +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; Thu, 5 Mar 2015 14:19:45 +0100 From: Bo Burman To: "avtext@ietf.org" Thread-Topic: I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-06.txt Thread-Index: AQHQV0VuTu+WZGa1pU2cswCSppMo2p0N3N3A Date: Thu, 5 Mar 2015 13:19:45 +0000 Message-ID: References: <20150305130740.7455.14158.idtracker@ietfa.amsl.com> In-Reply-To: <20150305130740.7455.14158.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.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvje6n8B8hBttPS1p8vHeD1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGTN3HGIrmCNV0X7+GUsD4yyRLkZODgkBE4mFs5YyQ9hiEhfu rWfrYuTiEBI4wijx9fAGdghnMaNE66sT7CBVbAIaEvN33GUEsUUE1CXuTL8A1MHOISzgLnGS HSLqIXFg7lsWCNtI4szvtUBxDg4WARWJJY/tQcK8Ar4SzeteMoHYQgIOErva14KVcwo4Snyc +xssziggK3H/+z2wOLOAuMStJ/OZIM4UkFiy5zzUyaISLx//Y4WwFSU+vtrHCFGvI7Fg9yc2 CFtbYtnC18wQewUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYyixanFxbnpRkZ6qUWZycXF +Xl6eaklmxiB8XBwy2+rHYwHnzseYhTgYFTi4d1w7HuIEGtiWXFl7iFGaQ4WJXFeO+NDIUIC 6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYSwUV+RiPXjw96fUZ95tbDrM0P4g/5rFqFleV5+Jq OYuq49mpM+dnG5q+fVARXpl/YYW+XaKZjsjmTR8v+S/psVZ8bVa1acq5tgslFY9FyhP593Ot 3GWqvM/8e2iJZYQAN7uhwK09vG9nnve2msB8rvDgwldfYqy/hGsH24ooOR0+wZudIKylxFKc kWioxVxUnAgAyC5ghmgCAAA= Archived-At: Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-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: Thu, 05 Mar 2015 13:19:50 -0000 This version contains the following changes (list is also in the document): o Clarified that a Redundancy RTP Stream can be used standalone to generate Repaired RTP Streams. o Clarified that (in accordance with above) RTP-based Repair takes zero or more Received RTP Streams and one or more Received Redundancy RTP Streams as input. o Changed Figure 6 to more clearly show that Media Transport is terminated in the Endpoint, not in the Participant. o Added a sentence to Endpoint section that clarifies there may be contexts where a single "host" can serve multiple Participants, making those Endpoints share some properties. o Merged previous section 3.5 on SST/MST with previous section 3.8 on Layered Multi-Stream into a common section discussing the scalable/layered stream relation, and moved improved, descriptive text on SST and MST to new sub-sections 4.7 and 4.13, describing them as existing terms. 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 5 mars 2015 14:08 > To: i-d-announce@ietf.org > Cc: avtext@ietf.org > Subject: I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-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 : A Taxonomy of Grouping Semantics and Mechanisms= for Real-Time Transport Protocol (RTP) Sources > Authors : Jonathan Lennox > Kevin Gross > Suhas Nandakumar > Gonzalo Salgueiro > Bo Burman > Filename : draft-ietf-avtext-rtp-grouping-taxonomy-06.txt > Pages : 44 > Date : 2015-03-05 >=20 > Abstract: > The terminology about, and associations among, Real-Time Transport > Protocol (RTP) sources can be complex and somewhat opaque. This > document describes a number of existing and proposed relationships > among RTP sources, and attempts to define common terminology for > discussing protocol entities and their relationships. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxonomy/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-06 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-rtp-grouping-taxonom= y-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 Thu Mar 5 05:53:40 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 4A5D31B2CF1 for ; Thu, 5 Mar 2015 05:53:39 -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 Tvipzw6QLyq9 for ; Thu, 5 Mar 2015 05:53:35 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A25381B2C91 for ; Thu, 5 Mar 2015 05:51:09 -0800 (PST) X-AuditID: c1b4fb25-f79b76d00000113a-c5-54f85f4b0fb9 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 86.46.04410.B4F58F45; Thu, 5 Mar 2015 14:51:07 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.210.2; Thu, 5 Mar 2015 14:51:06 +0100 Message-ID: <54F85F49.7050401@ericsson.com> Date: Thu, 5 Mar 2015 14:51:05 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Bo Burman , "avtext@ietf.org" References: <20150305130740.7455.14158.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3Rtc7/keIwa4vhhYf791gdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtzrx1gKvipUvO15xdrAeE6yi5GTQ0LAROLwzl5WCFtM4sK9 9WxdjFwcQgJHGCXuvZzFBOEsY5R49fYlWBWvgLbEt4MvgRIcHCwCKhJPd/qDhNkELCRu/mhk A7FFBYIlfrbvZoIoF5Q4OfMJC4gtIuAtcW/uW0aQVmGBAInDZ8IhxjcxSrw5upoRpIZTwE/i zZrr7CA2s4CBxJFFc1ghbHmJ5q2zmUFsIaATGpo6WCcwCsxCsmIWkpZZSFoWMDKvYhQtTi1O yk03MtZLLcpMLi7Oz9PLSy3ZxAgMwYNbfqvuYLz8xvEQowAHoxIP74Zj30OEWBPLiitzDzFK c7AoifPaGR8KERJITyxJzU5NLUgtii8qzUktPsTIxMEp1cBY90c3aYHRhSL5t4t/djzy3j1T /SHj57df9HYaxW49s8FrWqiPf67B9ata29/v2Ca2vMHrR9FFpjAe5ie7xfsW/5RJu9DXZDFR o4XlyZs77LOOZHO3tZau/M/sKtaReo2bs8PPiXfuhu8/NW2jxV1MJn6ufNXMunMNzzyRp/Zc rikeYvIpyu+UWIozEg21mIuKEwFs1wHZIgIAAA== Archived-At: Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-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: Thu, 05 Mar 2015 13:53:39 -0000 WG, I have reviewed these changes and I believe they addresses my comments on the previous version. Thanks Magnus On 2015-03-05 14:19, Bo Burman wrote: > This version contains the following changes (list is also in the document): > > o Clarified that a Redundancy RTP Stream can be used standalone to > generate Repaired RTP Streams. > > o Clarified that (in accordance with above) RTP-based Repair takes > zero or more Received RTP Streams and one or more Received > Redundancy RTP Streams as input. > > o Changed Figure 6 to more clearly show that Media Transport is > terminated in the Endpoint, not in the Participant. > > o Added a sentence to Endpoint section that clarifies there may be > contexts where a single "host" can serve multiple Participants, > making those Endpoints share some properties. > > o Merged previous section 3.5 on SST/MST with previous section 3.8 > on Layered Multi-Stream into a common section discussing the > scalable/layered stream relation, and moved improved, descriptive > text on SST and MST to new sub-sections 4.7 and 4.13, describing > them as existing terms. > > o Editorial improvements. > > Cheers, > Bo > >> -----Original Message----- >> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org >> Sent: den 5 mars 2015 14:08 >> To: i-d-announce@ietf.org >> Cc: avtext@ietf.org >> Subject: I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-06.txt >> >> >> 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 : A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources >> Authors : Jonathan Lennox >> Kevin Gross >> Suhas Nandakumar >> Gonzalo Salgueiro >> Bo Burman >> Filename : draft-ietf-avtext-rtp-grouping-taxonomy-06.txt >> Pages : 44 >> Date : 2015-03-05 >> >> Abstract: >> The terminology about, and associations among, Real-Time Transport >> Protocol (RTP) sources can be complex and somewhat opaque. This >> document describes a number of existing and proposed relationships >> among RTP sources, and attempts to define common terminology for >> discussing protocol entities and their relationships. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxonomy/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-06 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rtp-grouping-taxonomy-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/ >> >> _______________________________________________ >> 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 > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > > -- 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 Thu Mar 5 06:38:14 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 DE0D91A00E8 for ; Thu, 5 Mar 2015 06:38:09 -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 gPIVL-tvsjW5 for ; Thu, 5 Mar 2015 06:38:02 -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 C678F1A000B for ; Thu, 5 Mar 2015 06:34:41 -0800 (PST) X-AuditID: c1b4fb2d-f79aa6d00000359d-3d-54f8697f879f Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 3B.63.13725.F7968F45; Thu, 5 Mar 2015 15:34:39 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.3.210.2; Thu, 5 Mar 2015 15:34:38 +0100 Message-ID: <54F8697B.4050400@ericsson.com> Date: Thu, 5 Mar 2015 15:34:35 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Bo Burman , "avtext@ietf.org" References: <54E758B8.50807@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM+JvjW595o8Qg/cfpS0+3rvBavGk5Qez A5PHkiU/mTx2bH7AGsAUxWWTkpqTWZZapG+XwJXxbNEdxoLvwhULth5mamB8w9/FyMkhIWAi 8X7+QUYIW0ziwr31bF2MXBxCAkcYJfbs6GSBcJYxSvy++JkFpIpXQFti5sR5YB0sAioSzRtf gdlsAhYSN380soHYogLBEj/bdzNB1AtKnJz5BKxXRMBb4t7ct2D1zEBzXkDVCws4Sqw6v4oV xBYSyJb4tQfC5hTwk1g54z0TRL2BxJFFc1ghbHmJ5q2zmSHqtSUamjpYJzAKzkKybhaSlllI WhYwMq9iFC1OLS7OTTcy1kstykwuLs7P08tLLdnECAzYg1t+6+5gXP3a8RCjAAejEg/vhmPf Q4RYE8uKK3MPMUpzsCiJ89oZHwoREkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwOg23S88V6X9 jPSyuyc7PGfnP930ueNQOOcrq2mr50lOYJK0Cjqo+ynu13rzc7M+aPPtOC6+ryr59YzPtlsF z/78dlxdp6/u1fKj5e/eznPvfD5Les96j9m77icfuPaX9cvNN3kvc1ssMr66l/SweeRncU6z n3iaKWL5K71Yibq9PYcrJsXWZx9WYinOSDTUYi4qTgQAr52pvDkCAAA= Archived-At: Subject: Re: [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: Thu, 05 Mar 2015 14:38:10 -0000 Hi, This email is all about issue 13. On 2015-03-03 13:01, Bo Burman wrote: > Thank you for this thorough review! > Please find my responses inline. > > Note that I specifically would like others to comment on a few of Magnus' items: > > > - Item 13: Is there a point to define that if both "ccm tmmbr" and "ccm pause" is included in the SDP, the part sending that SDP MUST be capable of handling corresponding pause functionality using TMMBR/TMMBN 0, as defined in this specification? > >> 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? > [BoB] Sounds reasonable to me. What do others think? > Having looked at this again, I am actually coming to the conclusion that there is no real value in doing what is proposed above. The reason is that it doesn't resolve the ambiguities around using TMMBR for pause. So in an O/A context an offer with both TMMBR and PAUSE will give the answerer the information that Offerer do support pause using TMMBR. However, we are mandating that if the answerer is capable of supporting CCM PAUSE it shall use its functionality, not TMMBR. Thus, if the answerer supports pause, this information is not used. If the answerer refuses PAUSE, then the offerer is in an information vacuum about the intentions of the answerer in regards to pause functionality. Therefore I suggest that we drop the above idea and makes no modifications in regards to the issue. 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 Thu Mar 5 08:09:40 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 407951A1AAD for ; Thu, 5 Mar 2015 08:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 o3XsKtos1WYS for ; Thu, 5 Mar 2015 08:09:29 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BE601A1B05 for ; Thu, 5 Mar 2015 08:05:36 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 798396A530172; Thu, 5 Mar 2015 16:05:27 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t25G5UOg030895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Mar 2015 17:05:30 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.230]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 5 Mar 2015 17:05:30 +0100 From: "DRAGE, Keith (Keith)" To: Bo Burman , "avtext@ietf.org" Thread-Topic: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-06.txt Thread-Index: AQHQV14zsh8RDL36I0e1u3F30me2GQ== Date: Thu, 5 Mar 2015 16:05:29 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B4A10F305@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <20150305130740.7455.14158.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-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: Thu, 05 Mar 2015 16:09:36 -0000 (As WG cochair) Magnus has responded that his addresses his last comments. Bernard also had comments on the last version - have these now been address= ed to his satisfaction? Any other comments that have not been addressed - or can I return to gettin= g the publication request finished? Keith=20 > -----Original Message----- > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Bo Burman > Sent: 05 March 2015 13:20 > To: avtext@ietf.org > Subject: Re: [avtext] I-D Action:=20 > draft-ietf-avtext-rtp-grouping-taxonomy-06.txt >=20 > This version contains the following changes (list is also in=20 > the document): >=20 > o Clarified that a Redundancy RTP Stream can be used standalone to > generate Repaired RTP Streams. >=20 > o Clarified that (in accordance with above) RTP-based Repair takes > zero or more Received RTP Streams and one or more Received > Redundancy RTP Streams as input. >=20 > o Changed Figure 6 to more clearly show that Media Transport is > terminated in the Endpoint, not in the Participant. >=20 > o Added a sentence to Endpoint section that clarifies there may be > contexts where a single "host" can serve multiple Participants, > making those Endpoints share some properties. >=20 > o Merged previous section 3.5 on SST/MST with previous section 3.8 > on Layered Multi-Stream into a common section discussing the > scalable/layered stream relation, and moved improved,=20 > descriptive > text on SST and MST to new sub-sections 4.7 and 4.13, describing > them as existing terms. >=20 > o Editorial improvements. >=20 > Cheers, > Bo >=20 > > -----Original Message----- > > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org]=20 > On Behalf Of=20 > > internet-drafts@ietf.org > > Sent: den 5 mars 2015 14:08 > > To: i-d-announce@ietf.org > > Cc: avtext@ietf.org > > Subject: I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-06.txt > >=20 > >=20 > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > > This draft is a work item of the Audio/Video Transport=20 > Extensions Working Group of the IETF. > >=20 > > Title : A Taxonomy of Grouping Semantics=20 > and Mechanisms for Real-Time Transport Protocol (RTP) Sources > > Authors : Jonathan Lennox > > Kevin Gross > > Suhas Nandakumar > > Gonzalo Salgueiro > > Bo Burman > > Filename : draft-ietf-avtext-rtp-grouping-taxonomy-06.txt > > Pages : 44 > > Date : 2015-03-05 > >=20 > > Abstract: > > The terminology about, and associations among, Real-Time=20 > Transport > > Protocol (RTP) sources can be complex and somewhat opaque. This > > document describes a number of existing and proposed=20 > relationships > > among RTP sources, and attempts to define common terminology for > > discussing protocol entities and their relationships. > >=20 > >=20 > > The IETF datatracker status page for this draft is: > >=20 > https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxono > > my/ > >=20 > > There's also a htmlized version available at: > >=20 > http://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-06 > >=20 > > A diff from the previous version is available at: > >=20 > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-rtp-grouping-taxono > > my-06 > >=20 > >=20 > > Please note that it may take a couple of minutes from the time of=20 > > submission until the htmlized version and diff are=20 > 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=20 > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > = From nobody Mon Mar 9 06:38:33 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 C73E21A889F for ; Mon, 9 Mar 2015 06:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 1pu3ltgDkk0P for ; Mon, 9 Mar 2015 06:38:30 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C59181A888F for ; Mon, 9 Mar 2015 06:38:13 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id D4321313AACD8 for ; Mon, 9 Mar 2015 13:38:09 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t29DcC9E030646 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Mar 2015 14:38:12 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.230]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 14:38:12 +0100 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Thread-Topic: draft-ietf-avtext-splicing-notification Thread-Index: AdBabkh0iZrr+pRuScOClgjAyVIa/w== Date: Mon, 9 Mar 2015 13:38:11 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B4A111EAD@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [avtext] draft-ietf-avtext-splicing-notification 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 Mar 2015 13:38:32 -0000 (As WG cochair) After we agreed that the above draft becomes a working group item, an IPR d= eclaration was received as follows. https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf-avt= ext-splicing-notification The chairs would normally prefer to deal with such IPR issues before adopti= on, but that has been precluded in this case. The chairs would like to ask the working group whether there are any issues= with the working group proceeding with this draft in the face of the above= IPR declaration. Please respond with your position, not matter which direc= tion it is in. If there are issues, then please identify your preferred solution to dealin= g with the issue, i.e. different solution, abandon the work, etc. Regards Keith= From nobody Mon Mar 9 08:38:04 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 CF7BE1A8ACA; Mon, 9 Mar 2015 08:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 TQBan_9HpsgS; Mon, 9 Mar 2015 08:38:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A221A8AE2; Mon, 9 Mar 2015 08:33:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309153326.18657.25479.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 08:33:26 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-stream-pause-07.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: Mon, 09 Mar 2015 15:38:04 -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-07.txt Pages : 54 Date : 2015-03-09 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rtp-stream-pause-07 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 Mon Mar 9 08:48: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 6E56D1A8A4B for ; Mon, 9 Mar 2015 08:48:20 -0700 (PDT) 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 M2Ha1DLvErB4 for ; Mon, 9 Mar 2015 08:48:18 -0700 (PDT) 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 234311A898F for ; Mon, 9 Mar 2015 08:46:37 -0700 (PDT) X-AuditID: c1b4fb3a-f79036d000001e94-41-54fdc05c161b Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 1C.9F.07828.C50CDF45; Mon, 9 Mar 2015 16:46:36 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.118]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0210.002; Mon, 9 Mar 2015 16:46:35 +0100 From: Bo Burman To: "avtext@ietf.org" Thread-Topic: [avtext] I-D Action: draft-ietf-avtext-rtp-stream-pause-07.txt Thread-Index: AQHQWn8REB+Y5JRrg0SRdOmKSLyvop0USYkQ Date: Mon, 9 Mar 2015 15:46:35 +0000 Message-ID: References: <20150309153326.18657.25479.idtracker@ietfa.amsl.com> In-Reply-To: <20150309153326.18657.25479.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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+JvjW7Mgb8hBpc6BS0+3rvB6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPkvVrMWbFKuODXxPHsD4xepLkZODgkBE4nj3/eyQ9hiEhfu rWfrYuTiEBI4wigx//F1FghnMaPE5DvvwKrYBDQk5u+4ywhiiwioS9yZfgGog4NDWMBb4uA7 Voiwj0RLbycrSFhEwEhixTM9kDCLgIrEvY0P2EBsXgFfid2fN4KVCwk4SpzqXgk2kVPASeLX rKVgNqOArMT97/dYQGxmAXGJW0/mM0HcKSCxZM95ZghbVOLl439gqyQEFCWW98tBlOtILNj9 iQ3C1pZYtvA1M8RaQYmTM5+wTGAUnYVk6iwkLbOQtMxC0rKAkWUVo2hxanFxbrqRkV5qUWZy cXF+nl5easkmRmA8HNzy22oH48HnjocYBTgYlXh4C678CRFiTSwrrsw9xCjNwaIkzmtnfChE SCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2OBg0jgWcbjsUWLfzxqWnNlSrh5hL4i85RGt1qd 7weztbIV/9/aUH9YKvfpt1es2nIz/u/kzE8/8mmC2cczZZHTf/Qr6R74Hfnl4o1F+6fZPxV5 E3coTut+l/Mj1ymv0t5nWGx52DI3+0LdJpV3EXdkzTfYi658MMdmvcyC9l3fLZZEFR+v2dqg xFKckWioxVxUnAgA9Kh1I2gCAAA= Archived-At: Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rtp-stream-pause-07.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: Mon, 09 Mar 2015 15:48:20 -0000 This version contains the following changes (list also in the document), wh= ich I believe addresses all of the received comments so far: o Completely rewrote the Security Consideration section. o Aligned text such that REFUSED is always referred to as a notification, not indication. o Added and changed text in several places, clarifying the case when TMMBR/TMMBN bounding set overhead value matters, related to whether local RTP stream sender or remote RTP stream receiver owns the TMMBR 0 restriction, and the consequences this has on pause/ resume logic. o Moved text on when to stop media stream transmission from when receiving PAUSE and entering pausing state, to when entering paused or local paused states. o Added text on how to determine if there is a single receiver or not, aligned with what is specified in draft-ietf-avtcore-multi- stream, adding a reference to draft-ietf-avtcore-multi-stream- optimisation to be able to use a single RTCP reporting group as one criteria. o Added clarifying text on repeating PAUSED and RESUME messages only as long as remaining in the relevant state. o Clarified that it is the RTP stream sender's responsibility to leave local paused state when the condition causing that state is no longer true. o Added text to better allow for extensions to this specification, since there is already some text on extensions. o Corrected and amended ABNF to make CCM pause parameters order- independent, allow for a larger config pause attribute value range, and added corresponding text to handle that additional flexibility. o Added SDP rules on how to handle unknown pause attribute values. o Clarified how to handle an SDP with both "ccm pause" and "ccm tmmbr". o Changed from "Translator" to "Relay" in examples, to make it clearer in relation to the updated topologies draft. o Editorial improvements. Cheers, Bo > -----Original Message----- > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org > Sent: den 9 mars 2015 16:33 > To: i-d-announce@ietf.org > Cc: avtext@ietf.org > Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-stream-pause-07.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-07.txt > Pages : 54 > Date : 2015-03-09 >=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-07 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-rtp-stream-pause-07 >=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 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Mon Mar 9 12:34:40 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 8A4F71A9168 for ; Mon, 9 Mar 2015 12:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 qt4gw8mjpm5n for ; Mon, 9 Mar 2015 12:34:36 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CDB11A9154 for ; Mon, 9 Mar 2015 12:34:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=817; q=dns/txt; s=iport; t=1425929674; x=1427139274; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=R5YlIVrtSpooHSRQSXMnIFTbIiJ7rHjoKHKf36svpCc=; b=Y7vqIHYgXn3RMm8Z65+9mOZm0WHNvcoXvE9Vfo7mt0N1j0weX/LsRqHt 7oFGM5SPWsTdqpzjs1RL1t73sUh9mos3OMs8MKlaNlzLhGFB+pNvVoq29 j7/319LZMOmJx/7wNQKxHh/u71h/ihjnPAU7Kt78NULIdxmEwMelMXuo6 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BRBQCqaeJU/5NdJa1bgwZSWgTCPIcLQwEBAQEBAXyEDQIEHVEdAQg7PScEARKILQ3OKAEBCCKLDIkeBY1MgWyDV4VggRg4glWLKoM+IoICHBSBPG+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,369,1422921600"; d="scan'208";a="401922789" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-8.cisco.com with ESMTP; 09 Mar 2015 19:34:33 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t29JYXdr018297 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Mar 2015 19:34:33 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.142]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 14:34:33 -0500 From: "Mo Zanaty (mzanaty)" To: Jonathan Lennox , "avtext@ietf.org" Thread-Topic: [avtext] Confirmation of consensus: Milestone for, and adoption of, RTP header extension for SDES items Thread-Index: AQHQWqARfI/sV1JLpUqP0QYSUpdEFQ== Date: Mon, 9 Mar 2015 19:34:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.150.28.53] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5E6F49F6F335CF4DA81B0341F3C154D4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [avtext] Confirmation of consensus: Milestone for, and adoption of, RTP header extension for SDES items 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 Mar 2015 19:34:38 -0000 The authors obviously support this. We would like to hear from others, so we can adopt or adjust the proposal. To remind, BUNDLE is already using this for MID. http://tools.ietf.org/html/draft-westerlund-avtext-sdes-hdr-ext Thanks, Mo On 11/11/14, 11:07 PM, Jonathan Lennox wrote: Hello, all =8B In the working group session today, we had strong consensus to create a milestone for an RTP header extension for SDES items, and to adopt draft-westerlund-avtext-sdes-hdr-ext-03 as the starting point for the working group document. This is a call for confirmation from the mailing list: for those not in the meeting (either in the room or remotely), please indicate either your support or objection to this course of action. Thanks! Jonathan Lennox AVTEXT Co-chair From nobody Mon Mar 9 13:04: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 7562A1AC3D2 for ; Mon, 9 Mar 2015 13:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHkUdFyB6ph2 for ; Mon, 9 Mar 2015 13:04:09 -0700 (PDT) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEC51AC423 for ; Mon, 9 Mar 2015 13:04:02 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id t29K1EWH024854; Mon, 9 Mar 2015 16:04:01 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 1syu3xh8ma-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 09 Mar 2015 16:04:01 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 15:04:00 -0500 From: Jonathan Lennox To: "Mo Zanaty (mzanaty)" Thread-Topic: [avtext] Confirmation of consensus: Milestone for, and adoption of, RTP header extension for SDES items Thread-Index: AQHQWqARfI/sV1JLpUqP0QYSUpdEFZ0U5u2A Date: Mon, 9 Mar 2015 20:03:59 +0000 Message-ID: <0B3A4F9B-68C5-4516-8FEE-61959D720455@vidyo.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.116.135.94] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-09_04:2015-03-09,2015-03-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1503090199 Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] Confirmation of consensus: Milestone for, and adoption of, RTP header extension for SDES items 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 Mar 2015 20:04:10 -0000 Apologies for letting this drop. Given the strong consensus in the room an= d the absence of objection on the mailing list, we=92ll request a milestone= for this from the A-D. On Mar 9, 2015, at 3:34 PM, Mo Zanaty (mzanaty) wrote: > The authors obviously support this. We would like to hear from others, so > we can adopt or adjust the proposal. To remind, BUNDLE is already using > this for MID. >=20 > http://tools.ietf.org/html/draft-westerlund-avtext-sdes-hdr-ext >=20 > Thanks, > Mo >=20 > On 11/11/14, 11:07 PM, Jonathan Lennox wrote: >=20 > Hello, all =8B >=20 > In the working group session today, we had strong consensus to create a > milestone for an RTP header extension for SDES items, and to adopt > draft-westerlund-avtext-sdes-hdr-ext-03 as the starting point for the > working group document. >=20 > This is a call for confirmation from the mailing list: for those not in > the meeting (either in the room or remotely), please indicate either your > support or objection to this course of action. >=20 > Thanks! >=20 > Jonathan Lennox > AVTEXT Co-chair >=20 From nobody Mon Mar 9 15:23: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 6D6AB1A017D for ; Mon, 9 Mar 2015 15:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoGiHTSTTTBu for ; Mon, 9 Mar 2015 15:23:39 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4681ACD9F for ; Mon, 9 Mar 2015 15:23:23 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id t29MKVCe003627 for ; Mon, 9 Mar 2015 18:23:22 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 1syu3xh9kx-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Mon, 09 Mar 2015 18:23:22 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 17:23:22 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: I-D Action: draft-lennox-avtext-lrr-00.txt Thread-Index: AQHQWrbIMKa6rySWs0u7KN3ENDpkfp0VDbCA Date: Mon, 9 Mar 2015 22:23:21 +0000 Message-ID: <2396B29D-7DFD-46CD-AB50-FF2BAE6112AE@vidyo.com> References: <20150309221609.10819.66649.idtracker@ietfa.amsl.com> In-Reply-To: <20150309221609.10819.66649.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.116.135.94] Content-Type: text/plain; charset="Windows-1252" Content-ID: <102145D1CC4DC04AAAF5443572C41AE8@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-09_05:2015-03-09,2015-03-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1503090225 Archived-At: Subject: Re: [avtext] I-D Action: draft-lennox-avtext-lrr-00.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: Mon, 09 Mar 2015 22:23:40 -0000 FYI. This is a proposal to add a feedback message to request refresh of on= e layer of a scalable source. I mentioned it at the Honolulu IETF as a section of our proposed VP9 payloa= d format; it=92s now been split out into a separate document. Comments are welcome. On Mar 9, 2015, at 6:16 PM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : The Layer Refresh Request (LRR) RTCP Feedback Me= ssage > Authors : Jonathan Lennox > Danny Hong > Justin Uberti > Stefan Holmer > Magnus Flodman > Filename : draft-lennox-avtext-lrr-00.txt > Pages : 10 > Date : 2015-03-09 >=20 > Abstract: > This memo describes the RTP Payload-Specific Feedback Message "Layer > Refresh Request" (LRR), which can be used to request a state refresh > of one or more substreams of a layered media stream. It also defines > its use with several scalable media formats. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-lennox-avtext-lrr/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-lennox-avtext-lrr-00 >=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 >=20 From nobody Mon Mar 16 10:38:26 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 089D21A891D for ; Mon, 16 Mar 2015 10:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zATmxJv69jIq for ; Mon, 16 Mar 2015 10:38:23 -0700 (PDT) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) by ietfa.amsl.com (Postfix) with ESMTP id 02A1D1A88F1 for ; Mon, 16 Mar 2015 10:38:20 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id t2GHbClq012331 for ; Mon, 16 Mar 2015 13:38:20 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 1t4hv490fh-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Mon, 16 Mar 2015 13:38:20 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Mon, 16 Mar 2015 12:38:19 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: Agenda for AVTEXT meeting at IETF 92 Thread-Index: AQHQYA/9Qn9zDYuy7EGhIUuyV6SzoQ== Date: Mon, 16 Mar 2015 17:38:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.0.208.51] Content-Type: multipart/alternative; boundary="_000_C1F1DF68026B455499B6A86D127A8760vidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-16_04:2015-03-13,2015-03-16,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1503160176 Archived-At: Subject: [avtext] Agenda for AVTEXT meeting at IETF 92 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, 16 Mar 2015 17:38:25 -0000 --_000_C1F1DF68026B455499B6A86D127A8760vidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, all =97 Here=92s the proposed agenda for the AVTEXT session at IETF 92. Please let= the chairs know about any problems or suggested changes. Note that we=92re somewhat tight for time, so I=92d like to ask all present= ers to stay tightly focused. Since all the presentations are proposed new = work, the presentations should be targeted at deciding whether the topic in= question is something that the WG should work on. (In the future, for everyone who's planning to propose new work for AVTEXT,= it=92d be helpful if you could let the chairs know before the deadline for= requesting session scheduling, so we can request an appropriate size slot.= Thanks!) AVTEXT Audio/Video Transport Extensions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Tuesday 17:30 - 18:30 CDT (Far East) Chairs: Keith Drage / Jonathan Lennox 17:30 Agenda bash, status update (10 min) Chairs draft-ietf-avtext-rtp-grouping-taxonomy-06 [Ready for Pub Req] draft-ietf-avtext-splicing-notification-01 [Check for IPR concerns, WGLC if none] draft-ietf-avtext-rtp-stream-pause-07 [Recent post-WGLC changes -- new WGLC needed?] draft-westerlund-avtext-sdes-hdr-ext-03 [Adopt as WG draft once milestone is approved] Potential new work: 17:40 Frame Marking RTP Header Extension (15 minutes) Suhas Nanakumar draft-berger-avtext-framemarking-00 17:55 The Layer Refresh Request (LRR) RTCP Feedback Message (15 minutes) Jonathan Lennox draft-lennox-avtext-lrr-00 18:10 Reference Picture Verification Information in AVPF (10 minutes) Bo Burman draft-samuelsson-avtext-rpvi-00 18:20 Encoded Stream ID Header Extension (10 minutes) Peter Thatcher draft-pthatcher-avtext-esid-00 18:30 Close =97 Jonathan Lennox jonathan@vidyo.com --_000_C1F1DF68026B455499B6A86D127A8760vidyocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2889C88ADA0FFE4187CEF87485A15481@vidyo.com> Content-Transfer-Encoding: quoted-printable Hi, all =97

Here=92s the proposed agenda for the AVTEXT session at IETF 92.  = Please let the chairs know about any problems or suggested changes. 

Note that we=92re somewhat tight for time, so I=92d like to ask all pr= esenters to stay tightly focused.  Since all the presentations are pro= posed new work, the presentations should be targeted at deciding whether th= e topic in question is something that the WG should work on.

(In the future, for everyone who's planning to propose new work for AV= TEXT, it=92d be helpful if you could let the chairs know before the deadlin= e for requesting session scheduling, so we can request an appropriate size = slot.  Thanks!)

AVTEXT Audio/Video Tra= nsport Extensions
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

Tuesday 17:30 - 18:30 = CDT (Far East)

Chairs: Keith Drage / = Jonathan Lennox

17:30   Agenda ba= sh, status update (10 min)

      C= hairs

 draft-ietf-avtext-rtp-group= ing-taxonomy-06
[Ready for Pub Req]
 draft-ietf-avtext-splicing-= notification-01
[Check for IPR concerns, WGLC if = none]
 draft-ietf-avtext-rtp-strea= m-pause-07
[Recent post-WGLC changes -- new = WGLC needed?]
  draft-westerlund-avte= xt-sdes-hdr-ext-03
[Adopt as WG draft once milestone= is approved]


Potential new work:


17:40   Frame Mar= king RTP Header Extension (15 minutes)

Suhas Nanakumar

  draft-berger-avtext-framemarking-00


17:55 The Layer Refresh Request (LRR) RTCP Feedback Message (15 minutes)

Jonathan Lennox

  draft-lennox-avtext-lrr-00


18:10 Reference Picture Verification Information in AVPF (10 minutes)

Bo Burman

  draft-samuelsson-avtext-rpvi-00


18:20 Encoded Stream ID Header Extension (10 minutes)

Peter Thatcher

  draft-pthatcher-avtext-esid-00


18:30   Close

=97
Jonathan Lennox
jonathan@vidyo.com

--_000_C1F1DF68026B455499B6A86D127A8760vidyocom_-- From nobody Wed Mar 18 01:40: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 A24411A0270 for ; Wed, 18 Mar 2015 01:40:48 -0700 (PDT) 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 s6PYCRCAYSfd for ; Wed, 18 Mar 2015 01:40:47 -0700 (PDT) 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 5ACFD1A011D for ; Wed, 18 Mar 2015 01:40:46 -0700 (PDT) X-AuditID: c1b4fb2d-f79a46d0000006b4-09-55093a0ca40f Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 35.FD.01716.C0A39055; Wed, 18 Mar 2015 09:40:44 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.3.210.2; Wed, 18 Mar 2015 09:40:43 +0100 Message-ID: <55093A0B.6030106@ericsson.com> Date: Wed, 18 Mar 2015 09:40:43 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "avtext@ietf.org" References: <20150317223834.14640.35584.idtracker@ietfa.amsl.com> In-Reply-To: <20150317223834.14640.35584.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150317223834.14640.35584.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------010007050300060702060904" X-Brightmail-Tracker: H4sIAAAAAAAAA1WSbUhTcRTGObt387oU/y2tk0HZojedpukHMxOtL0EIgi0kFF11m5Iu2V3L ImIOUlumVpK5DN+zLBOlzNLEli+USfuQZVC2pRUuM0tBxZS89wrVt9855zn3efify1CKH1Jf Jk1nYPU6TbpSJqdLE+bPBHpEuKuDJ8x+4T+HBqXRsLemZlYSBwflkUfY9DQjq98WlSJPdczl 0JlfQ7KKBmvBBLMqCzAMkjBstygt4L6IK9E+1CizgJxRkC7Anoo2SizqAF2dL4BXeZIAzOue kvJMk43Ykj0p4VlGwvHdTLaMZx8Sj7O5bRJRvxyfl47QPHuTzfi+xC44rCCXASdGncJHFSQG r40WuvHsTnZj2ycHiJFisX7MSfNJKRKHruoAUR6AJnOetAiI9R8L618V36ZIMHZVlUlFXocP v5dRIjcC3qg8/n9fvsiDgOVfHggLSLwwt++lMFCQJsDmX2MScRCG5/v73MRBsQSH69ppsbgC +NB8VShoMk1hVX6bm7jijzP1LimfjyZb0XJpk7jQCthQcJESNVvw2m07WIWbeGGDbYPYVuBQ XcmSsyf2FffKRE7Bug9NwqqCtAA+nvwbosX8AazCSfwxf/6RsOBN1Nj0e3opjzeODziXfBHL K24JDGQtzvQMC2aEEFy4bKfF941Bq6NDYP7krfYSEPWJmLvwmaqAsHrw4ViOy9BuDw1i9WmH Oe64LkjHGpph8Q99en8usBXufIuxAWFA6eEZ7GLUCqnGyJ3KsMEahlau8owKte1XEK3GwB5j 2UxWn6w/kc5yNpAw7r4m8DtdqYpPWvbEp8O8y9HP9M5fMCYmX4V97aUO56EBY/K414juaKvH K21E9dR04+u7O+9N0mebkg4F7Xme2jmYkSJTRe9RJ8xlXo/tDPqU9cbhq5quiV/dnd9Vy86u P5mTfvNc/wuPhI+OB+vpAyrtjrzI+LfPTNmFBdWPjAaD9FatkuZSNSH+lJ7T/AGbh7wqggMA AA== Archived-At: Subject: [avtext] Fwd: [ipr-announce] IPR Disclosure Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-samuelsson-avtext-rpvi 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, 18 Mar 2015 08:40:48 -0000 --------------010007050300060702060904 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit WG, For your information Ericsson has now declared its IPR related to draft-samuelsson-avtext-rpvi. Thus there are three IPR disclosures on this draft. Cheers Magnus Westerlund --------------010007050300060702060904 Content-Type: message/rfc822; name="[ipr-announce] IPR Disclosure Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-samuelsson-avtext-rpvi.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="[ipr-announce] IPR Disclosure Telefonaktiebolaget LM Ericsso"; filename*1="n (publ)'s Statement about IPR related to draft-samuelsson-a"; filename*2="vtext-rpvi.eml" X-Mozilla-Keys: Received: from sesbmg13.ericsson.net (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.67) with Microsoft SMTP Server id 14.3.210.2; Tue, 17 Mar 2015 23:38:39 +0100 X-AuditID: c1b4fb31-f79956d000002d57-23-5508acee9b4e Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by sesbmg13.ericsson.net (Symantec Mail Security) with SMTP id 91.C3.11607.FECA8055; Tue, 17 Mar 2015 23:38:40 +0100 (CET) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A36321A1BD2; Tue, 17 Mar 2015 15:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1426631917; bh=vwGguTH9nk1PTJu2vMd2RLIxg2ZILV/Vws3ceLYHX54=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=g+IpByE5QCzVvS+YR8cj4VsHc62eT9yIKWoDVr5zKEgFFJq4h87gMLgR9+k9vVKKO RRR6TJziCxA7EwcifqMZ5m3a+XLlMp2yWr6uqtiVdgLp24GSTPNhfIAsgoQ2jWgHVC BPVTOWElOyGMM83A7zXBGI44maW2VujuSINUo3ok= X-Original-To: ipr-announce@ietfa.amsl.com Delivered-To: ipr-announce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2981A1BB3 for ; Tue, 17 Mar 2015 15:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Tz6Nv2Y0_TqK; Tue, 17 Mar 2015 15:38:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BB11A1BBD; Tue, 17 Mar 2015 15:38:34 -0700 (PDT) From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150317223834.14640.35584.idtracker@ietfa.amsl.com> Date: Tue, 17 Mar 2015 15:38:34 -0700 Archived-At: CC: , Subject: [ipr-announce] IPR Disclosure Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-samuelsson-avtext-rpvi X-BeenThere: ipr-announce@ietf.org X-Mailman-Version: 2.1.15 List-Id: For keeping updated on new IETF IPR disclosures List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ipr-announce-bounces@ietf.org Sender: ipr-announce X-Brightmail-Tracker: H4sIAAAAAAAAA1VSfUxNYRzuPefcc0/tHr3OLf3cKDvNR5aS2O7MIh9Dm1GrDTNcnLp36lb3 XFZ/+FgyiaysL2nTYuTSCkmtabqzjD5cUj5GbsQIzRiuIs5Hwn/P+z6/5+N992NI7i5tYIRM u2CzmlJ42oeigtvC5ny8yCTOzWknjNnP6rXG08+rtcb7tX2EsfdFrPFkxyON0dN8UWO8eWeI XKJdNfylh16HNvos2iGkWHYLtojorT7mhtzw9M+azMf5r+n96IgmD3kzgOfD4c52rYongauv lpYxh4sIKHAvyEM+Ei5G0PWwl5APFP5GQtXR5jHFbPA4BiUnRiJCIa9whipuROBojldHZkHZ eReSRwD7Qo0zRL3moO9cKaHiCXDvjWcMb4Vzzy6Ram4DgpOXB8jxEv2FV5A8xeKJcPvEACVj Wupw9GeT0toPJ0LOqQFadfKDoZ5+UsUApyqrFYxwEHjaXippGGMYPe6iVM8YKHe3KJjC06HR VYrU+U1waPSVoiVxBOS+K1E+Qo/zEbgKh8fCePj87trYl06Gju5ORazD8TDS9VIR6PABBO6R AlollsJB91ttAZpZ/s+DypWQMKhs/kSrOBiufaggKxHpQP6iIG5LTY6MChdslu2imGYNtwr2 y0hakNb6kchG1PQ1xokwg3gdW1emTeQ0pt1iVqoTTWYI3p9NcjCJ3IRtaTuyzCbRvMW2K0UQ nSiQofgAtiTMmcDhZJNd2CkI6YLtDzuFYXhgBy9Iyok2IVnITLKk2P/SBOPtRMDoeD82UNpO jhXTTamiJVnl76Aopq71RxXBPC36VUVwlDXNKhgC2G+yHZZHzbus425/9vw+mmrQs8jLy4vT SU1SLfb/+UEUIL1Qz76WXXQWq308b1CqQkhVcg7RchW76S9l2I/y3y/uiFuxOqrbkN01zRvr m3Jaz97oDqwb2uy/Zl59KBHr4TOe6oszon/cyliwod/XuMXhO3x1Vmhr0MaGomMLG8+sfF/x uKXlZ1PYvrSikN4Z30dr9sbuaT8SU7yYaJvTnZ2/PsudYHswVVgevejXskqvwi9rnyy9Xtqe u0aTUBGXvYynRLMpcjZpE02/AWlsiQHiAwAA Return-Path: ipr-announce-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: ESESSHC016.ericsson.se X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 MIME-Version: 1.0 Dear Jonatan Samuelsson, Muhammed Coban, Stephan Wenger: An IPR disclosure that pertains to your Internet-Draft entitled "Reference Picture Verification Information in the RTP Audio-Visual Profile with Feedback (AVPF)" (draft-samuelsson-avtext-rpvi) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2549/). The title of the IPR disclosure is "Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-samuelsson-avtext-rpvi" Thank you IETF Secretariat _______________________________________________ ipr-announce mailing list ipr-announce@ietf.org https://www.ietf.org/mailman/listinfo/ipr-announce --------------010007050300060702060904-- From nobody Wed Mar 18 10:07:40 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 319521A8A93 for ; Wed, 18 Mar 2015 10:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 OPHLeRUMrgfq for ; Wed, 18 Mar 2015 10:07:37 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C39531A8A94 for ; Wed, 18 Mar 2015 10:07:37 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id BBA84DAE63EED for ; Wed, 18 Mar 2015 17:07:32 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t2IH7ZKq013718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 18 Mar 2015 18:07:35 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.230]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 18 Mar 2015 18:07:35 +0100 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Thread-Topic: draft-ietf-avtext-splicing-notification Thread-Index: AdBabkh0iZrr+pRuScOClgjAyVIa/wHLP+5g Date: Wed, 18 Mar 2015 17:07:34 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B4A117FBE@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [avtext] draft-ietf-avtext-splicing-notification 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, 18 Mar 2015 17:07:39 -0000 I have seen no feedback at all to this message to the working group. Regards Keith=20 > -----Original Message----- > From: DRAGE, Keith (Keith)=20 > Sent: 09 March 2015 13:38 > To: avtext@ietf.org > Subject: draft-ietf-avtext-splicing-notification >=20 > (As WG cochair) >=20 > After we agreed that the above draft becomes a working group=20 > item, an IPR declaration was received as follows. >=20 > https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft > -ietf-avtext-splicing-notification >=20 > The chairs would normally prefer to deal with such IPR issues=20 > before adoption, but that has been precluded in this case. >=20 > The chairs would like to ask the working group whether there=20 > are any issues with the working group proceeding with this=20 > draft in the face of the above IPR declaration. Please=20 > respond with your position, not matter which direction it is in. >=20 > If there are issues, then please identify your preferred=20 > solution to dealing with the issue, i.e. different solution,=20 > abandon the work, etc. >=20 > Regards >=20 > Keith= From nobody Sat Mar 21 21:52:02 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 C588A1A1A4F for ; Sat, 21 Mar 2015 21:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 BPJ7PcP1vxoV for ; Sat, 21 Mar 2015 21:51:58 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65CB51A1A5A for ; Sat, 21 Mar 2015 21:51:58 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 79DE070F0CA4B for ; Sun, 22 Mar 2015 04:51:53 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t2M4ps6L009366 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 22 Mar 2015 05:51:54 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.230]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Sun, 22 Mar 2015 05:51:54 +0100 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Thread-Topic: Agenda for AVTEXT meeting at IETF 92 Thread-Index: AQHQYA/9Qn9zDYuy7EGhIUuyV6SzoZ0ndKXA Date: Sun, 22 Mar 2015 04:51:54 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B4A119FDF@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B4A119FDFFR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Subject: Re: [avtext] Agenda for AVTEXT meeting at IETF 92 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 Mar 2015 04:52:02 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B4A119FDFFR712WXCHMBA11z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (As WG cochair) Can I pleaae emphasise what my cochair has written below. We have limited time to look at four new drafts. Please concentrate in the = meeting on those questions that allow us to decide whether to move forward = or not with any or all of these drafts. So these are things like: 1) Is a header extension the right solution for this? If not it probably= moves out of the AVTEXT group and gets directed elsewhere. 2) Is the scope of the proposal about right, for example would be have a= more useful header extension if it did a+b rather than just a? The convers= e example also applies? 3) And the obvious, is this something we want AVTEXT to work on, and is = there sufficient interest in the working group to progress this? 4) It is also always appropriate to make these points or ask these quest= ions on the mailing list prior to the face-to-face meeting. If you do have questions or points such as - this should be a two octet fie= ld or a three octet field - please feel free to make them on the mailing li= st - please DO NOT raise them in the face to face meeting. We can deal with= such issues later if and when we have assigned a charter milestone. A reminder that there are IPR declarations against draft-samuelsson-avtext-= rpvi. Please read the disclosures and take this into account when expressin= g your views. If you know of IPR declarations affecting any of the document= s, then please raise them - it is better to deal with such declarations at = this stage than have to backtrack later when they are discovered. regards Keith ________________________________ From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Jonathan Lennox Sent: 16 March 2015 17:38 To: avtext@ietf.org Subject: [avtext] Agenda for AVTEXT meeting at IETF 92 Hi, all - Here's the proposed agenda for the AVTEXT session at IETF 92. Please let t= he chairs know about any problems or suggested changes. Note that we're somewhat tight for time, so I'd like to ask all presenters = to stay tightly focused. Since all the presentations are proposed new work= , the presentations should be targeted at deciding whether the topic in que= stion is something that the WG should work on. (In the future, for everyone who's planning to propose new work for AVTEXT,= it'd be helpful if you could let the chairs know before the deadline for r= equesting session scheduling, so we can request an appropriate size slot. = Thanks!) AVTEXT Audio/Video Transport Extensions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Tuesday 17:30 - 18:30 CDT (Far East) Chairs: Keith Drage / Jonathan Lennox 17:30 Agenda bash, status update (10 min) Chairs draft-ietf-avtext-rtp-grouping-taxonomy-06 [Ready for Pub Req] draft-ietf-avtext-splicing-notification-01 [Check for IPR concerns, WGLC if none] draft-ietf-avtext-rtp-stream-pause-07 [Recent post-WGLC changes -- new WGLC needed?] draft-westerlund-avtext-sdes-hdr-ext-03 [Adopt as WG draft once milestone is approved] Potential new work: 17:40 Frame Marking RTP Header Extension (15 minutes) Suhas Nanakumar draft-berger-avtext-framemarking-00 17:55 The Layer Refresh Request (LRR) RTCP Feedback Message (15 minutes) Jonathan Lennox draft-lennox-avtext-lrr-00 18:10 Reference Picture Verification Information in AVPF (10 minutes) Bo Burman draft-samuelsson-avtext-rpvi-00 18:20 Encoded Stream ID Header Extension (10 minutes) Peter Thatcher draft-pthatcher-avtext-esid-00 18:30 Close - Jonathan Lennox jonathan@vidyo.com --_000_949EF20990823C4C85C18D59AA11AD8B4A119FDFFR712WXCHMBA11z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
(As WG cochair)
 
Can I pleaae emphasise what my cochair has written below.
 
We have limited time to look at four new drafts. Please conc= entrate in the meeting on those questions that allow us to decide whether t= o move forward or not with any or all of these drafts.
 
So these are things like:
 
1)    Is a header extension the right solutio= n for this? If not it probably moves out of the AVTEXT group and gets direc= ted elsewhere.
 
2)    Is the scope of the proposal about righ= t, for example would be have a more useful header extension if it did a+= ;b rather than just a? The converse example also applies?
 
3)    And the obvious, is this something we w= ant AVTEXT to work on, and is there sufficient interest in the working grou= p to progress this?
 
4)    It is also always appropriate to make t= hese points or ask these questions on the mailing list prior to the face-to= -face meeting.
 
If you do have questions or points such as - this should be = a two octet field or a three octet field - please feel free to make them on= the mailing list - please DO NOT raise them in the face to face meeting. We can deal with such issues later if an= d when we have assigned a charter milestone.
 
A reminder that there are IPR declarations against draft-samuelsson-avtext-rpvi. Please read the disclosu= res and take this into account when expressing your views. If you know of I= PR declarations affecting any of the documents, then please raise them - it= is better to deal with such declarations at this stage than have to backtrack later when they are discovered.
 
regards
 
Keith
 
 

From: avtext [mailto:avtext-bounces= @ietf.org] On Behalf Of Jonathan Lennox
Sent: 16 March 2015 17:38
To: avtext@ietf.org
Subject: [avtext] Agenda for AVTEXT meeting at IETF 92

Hi, all —

Here’s the proposed agenda for the AVTEXT session at IETF 92. &n= bsp;Please let the chairs know about any problems or suggested changes.&nbs= p;

Note that we’re somewhat tight for time, so I’d like to as= k all presenters to stay tightly focused.  Since all the presentations= are proposed new work, the presentations should be targeted at deciding wh= ether the topic in question is something that the WG should work on.

(In the future, for everyone who's planning to propose new work for AV= TEXT, it’d be helpful if you could let the chairs know before the dea= dline for requesting session scheduling, so we can request an appropriate s= ize slot.  Thanks!)

AVTEXT Audio/Video Tran= sport Extensions
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

Tuesday 17:30 - 18:30 C= DT (Far East)

Chairs: Keith Drage / J= onathan Lennox

17:30   Agenda bas= h, status update (10 min)

      Ch= airs

 draft-ietf-avtext-rtp-group= ing-taxonomy-06
[Ready for Pub Req]
 draft-ietf-avtext-splicing-= notification-01
[Check for IPR concerns, WGLC if = none]
 draft-ietf-avtext-rtp-strea= m-pause-07
[Recent post-WGLC changes -- new = WGLC needed?]
  draft-westerlund-avte= xt-sdes-hdr-ext-03
[Adopt as WG draft once milestone= is approved]


Potential new work:


17:40   Frame Mark= ing RTP Header Extension (15 minutes)

Suhas Nanakumar

  draft-berger-avtext-framemarking-00


17:55 The Layer Refresh Request (LRR) RTCP Feedback Message (15 minutes)

Jonathan Lennox

  draft-lennox-avtext-lrr-00


18:10 Reference Picture Verification Information in AVPF (10 minutes)

Bo Burman

  draft-samuelsson-avtext-rpvi-00


18:20 Encoded Stream ID Header Extension (10 minutes)

Peter Thatcher

  draft-pthatcher-avtext-esid-00


18:30   Close

—
Jonathan Lennox
jonathan@vidyo.com

--_000_949EF20990823C4C85C18D59AA11AD8B4A119FDFFR712WXCHMBA11z_-- From nobody Sun Mar 22 19:01:08 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 D15A31A8773 for ; Sun, 22 Mar 2015 19:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 X-Dwq4muVHb6 for ; Sun, 22 Mar 2015 19:01:02 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B9421A876A for ; Sun, 22 Mar 2015 19:01:02 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 3D890BCD2E325 for ; Mon, 23 Mar 2015 02:00:59 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t2N20xvq020975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 23 Mar 2015 03:00:59 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.230]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 23 Mar 2015 03:00:59 +0100 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Thread-Topic: IETF#92 AVTEXT meeting - slide presentations Thread-Index: AdBlDTQdBlqYHX19SJK62XFGNQ4RpQ== Date: Mon, 23 Mar 2015 02:00:58 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B4A11A64D@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [avtext] IETF#92 AVTEXT meeting - slide presentations 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, 23 Mar 2015 02:01:07 -0000 (As WG cochair) AVTEXT is meeting in the last session on Tuesday. Please could presenters provide their slides to the chairs by 15:00 tomorro= w (Monday) so they can be uploaded to the system (and checked by the chairs= ). Regards Keith= From nobody Mon Mar 23 08:34: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 BBAAA1A90E6 for ; Mon, 23 Mar 2015 08:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 cnLjMnWfLuIx for ; Mon, 23 Mar 2015 08:34:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF47E1A90F9 for ; Mon, 23 Mar 2015 08:34:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150323153408.2729.45963.idtracker@ietfa.amsl.com> Date: Mon, 23 Mar 2015 08:34:08 -0700 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Mon, 23 Mar 2015 08:34:41 -0700 Subject: [avtext] Milestones changed for avtext WG 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: Mon, 23 Mar 2015 15:34:10 -0000 Changed milestone "Submit RTP header extension for SDES items for Proposed Standard", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/avtext/charter/ From nobody Mon Mar 23 08:56:08 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 055F61A92F8; Mon, 23 Mar 2015 08:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 06unjQEvacO3; Mon, 23 Mar 2015 08:56:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D661A92F0; Mon, 23 Mar 2015 08:56:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150323155604.19569.67992.idtracker@ietfa.amsl.com> Date: Mon, 23 Mar 2015 08:56:04 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-sdes-hdr-ext-00.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: Mon, 23 Mar 2015 15:56:06 -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 Header Extension for RTCP Source Description Items Authors : Magnus Westerlund Bo Burman Roni Even Mo Zanaty Filename : draft-ietf-avtext-sdes-hdr-ext-00.txt Pages : 12 Date : 2015-03-23 Abstract: Source Description (SDES) items are normally transported in RTP control protocol (RTCP). In some cases it can be beneficial to speed up the delivery of these items. Mainly when a new source (SSRC) joins an RTP session and the receivers needs this source's relation to other sources and its synchronization context, which are fully or partially identified using SDES items. To enable this optimization, this document specifies a new RTP header extension that can carry any type of SDES items. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtext-sdes-hdr-ext-00 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 Mon Mar 23 08:59:47 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 F2BCA1ABB1A for ; Mon, 23 Mar 2015 08:59:45 -0700 (PDT) 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 eeGKvkbJq3mx for ; Mon, 23 Mar 2015 08:59:44 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C03CD1A911E for ; Mon, 23 Mar 2015 08:59:43 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-e3-5510386df0db Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 87.51.19337.D6830155; Mon, 23 Mar 2015 16:59:42 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.3.210.2; Mon, 23 Mar 2015 16:59:40 +0100 Message-ID: <55103867.2080504@ericsson.com> Date: Mon, 23 Mar 2015 10:59:35 -0500 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "avtext@ietf.org" References: <20150323155604.19569.67992.idtracker@ietfa.amsl.com> In-Reply-To: <20150323155604.19569.67992.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3RjfPQiDUYOF5RouP926wOjB6LFny kymAMYrLJiU1J7MstUjfLoEr4/qu64wFE0UqPj/bxN7AuIu/i5GDQ0LARKJ7hm8XIyeQKSZx 4d56ti5GLg4hgSOMEi/PPWOHcJYzSlx+NJMNpIpXQFvi3t6/rCA2i4CqxJqNu5hAbDYBC4mb PxrBakQFgiV+tu9mgqgXlDg58wkLiC0ioC5xZ/oFsBphATuJT/MWgNUICThK3FnXDDaTU8BJ YmrHFbB6ZgEDiSOL5rBC2PISzVtnM0PUa0s0NHWwTmAUmIVkxSwkLbOQtCxgZF7FKFqcWpyU m25krJdalJlcXJyfp5eXWrKJERiCB7f8Vt3BePmN4yFGAQ5GJR7eDY38oUKsiWXFlbmHGKU5 WJTEee2MD4UICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYAy5bWRYMuXN6/5jc7+x1298d4Up LKAs6lhCdaFlxF+vJVxMVjLNpTbGrL6MEasP343/FZrwdfOXHY823bGOm5DVuKBw6uEPR8/P 1S+JCt3c/nqdxy2TeXOUC3YoCDBeDZsuEZt6o/NWfKyKb6Zha86BF4v2CTh7n4xawCZ348C0 auGzN36FnlNiKc5INNRiLipOBAD9awCdIgIAAA== Archived-At: Subject: Re: [avtext] I-D Action: draft-ietf-avtext-sdes-hdr-ext-00.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: Mon, 23 Mar 2015 15:59:46 -0000 WG, This version is identical to the -03 individual except for the filename and date. Cheers Magnus Westerlund On 2015-03-23 10:56, internet-drafts@ietf.org wrote: > > 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 Header Extension for RTCP Source Description Items > Authors : Magnus Westerlund > Bo Burman > Roni Even > Mo Zanaty > Filename : draft-ietf-avtext-sdes-hdr-ext-00.txt > Pages : 12 > Date : 2015-03-23 > > Abstract: > Source Description (SDES) items are normally transported in RTP > control protocol (RTCP). In some cases it can be beneficial to speed > up the delivery of these items. Mainly when a new source (SSRC) > joins an RTP session and the receivers needs this source's relation > to other sources and its synchronization context, which are fully or > partially identified using SDES items. To enable this optimization, > this document specifies a new RTP header extension that can carry any > type of SDES items. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtext-sdes-hdr-ext-00 > > > 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/ > > _______________________________________________ > 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 > > -- 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 Mon Mar 23 09:20:07 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 9D9231ACC87 for ; Mon, 23 Mar 2015 09:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 VK77f4ypm1d3 for ; Mon, 23 Mar 2015 09:20:05 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 383141ACC89 for ; Mon, 23 Mar 2015 09:20:04 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 3403C13FD0869 for ; Mon, 23 Mar 2015 16:20:00 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t2NGK0Mq001231 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 23 Mar 2015 17:20:02 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.230]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 23 Mar 2015 17:20:02 +0100 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Thread-Topic: Publication requested for: draft-ietf-avtext-rtp-grouping-taxonomy-06 Thread-Index: AdBlhTZ6qaJkzTYeSlOpUNMl+TZCIQ== Date: Mon, 23 Mar 2015 16:20:02 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B4A11ADA6@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [avtext] Publication requested for: draft-ietf-avtext-rtp-grouping-taxonomy-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: Mon, 23 Mar 2015 16:20:06 -0000 I have just submitted the publication request for this document. You can see the writeup for the publication request here: http://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxonomy/she= pherdwriteup/ Regards Keith From nobody Mon Mar 23 12:17:31 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 A5F8F1A0086 for ; Mon, 23 Mar 2015 12:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.59 X-Spam-Level: X-Spam-Status: No, score=0.59 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCPqBwqN0JbY for ; Mon, 23 Mar 2015 12:17:28 -0700 (PDT) Received: from BLU004-OMC2S3.hotmail.com (blu004-omc2s3.hotmail.com [65.55.111.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E75A1A009B for ; Mon, 23 Mar 2015 12:17:27 -0700 (PDT) Received: from BLU181-W45 ([65.55.111.72]) by BLU004-OMC2S3.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Mon, 23 Mar 2015 12:17:26 -0700 X-TMN: [GUfkaMBC5Qq9P/673KIDC/GvoFScsWPa] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_2aebf87f-5945-4949-9f86-8efe445c5ab6_" From: Bernard Aboba To: "avtext@ietf.org" Date: Mon, 23 Mar 2015 12:17:26 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 23 Mar 2015 19:17:26.0844 (UTC) FILETIME=[FFBAAFC0:01D0659D] Archived-At: Subject: [avtext] Some comments on draft-berger-avtext-framemarking 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, 23 Mar 2015 19:17:29 -0000 --_2aebf87f-5945-4949-9f86-8efe445c5ab6_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The basic idea of this draft seems sound to me=2C and most of the fields p= roposed for the 'Mandatory Extension' (Section 2.1) also make sense to me (= with the possible exception of the "B" bit=2C since for temporal scalabilit= y this should be derivable from the TID).=20 =20 However=2C I did want to comment on the Optional Extensions (Section 2.2) s= ection=2C where additional fields such as the PictureID and H265-LayerId ar= e discussed.=20 =20 In particular=2C I would argue for the following additional information wit= hin Optional Extensions:=20 =20 Additional Layer Identifiers beyond the TID =20 Layer identifiers enable the SFU to determine the temporal=2C=0A= spatial or quality layer of a given packet=2C which is used in=0A= forwarding/drop decisions. Within H.264/SVC this information is=0A= present in the DID(3 bits)=2C QID (4 bits) and TID (3 bits) fields.= =0A= Within VP8=2C it is present in the TID field (2 bits). Within=0A= H.265=2C it is present in the LayerID (6 bits) and TID (3 bits)=0A= fields.=0A= =20 =20 =0A= TL0PICIDX=0A= =20 =0A= This field enables an SFU to determine whether a received frame is=0A= dependent on a base layer frame which the SFU has not previously=0A= received in its entirety. This is important information since it=0A= may represent the first indication that all or part of a base=0A= layer frame needs to be recovered before the arrival of subsequent=0A= base layer frames that depend on it. Within H.264/SVC the=0A= IDRPICID and TL0PICIDX fields are present if the Y bit is set.=0A= Within VP8=2C the TL0PICIDX field is present if the Y bit is set.=0A= =20 However=2C I would argue against the PictureID field=2C for the following r= easons:=20 =20 =0A= =0A= While the PictureID field is utilized within the RPSI feedback=0A= message=2C as well as being supported within the VP8 and VP9 codecs= =2C=0A= its use is not essential to an SFU. RPSI feedback messages are rarel= y supported within=0A= existing SVC and simulcast implementations=2C since better loss=0A= recovery mechanisms are available. As a result=2C an SFU does not=0A= need to originate an RPSI message which would require the=0A= PictureID. Where it is necessary for the SFU to determine which=0A= picture a given packet belongs to=2C RTP header fields such as the=0A= timestamp and sequence number can be used instead.=0A= =20 Similarly=2C I don't believe that Macroblock identifiers should be consider= ed (the draft doesn't propose this=2C but sometimes beating a not-yet-dead = horse is useful):=20 =20 While macroblock identifiers are universally supported within=0A= video codecs=2C they are not used by SFUs today. SLI feedback message= s (which=0A= require a starting macroblock) are rarely supported within=0A= existing SFUs=2C since better loss recovery mechanisms are=0A= available. Therefore a codec-independent SFU should never need to=0A= source an SLI message.=0A= = --_2aebf87f-5945-4949-9f86-8efe445c5ab6_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The basic idea of this draft see= ms sound to me=2C and most of  =3Bthe fields proposed for the 'Mandator= y Extension' (Section 2.1) also make sense to me (with the possible excepti= on of the "B" bit=2C since for temporal scalability =3Bthis should be d= erivable from the =3BTID).
 =3B
However=2C I did want to com= ment on the Optional Extensions (Section 2.2) section=2C where =3Baddit= ional fields such as the PictureID and H265-LayerId are discussed.
&nbs= p=3B
In particular=2C I would argue for the following additional informa= tion within Optional Extensions:
 =3B
Additional Layer Identifie= rs beyond the TID
 =3B
Layer identifiers enable the SFU to determ= ine the temporal=2C=0A= spatial or quality layer of a given packet=2C =3Bwhich is =3B= used in=0A= forwarding/drop decisions. Within H.264/SVC this information is=0A= present in the DID(3 bits)=2C QID (4 bits) and TID (3 bits) fields.= =0A= Within VP8=2C it is present in the TID field (2 bits). Within=0A= H.265=2C it is present in the LayerID (6 bits) and TID (3 bits)=0A= fields.=0A=  =3B
 =3B
=0A= TL0PICIDX=0A=
 =3B
=0A= This field enables an SFU to determine whether a received frame is=0A= dependent on a base layer frame which the SFU has not previously=0A= received in its entirety. This is important information since it=0A= may represent the first indication that all or part of a base=0A= layer frame needs to be recovered before the arrival of subsequent=0A= base layer frames that depend on it. Within H.264/SVC the=0A= IDRPICID and TL0PICIDX fields are present if the Y bit is set.=0A= Within VP8=2C the TL0PICIDX field is present if the Y bit is set.=0A=
 =3B
However=2C I would argue against the PictureID field=2C for= the following reasons:
 =3B
=0A= =0A= While the PictureID field is utilized within the RPSI feedback=0A= message=2C as well as being supported within the VP8 and VP9 codecs= =2C=0A= its use is not essential to an SFU. =3B RPSI feedback messages ar= e rarely supported within=0A= existing SVC and simulcast implementations=2C since better loss=0A= recovery mechanisms are available. As a result=2C an SFU does not=0A= need to originate an RPSI message which would require the=0A= PictureID. Where it is necessary for the SFU to determine which=0A= picture a given packet belongs to=2C RTP header fields such as the=0A= timestamp and sequence number can be used instead.=0A=
 =3B
Similarly=2C I don't believe that Macroblock identifiers sh= ould be considered (the draft doesn't propose this=2C but sometimes beating= a not-yet-dead horse is useful):
 =3B
While macroblock identifi= ers are universally supported within=0A= video codecs=2C they are not used by SFUs today. SLI feedback message= s (which=0A= require a starting macroblock) are rarely supported within=0A= existing SFUs=2C since better loss recovery mechanisms are=0A= available. Therefore a codec-independent SFU should never need to=0A= source an SLI message.=0A=
= --_2aebf87f-5945-4949-9f86-8efe445c5ab6_-- From nobody Tue Mar 24 07:02:45 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 49E411A871E for ; Tue, 24 Mar 2015 07:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlPoUuE9E7It for ; Tue, 24 Mar 2015 07:02:40 -0700 (PDT) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) by ietfa.amsl.com (Postfix) with ESMTP id 80A111A8714 for ; Tue, 24 Mar 2015 07:02:18 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id t2ODxg2Z007149 for ; Tue, 24 Mar 2015 10:02:18 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 1t74r62tu2-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Tue, 24 Mar 2015 10:02:18 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Tue, 24 Mar 2015 09:02:17 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: Notetaker and Jabber Relay volunteers for AVTEXT? Thread-Index: AQHQZjsidggDoU16AEO0Ae/f6fMPTQ== Date: Tue, 24 Mar 2015 14:02:16 +0000 Message-ID: <8DFB1CEE-1FA5-4A5C-8059-3A0ABBC56AE0@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.178.205] Content-Type: text/plain; charset="Windows-1252" Content-ID: <3FE459231D4F0C40A7BB63D59900C163@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-24_04:2015-03-24,2015-03-24,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1503240144 Archived-At: Subject: [avtext] Notetaker and Jabber Relay volunteers for AVTEXT? 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, 24 Mar 2015 14:02:44 -0000 We already have one volunteer to be a notetaker for the AVTEXT session this= afternoon (thanks, Roni!) but we need volunteers to be the backup notetake= r and to be Jabber scribe. The session will be pretty time-crunched, so for efficiency=92s sake it=92d= be great to get volunteers set up prior to the session. Please let the ch= airs know if you=92re willing to take notes.=20 Thanks!=20 Jonathan AVTEXT Co-Chair= From nobody Tue Mar 24 12:24:01 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 AB6091A8AA4 for ; Tue, 24 Mar 2015 12:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GobWnCHwldlq for ; Tue, 24 Mar 2015 12:23:56 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F133C1A8ACF for ; Tue, 24 Mar 2015 12:23:54 -0700 (PDT) Received: by obbgg8 with SMTP id gg8so2300085obb.1 for ; Tue, 24 Mar 2015 12:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=euF9nhhdZY83ySrP8dkVvulhFGP1F3hQo5vFFN1zx70=; b=Pab19RsFhZOxEC1oxQ6O60HSkqCbZFv8x9zwjM1A8/Im4lE2MXFO+U5a/ybijIKEXY +IH82OIw1RnPRx4LZ80swRZmLHnkL0R2cpdl9MyRY5aATRj8DfPxzl4B35aV7p/hFHiE v/u3qeDL8iEUbXwrihN16+CYx3/svZeA7+QZO18zzskX18+WkKW8UMESFuiDYy2pGLgL eTCJwiCQV+lCsBXJ1/yUwS1DfyKZ9vIOHUKY6tyArX3Kc6cwkzLmvOfcdcDrL7NCA7QV AuMZaSu0ZNJ2KG/zZAocxSZ3lna5t5RB9ihtQOthx/4JWVIPei8sQo4063p5D0PjKAWR Sb8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=euF9nhhdZY83ySrP8dkVvulhFGP1F3hQo5vFFN1zx70=; b=TELYkuMcMQmNHAFBbXYJI8grFlDx6JrGBRgURRoNwmOc1IXy748ZTGIsfSGHIMgGNc ggEr79UUXoxgBl76lhtCDN6VSTWs1pMCO/oUCBQCqjEhpOk7Ss+ndEvba8J4elPztfXg 0mBbA1pE2PjhGKrdMTt8FWdZD69pu0KDRy620KYECwqzclvGqohxIc3z71lNJA/nzKa+ LncZLEJQgpsZOMWM5DtuFdDQk+/VgU0LxT8YgDwkrcewJqFNVbB5v4NNaQBE9byVQyBA DWTZnbtJi8QckJwutd9zMq99o0rUdrLWfb38dRsTiYPfgQ0QVXROXPFt/9AVDOqIzCwE G5pQ== X-Gm-Message-State: ALoCoQkz23IUBOaFqK/GvTHJCrkgNVl90ZUr2cOiZ+V6czBMVHPz1+mkMuWgqgUWuus1uHu/1zRf X-Received: by 10.182.191.99 with SMTP id gx3mr4610148obc.16.1427225034423; Tue, 24 Mar 2015 12:23:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.73.194 with HTTP; Tue, 24 Mar 2015 12:23:14 -0700 (PDT) In-Reply-To: <8DFB1CEE-1FA5-4A5C-8059-3A0ABBC56AE0@vidyo.com> References: <8DFB1CEE-1FA5-4A5C-8059-3A0ABBC56AE0@vidyo.com> From: Peter Thatcher Date: Tue, 24 Mar 2015 12:23:14 -0700 Message-ID: To: Jonathan Lennox Content-Type: multipart/alternative; boundary=089e015386dc3126bb05120db9a8 Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] Notetaker and Jabber Relay volunteers for AVTEXT? 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, 24 Mar 2015 19:23:58 -0000 --089e015386dc3126bb05120db9a8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'll take notes up until when I present, and then Harald will take notes for me while I present. But I've never take notes (slacker, I know). So, any pointers as to where I should type them, and how detailed I should type them? On Tue, Mar 24, 2015 at 7:02 AM, Jonathan Lennox wrote= : > We already have one volunteer to be a notetaker for the AVTEXT session > this afternoon (thanks, Roni!) but we need volunteers to be the backup > notetaker and to be Jabber scribe. > > The session will be pretty time-crunched, so for efficiency=E2=80=99s sak= e it=E2=80=99d be > great to get volunteers set up prior to the session. Please let the chai= rs > know if you=E2=80=99re willing to take notes. > > Thanks! > > Jonathan > AVTEXT Co-Chair > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > --089e015386dc3126bb05120db9a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'll take notes up until when I present, and then H= arald will take notes for me while I present.

But I&#= 39;ve never take notes (slacker, I know).=C2=A0 So, any pointers as to wher= e I should type them, and how detailed I should type them?

On Tue, Mar 24, 2015 a= t 7:02 AM, Jonathan Lennox <jonathan@vidyo.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">We already have one volunteer to be a notetak= er for the AVTEXT session this afternoon (thanks, Roni!) but we need volunt= eers to be the backup notetaker and to be Jabber scribe.

The session will be pretty time-crunched, so for efficiency=E2=80=99s sake = it=E2=80=99d be great to get volunteers set up prior to the session.=C2=A0 = Please let the chairs know if you=E2=80=99re willing to take notes.

Thanks!

Jonathan
AVTEXT Co-Chair
_______________________________________________
avtext mailing list
avtext@ietf.org
= https://www.ietf.org/mailman/listinfo/avtext

--089e015386dc3126bb05120db9a8-- From nobody Tue Mar 24 13:02:44 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 A87A31A8ACA for ; Tue, 24 Mar 2015 13:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlhnE08GipCq for ; Tue, 24 Mar 2015 13:02:41 -0700 (PDT) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) by ietfa.amsl.com (Postfix) with ESMTP id 063F61A8FD2 for ; Tue, 24 Mar 2015 13:02:05 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id t2OK25mF005795 for ; Tue, 24 Mar 2015 16:02:05 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 1t74r630f2-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Tue, 24 Mar 2015 16:02:05 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Tue, 24 Mar 2015 15:01:59 -0500 From: Jonathan Lennox To: Google-Peter Thatcher Thread-Topic: [avtext] Notetaker and Jabber Relay volunteers for AVTEXT? Thread-Index: AQHQZjsidggDoU16AEO0Ae/f6fMPTZ0sV00AgAAK0YA= Date: Tue, 24 Mar 2015 20:01:57 +0000 Message-ID: <40F35F08-4CC2-4D91-9257-D3ED9F30322C@vidyo.com> References: <8DFB1CEE-1FA5-4A5C-8059-3A0ABBC56AE0@vidyo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.178.205] Content-Type: multipart/alternative; boundary="_000_40F35F084CC24D919257D3ED9F30322Cvidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-24_06:2015-03-24,2015-03-24,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1503240189 Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] Notetaker and Jabber Relay volunteers for AVTEXT? 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, 24 Mar 2015 20:02:42 -0000 --_000_40F35F084CC24D919257D3ED9F30322Cvidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Mar 24, 2015, at 2:23 PM, Peter Thatcher > wrote: I'll take notes up until when I present, and then Harald will take notes fo= r me while I present. But I've never take notes (slacker, I know). So, any pointers as to where = I should type them, and how detailed I should type them? You can either type them locally on your laptop and then e-mail them to the= chairs, or else (if you wish) use the WG=92s Etherpad at . Generally speaking, we only need a record of decisions made by the working = group. More details can be useful but aren=92t required. On Tue, Mar 24, 2015 at 7:02 AM, Jonathan Lennox > wrote: We already have one volunteer to be a notetaker for the AVTEXT session this= afternoon (thanks, Roni!) but we need volunteers to be the backup notetake= r and to be Jabber scribe. The session will be pretty time-crunched, so for efficiency=92s sake it=92d= be great to get volunteers set up prior to the session. Please let the ch= airs know if you=92re willing to take notes. Thanks! Jonathan AVTEXT Co-Chair _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext --_000_40F35F084CC24D919257D3ED9F30322Cvidyocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <419634697921A94E95756FC4B2882049@vidyo.com> Content-Transfer-Encoding: quoted-printable
On Mar 24, 2015, at 2:23 PM, Peter Thatcher <pthatcher@google.com> wrote:

I'll take notes up until when I present, and then Harald will take notes= for me while I present.

But I've never take notes (slacker, I know).  So, any pointers as t= o where I should type them, and how detailed I should type them?

You can either type them locally on your laptop and then e-mail them t= o the chairs, or else (if you wish) use the WG=92s Etherpad at <http://tools.ietf.org/wg/avtex= t/minutes>.

Generally speaking, we only need a record of decisions made by the wor= king group.  More details can be useful but aren=92t required.

On Tue, Mar 24, 2015 at 7:02 AM, Jonathan Lennox= <jonathan@vidyo.= com> wrote:
We already have one volunteer to be a notetaker for the AVTEXT session this= afternoon (thanks, Roni!) but we need volunteers to be the backup notetake= r and to be Jabber scribe.

The session will be pretty time-crunched, so for efficiency=92s sake it=92d= be great to get volunteers set up prior to the session.  Please let t= he chairs know if you=92re willing to take notes.

Thanks!

Jonathan
AVTEXT Co-Chair
_______________________________________________
avtext mailing list
avtext@ietf.org
= https://www.ietf.org/mailman/listinfo/avtext


--_000_40F35F084CC24D919257D3ED9F30322Cvidyocom_-- From nobody Tue Mar 24 15:06:01 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 B32211AC438 for ; Tue, 24 Mar 2015 15:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 XAQg_l-MIpJe for ; Tue, 24 Mar 2015 15:05:57 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 190EC1A1A92 for ; Tue, 24 Mar 2015 15:05:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8984; q=dns/txt; s=iport; t=1427234717; x=1428444317; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=mDyrFajh0+XdhhmAW2Sn0rLXDY5vgk3P/NK4rN5y4OA=; b=Zp+RdEmkFOfJh4dUtW+THqvKSVoSxv4LM6xlz+vpN6a2p86kDs2R5R+F H9vMYgVg/xa4Qts0s1zGtf8XiJhpCw0lPFT3Bc1lfzSr0qqtt71bnMT9h DbcwQoDT2JRQU0SV/UkkY7gZPaPk/eZWizmhmzJHWSZwc4c1/83xtCwhm w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AQBQCx3hFV/4YNJK1cgkNDgSwEtjaWBwKBSUwBAQEBAQF9hBUBAQQMfQIBCD8HMhQRAgQBEogbAxHJJQEBAQEBAQEDAQEBAQEBAQEaiyGCR4I2hC0FkFCII4FMjgOGKSKCAhyBUG+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,460,1422921600"; d="scan'208,217";a="406720267" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-2.cisco.com with ESMTP; 24 Mar 2015 22:05:16 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t2OM5Gqh017004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Mar 2015 22:05:16 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.61]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Tue, 24 Mar 2015 17:05:16 -0500 From: "Mo Zanaty (mzanaty)" To: Bernard Aboba , "avtext@ietf.org" Thread-Topic: [avtext] Some comments on draft-berger-avtext-framemarking Thread-Index: AQHQZn6bJNn+l2BMrE2YJS+2f0aG3g== Date: Tue, 24 Mar 2015 22:05:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [64.100.32.216] Content-Type: multipart/alternative; boundary="_000_D135E0524A350mzanatyciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [avtext] Some comments on draft-berger-avtext-framemarking 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, 24 Mar 2015 22:06:00 -0000 --_000_D135E0524A350mzanatyciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Bernard, The "B=94 bit is for base layer sync, like the =93Y=94 bit in VP8 (but unli= ke the =93Y=94 bit in H.264 SVC PACSI). It indicates this packet only depen= ds on the base layer. This would only be derivable from TID if TID=3D0. If = TID>0, there is no way to derive this, it must be signaled explicitly. The codec-specific extensions are admittedly incomplete. At a minimum, we n= eed to define H.264 (SVC), H.265 (v2/SHVC), VP8, and VP9. The key question = to answer for those codecs is what info is critical for RTP switch operatio= ns. Info that is only useful for endpoints should not be necessary in the h= eader extension since it can be extracted from the payload. I agree that for H.264 (SVC), this should include DID and QID; and for H.26= 5, LayerID. I also agree PictureID may be unnecessary. I=92m not sure TL0PI= CIDX is necessary, but agree we should explore it. Regards, Mo On 3/23/15, 3:17 PM, Bernard Aboba > wrote: The basic idea of this draft seems sound to me, and most of the fields pro= posed for the 'Mandatory Extension' (Section 2.1) also make sense to me (wi= th the possible exception of the "B" bit, since for temporal scalability th= is should be derivable from the TID). However, I did want to comment on the Optional Extensions (Section 2.2) sec= tion, where additional fields such as the PictureID and H265-LayerId are di= scussed. In particular, I would argue for the following additional information withi= n Optional Extensions: Additional Layer Identifiers beyond the TID Layer identifiers enable the SFU to determine the temporal, spatial or qual= ity layer of a given packet, which is used in forwarding/drop decisions. Wi= thin H.264/SVC this information is present in the DID(3 bits), QID (4 bits)= and TID (3 bits) fields. Within VP8, it is present in the TID field (2 bit= s). Within H.265, it is present in the LayerID (6 bits) and TID (3 bits) fi= elds. TL0PICIDX This field enables an SFU to determine whether a received frame is dependen= t on a base layer frame which the SFU has not previously received in its en= tirety. This is important information since it may represent the first indi= cation that all or part of a base layer frame needs to be recovered before = the arrival of subsequent base layer frames that depend on it. Within H.264= /SVC the IDRPICID and TL0PICIDX fields are present if the Y bit is set. Wit= hin VP8, the TL0PICIDX field is present if the Y bit is set. However, I would argue against the PictureID field, for the following reaso= ns: While the PictureID field is utilized within the RPSI feedback message, as = well as being supported within the VP8 and VP9 codecs, its use is not essen= tial to an SFU. RPSI feedback messages are rarely supported within existin= g SVC and simulcast implementations, since better loss recovery mechanisms = are available. As a result, an SFU does not need to originate an RPSI messa= ge which would require the PictureID. Where it is necessary for the SFU to = determine which picture a given packet belongs to, RTP header fields such a= s the timestamp and sequence number can be used instead. Similarly, I don't believe that Macroblock identifiers should be considered= (the draft doesn't propose this, but sometimes beating a not-yet-dead hors= e is useful): While macroblock identifiers are universally supported within video codecs,= they are not used by SFUs today. SLI feedback messages (which require a st= arting macroblock) are rarely supported within existing SFUs, since better = loss recovery mechanisms are available. Therefore a codec-independent SFU s= hould never need to source an SLI message. --_000_D135E0524A350mzanatyciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9F28DF5921892B4283C3E41FDEE5BACF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Bernard,

The "B=94 bit is for base layer sync, like the =93Y=94 bit in VP8= (but unlike the =93Y=94 bit in H.264 SVC PACSI). It indicates this packet = only depends on the base layer. This would only be derivable from TID if TI= D=3D0. If TID>0, there is no way to derive this, it must be signaled explicitly.

The codec-specific extensions are admittedly incomplete. At a minimum,= we need to define H.264 (SVC), H.265 (v2/SHVC), VP8, and VP9. The key ques= tion to answer for those codecs is what info is critical for RTP switch ope= rations. Info that is only useful for endpoints should not be necessary in the header extension since it can= be extracted from the payload.

I agree that for H.264 (SVC), this should include DID and QID; and for= H.265, LayerID. I also agree PictureID may be unnecessary. I=92m not sure = TL0PICIDX is necessary, but agree we should explore it.

Regards,
Mo


On 3/23/15, 3:17 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

The basic idea of this draft seems sound to me, and most o= f  the fields proposed for the 'Mandatory Extension' (Section 2.1) als= o make sense to me (with the possible exception of the "B" bit, s= ince for temporal scalability this should be derivable from the TID).
 
However, I did want to comment on the Optional Extensions (Section 2.2) sec= tion, where additional fields such as the PictureID and H265-LayerId a= re discussed.
 
In particular, I would argue for the following additional information withi= n Optional Extensions:
 
Additional Layer Identifiers beyond the TID
 
Layer identifiers enable the SFU to determine the temporal, spatial or qual= ity layer of a given packet, which is used in forwarding/drop dec= isions. Within H.264/SVC this information is present in the DID(3 bits), QI= D (4 bits) and TID (3 bits) fields. Within VP8, it is present in the TID field (2 bits). Within H.265, it is present = in the LayerID (6 bits) and TID (3 bits) fields.  
 
TL0PICIDX
 
This field enables an SFU to determine whether a received frame is dependen= t on a base layer frame which the SFU has not previously received in its en= tirety. This is important information since it may represent the first indi= cation that all or part of a base layer frame needs to be recovered before the arrival of subsequent base la= yer frames that depend on it. Within H.264/SVC the IDRPICID and TL0PICIDX f= ields are present if the Y bit is set. Within VP8, the TL0PICIDX field is p= resent if the Y bit is set.
 
However, I would argue against the PictureID field, for the following reaso= ns:
 
While the PictureID field is utilized within the RPSI feedback message, as = well as being supported within the VP8 and VP9 codecs, its use is not essen= tial to an SFU.  RPSI feedback messages are rarely supported within ex= isting SVC and simulcast implementations, since better loss recovery mechanisms are available. As a result, an SFU d= oes not need to originate an RPSI message which would require the PictureID= . Where it is necessary for the SFU to determine which picture a given pack= et belongs to, RTP header fields such as the timestamp and sequence number can be used instead.
 
Similarly, I don't believe that Macroblock identifiers should be considered= (the draft doesn't propose this, but sometimes beating a not-yet-dead hors= e is useful):
 
While macroblock identifiers are universally supported within video codecs,= they are not used by SFUs today. SLI feedback messages (which require a st= arting macroblock) are rarely supported within existing SFUs, since better = loss recovery mechanisms are available. Therefore a codec-independent SFU should never need to source an SLI messa= ge.
--_000_D135E0524A350mzanatyciscocom_-- From nobody Thu Mar 26 16:00:45 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 ED5881A1B1F for ; Thu, 26 Mar 2015 16:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 x8Q55anq0_qZ for ; Thu, 26 Mar 2015 16:00:43 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77EEC1A1A60 for ; Thu, 26 Mar 2015 16:00:43 -0700 (PDT) Received: from [2001:67c:370:152:466:9a46:a598:789f] (port=54136) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YbGlU-0005HR-4m; Thu, 26 Mar 2015 23:00:41 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: Date: Thu, 26 Mar 2015 18:00:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Espen Berger (espeberg)" X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] draft-avtext-berger-framemarking-00.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: Thu, 26 Mar 2015 23:00:45 -0000 On 19 Nov 2013, at 16:21, Espen Berger (espeberg) = wrote: > The draft discuss usage of RTP header extension to do RTP simulcast = operation on encrypted payload.=20 >=20 > Comments? =20 To echo my comments in the working group session in Dallas: - Given the goal of codec-agnostic processing, there seems to be = considerable codec-specific information carried. I'd be more comfortable = with this draft if the codec-specific information was left to payload = headers, with only the codec-agnostic information (the first byte of the = extension) being sent in a header extension. - There's been some talk of potentially updating SRTP to better support = private centralised conferencing. If that were done, it could = potentially expose enough payload header information to support the use = cases of this draft. It's not necessarily clear that this will happen, = or is a good idea, but it should perhaps be considered.=20 In general, though, I support this work. Cheers, Colin --=20 Colin Perkins https://csperkins.org/ From nobody Thu Mar 26 16:18:19 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 E60E71A1BDF for ; Thu, 26 Mar 2015 16:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 v8tnCaZllfoY for ; Thu, 26 Mar 2015 16:18:12 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E3261A1B12 for ; Thu, 26 Mar 2015 16:18:12 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 80846B4CF78F5 for ; Thu, 26 Mar 2015 23:18:05 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t2QNI9S7003418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 27 Mar 2015 00:18:09 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.230]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 27 Mar 2015 00:18:09 +0100 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Thread-Topic: draft-lennox-avtext-lrr-00 Thread-Index: AdBoGx54geqUZ/g7Rp6/2GFmWn7F6Q== Date: Thu, 26 Mar 2015 23:18:08 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B4A11DC22@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [avtext] draft-lennox-avtext-lrr-00 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: Thu, 26 Mar 2015 23:18:15 -0000 (As WG chair) The Layer Refresh Request (LRR) RTCP Feedback Message At the meeting in Dallas there was clear support for this document and no o= bjections. People seemed to be happy that the scope was about right. This message is to ask the list whether there are any objections in proceed= ing with this work, or any comments that would change the scope of the work= . In the absence of any comments the chairs will progress to ask for an appro= priate charter milestone. Regards Keith= From nobody Thu Mar 26 16:23:29 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 C92271A1BFF for ; Thu, 26 Mar 2015 16:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 1QN12ix_nHAj for ; Thu, 26 Mar 2015 16:23:27 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A90021A1BEA for ; Thu, 26 Mar 2015 16:23:25 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id BA820FE2E70B3 for ; Thu, 26 Mar 2015 23:23:19 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t2QNNNWk007162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 27 Mar 2015 00:23:23 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.230]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 27 Mar 2015 00:23:23 +0100 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Thread-Topic: draft-berger-avtext-framemarking-00 Thread-Index: AdBoG9lsEQ/pytxTS52fpG/AnGEnvw== Date: Thu, 26 Mar 2015 23:23:23 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B4A11DC39@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [avtext] draft-berger-avtext-framemarking-00 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: Thu, 26 Mar 2015 23:23:29 -0000 (As WG chair) Frame Marking RTP Header Extension At the meeting in Dallas there was clear support for work in this area and = no objections. However from the comments in the room there seemed to some concerns that th= e precise nature of the work that needed to be done needed to be discussed = further. Could the chairs ask from the list for text proposals for the charter miles= tone the working group chairs should ultimately be requesting. The authors should also be taking into account any discussion as a result o= f this with a view to revising their draft. Regards Keith= From nobody Thu Mar 26 16:27:19 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 54F621A1AA0 for ; Thu, 26 Mar 2015 16:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 Euyp2180jcN9 for ; Thu, 26 Mar 2015 16:27:17 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425AA1A00C8 for ; Thu, 26 Mar 2015 16:27:17 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id C3A7B30FC77EF for ; Thu, 26 Mar 2015 23:27:11 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t2QNRFBd009527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 27 Mar 2015 00:27:15 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.230]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 27 Mar 2015 00:27:15 +0100 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Thread-Topic: draft-samuelsson-avtext-rpvi-00.txt Thread-Index: AdBoHGRa8zS472+3SkGlNGT3C8PoQA== Date: Thu, 26 Mar 2015 23:27:15 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B4A11DC64@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [avtext] draft-samuelsson-avtext-rpvi-00.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: Thu, 26 Mar 2015 23:27:18 -0000 (As WG chair) This proposal in its current form was not supported, although there seemed = to be a desire from the WG to do some work in this area, potentially with l= ess or no IPR encumbrance. We would ask working group members to work to come up with proposals to fil= l this space, either as revisions of this draft or by the provisions of alt= ernative drafts. Regards Keith= From nobody Fri Mar 27 14:46:13 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 9CF8E1B2B1F for ; Fri, 27 Mar 2015 14:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 vRpLzCK08XEF for ; Fri, 27 Mar 2015 14:46:08 -0700 (PDT) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D0AC1B2B1B for ; Fri, 27 Mar 2015 14:46:08 -0700 (PDT) Received: by pdnc3 with SMTP id c3so108536668pdn.0 for ; Fri, 27 Mar 2015 14:46:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=aceLDfaO/fYTOrH+mOuQgPDjASUTzlvQjKLjD/+kseM=; b=MmGyMDPkLQNPZxf0JtCH9grI4mOb8e3GPu6f1zKhs3blJNArIV4GPq9gxIGXv6bTm2 lIcwQX6U45pbQjcSiwD5ygUzQv1YyOJf0/kUtUW8ERNnbP7Gp+M9u5ZoFaKGo6/JtxHQ pyD+R71GyuG/JmF33dauSp4J4HVJXLF0t1Js2COKmYLZ1Nl9hx9IxCUY02sh5nrGZM7h zpPUD98rScBM3b+siF5KJ5uWVbqMTq36fopD9k3wzIDFFmv7pWrmTso9osxVXKD/HDlp xt0z7LZwzMeVSQvqc6spyw9yxxSxqlaoZgGJYnplARDR6gpAeNRSwXBL47+VPDaWhIPg vvYA== X-Gm-Message-State: ALoCoQlnO8C+ABMjCCSohpA1B83sRCKgOMTnakEa+G4usOgmHy7nrssXznsuTcxWmUqGGz5h/1e8 X-Received: by 10.66.233.35 with SMTP id tt3mr39047400pac.36.1427492768105; Fri, 27 Mar 2015 14:46:08 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:7e7a:91ff:fe9e:8126? ([2620:101:80fc:224:7e7a:91ff:fe9e:8126]) by mx.google.com with ESMTPSA id lr1sm3111406pab.39.2015.03.27.14.46.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Mar 2015 14:46:06 -0700 (PDT) Message-ID: <5515CF9D.2060706@mozilla.com> Date: Fri, 27 Mar 2015 14:46:05 -0700 From: Thomas Daede User-Agent: http://a.pomf.se/cszdno.opus MIME-Version: 1.0 To: avtext@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [avtext] RTP switch behavior in draft-berger-avtext-framemarking-00 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, 27 Mar 2015 21:46:11 -0000 Currently, the framemarking draft specifies a set of flags and what kind of concept they map to in various video codecs. However, switch behavior is only defined based on the I and D bits. How are the other bits, such as TID intended to be used? Does the switch include RTCP based throttling logic? Or is there some other sideband that tells the switch what temporal layer to send? The TID also seems quite underspecified. To use it smartly, you need to know the actual number of layers and when it is safe to switch, which is information only the endpoints would have. Other nit: instead of defining the I bit as: MUST be 1 for frames that can be decoded indepedent of prior frames I would use the text (could use better wording): MUST be 1 for frames where both the current frame and all future frames can be decoded without any frames before the frame with the 'I' bit set. From nobody Fri Mar 27 16:33:18 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 592391A0187 for ; Fri, 27 Mar 2015 16:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, 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 opMDcMhEwzEd for ; Fri, 27 Mar 2015 16:33:15 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0784.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:784]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B07851A017F for ; Fri, 27 Mar 2015 16:33:14 -0700 (PDT) Received: from CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) by CY1PR0701MB1273.namprd07.prod.outlook.com (25.160.149.16) with Microsoft SMTP Server (TLS) id 15.1.118.21; Fri, 27 Mar 2015 23:32:52 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) by CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) with mapi id 15.01.0118.022; Fri, 27 Mar 2015 23:32:52 +0000 From: Stephan Wenger To: "avtext@ietf.org" Thread-Topic: Frame marking header extension Thread-Index: AQHQaOZXGzVvBvzpsE6ZLtbF6br2UQ== Date: Fri, 27 Mar 2015 23:32:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [12.203.54.183] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1273; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(54356999)(2900100001)(66066001)(77156002)(62966003)(2501003)(50986999)(36756003)(106116001)(16236675004)(107886001)(102836002)(86362001)(46102003)(2656002)(87936001)(122556002)(92566002)(110136001)(99286002)(2351001)(229853001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1273; H:CY1PR0701MB1276.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CY1PR0701MB1273; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1273; x-forefront-prvs: 0528942FD8 Content-Type: multipart/alternative; boundary="_000_D13B36AE526BDstewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2015 23:32:52.0687 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1273 Archived-At: Subject: [avtext] Frame marking header extension 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, 27 Mar 2015 23:33:17 -0000 --_000_D13B36AE526BDstewesteweorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I was asked to also put the comment below on the list, which I hereby do. The frame marking draft seems to be a good and useful technology, however i= t could be made somewhat more future-proof. In particular, I suggest that = the "mandatory one byte header" should be extended to include a few reserve= d bits for future use. Another issue that came to my mind is that your hypothetical middle box doe= s not know which codec is in use (and thereby cannot interpret the codec-sp= ecific fields correctly) without intercepting and interpreting the signalin= g. At least one of the authors of this draft is known to be as a big fan o= f self-describing RTP (to the extent possible) :-). Perhaps you want to sp= end a few bits of the extended mandatory one byte header proposed above to = provide in-band info what codec is in use? Stephan --_000_D13B36AE526BDstewesteweorg_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

I was asked to also put the comment below on the list, which I hereby = do.

The frame marking draft seems to be a good and useful technology, howe= ver it could be made somewhat more future-proof.  In particular, I sug= gest that the “mandatory one byte header” should be extended to= include a few reserved bits for future use.  

Another issue that came to my mind is that your hypothetical middle bo= x does not know which codec is in use (and thereby cannot interpret the cod= ec-specific fields correctly) without intercepting and interpreting the sig= naling.  At least one of the authors of this draft is known to be as a big fan of self-describing RTP (to the e= xtent possible) :-).  Perhaps you want to spend a few bits of the exte= nded mandatory one byte header proposed above to provide in-band info what = codec is in use?
 
Stephan
--_000_D13B36AE526BDstewesteweorg_-- From nobody Fri Mar 27 17:09:34 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 565A91A00C8 for ; Fri, 27 Mar 2015 17:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=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 7iRE5iiXS2yo for ; Fri, 27 Mar 2015 17:09:31 -0700 (PDT) Received: from BLU004-OMC2S4.hotmail.com (blu004-omc2s4.hotmail.com [65.55.111.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C162C1A002D for ; Fri, 27 Mar 2015 17:09:30 -0700 (PDT) Received: from BLU406-EAS365 ([65.55.111.71]) by BLU004-OMC2S4.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Fri, 27 Mar 2015 17:09:30 -0700 X-TMN: [AbRaYeMGmx6mMqq9VhUtYHyFr7Cne+rV] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable References: <5515CF9D.2060706@mozilla.com> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <5515CF9D.2060706@mozilla.com> Date: Fri, 27 Mar 2015 19:09:25 -0500 To: Thomas Daede X-OriginalArrivalTime: 28 Mar 2015 00:09:30.0242 (UTC) FILETIME=[76240620:01D068EB] Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] RTP switch behavior in draft-berger-avtext-framemarking-00 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: Sat, 28 Mar 2015 00:09:33 -0000 On Mar 27, 2015, at 4:46 PM, Thomas Daede wrote: >=20 > Currently, the framemarking draft specifies a set of flags and what kind > of concept they map to in various video codecs. However, switch behavior > is only defined based on the I and D bits. How are the other bits, such > as TID intended to be used? [BA] same as it would if it were in the payload. > Does the switch include RTCP based > throttling logic? Or is there some other sideband that tells the switch > what temporal layer to send? [BA] RTCP and signaling are the control channel. Switch decides based on man= y of the same factors used in congestion control.=20 >=20 > The TID also seems quite underspecified. To use it smartly, you need to > know the actual number of layers and when it is safe to switch, which is > information only the endpoints would have. [BA] Max TID could be signaled in which case SFU will have it. Switching sh= ould be informed by TID, S, E bits.=20 >=20 > Other nit: instead of defining the I bit as: >=20 > MUST be 1 for frames that can be decoded indepedent of prior frames >=20 > I would use the text (could use better wording): >=20 > MUST be 1 for frames where both the current frame and all future frames > can be decoded without any frames before the frame with the 'I' bit set. >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Tue Mar 31 07:27:14 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 AD8881ACD78 for ; Tue, 31 Mar 2015 07:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.797 X-Spam-Level: X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Km3n2NnJeGN for ; Tue, 31 Mar 2015 07:27:11 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D1BE1ACD6B for ; Tue, 31 Mar 2015 07:27:11 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id t2VEQtE2025214; Tue, 31 Mar 2015 10:27:09 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 1t74r6dxyt-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 31 Mar 2015 10:27:09 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Tue, 31 Mar 2015 09:27:09 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: WGLC for draft-ietf-avtext-splicing-notification-01 Thread-Index: AQHQa77ENV6jjzL+3kyeTYpe/9M1/Q== Date: Tue, 31 Mar 2015 14:27:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="us-ascii" Content-ID: <316D1FBC0EFB2E4989F5FCF98D448149@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-31_04:2015-03-31,2015-03-31,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1503310130 Archived-At: Cc: "avtext-chairs@tools.ietf.org" , "draft-ietf-avtext-splicing-notification@tools.ietf.org" Subject: [avtext] WGLC for draft-ietf-avtext-splicing-notification-01 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, 31 Mar 2015 14:27:12 -0000 This is to announce a 3 week Working Group Last Call for draft-ietf-avtext-splicing-notification-01 as proposed standard. Please review and provide any comments you may have on the document by Tues= day, April 21, 2015. Comments should be sent to the document authors and th= e AVTEXT WG list. If you review the document but do not have any comments, = please send a note to that effect as well. Please also forward this WGLC call to any other interested parties who may = be able to review the draft, asking them to also direct their comments to t= he authors and the list as above. Thank you! Jonathan (AVTEXT co-chair) Draft information: This draft is a work item of the Audio/Video Transport Extensions Working= Group of the IETF. Title : RTP/RTCP extension for RTP Splicing Notification Authors : Jinwei Xia Roni Even Rachel Huang Lingli Deng Filename : draft-ietf-avtext-splicing-notification-01.txt Pages : 17 Date : 2014-12-10 Abstract: Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content, and delivers the substitutive multimedia content to the receivers for a period of time. The splicer is designed to handle RTP splicing and needs to know when to start and end the splicing. This memo defines two RTP/RTCP extensions to indicate the splicing related information to the splicer: an RTP header extension that conveys the information in-band and an RTCP packet that conveys the information out-of-band. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtext-splicing-notification-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-splicing-notification-= 01 Please note that it may take a couple of minutes from the time of submissio= n 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/