From nobody Wed Feb 1 02:42:59 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E10D3129D18 for ; Wed, 1 Feb 2017 02:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuUdXkdvp78W for ; Wed, 1 Feb 2017 02:42:55 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66FE9129424 for ; Wed, 1 Feb 2017 02:42:54 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFP31179; Wed, 01 Feb 2017 10:42:52 +0000 (GMT) Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 1 Feb 2017 10:42:50 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0301.000; Wed, 1 Feb 2017 18:42:44 +0800 From: Roni Even To: IETF AVTCore WG Thread-Topic: Need feedback on RFC5285bis (RTP header extensions) comments Thread-Index: AdJ8cvwqQ20XYkJqScm51Efh6qfqvg== Date: Wed, 1 Feb 2017 10:42:42 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD770167@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.150] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD770167DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.5891BBAC.0131, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ac2151dff37877f5ba5a64be817e2399 Archived-At: Cc: David Singer Subject: [AVTCORE] Need feedback on RFC5285bis (RTP header extensions) comments X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 10:42:59 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD770167DGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Paul made a very thorough SDP review and had some comments on which I am lo= oking for feedback. 1. In section 7 "If an extension is marked as "sendonly" and the answ= erer desires to receive it, the extension MUST be marked as "recvonly" in = the SDP answer. An answerer that has no desire to receive the extension or= does not understand the extension SHOULD remove it from the SDP answer." = . Is there a reason for the "SHOULD" here or should we change it to "MUST" = or maybe if not removed to respond with "inactive" or "sendonly" if want = to send and and not receive? 2. In this case if the offer is refused by removing the extmap line, = can the ID be re-used? 3. In section 7 "Local identifiers in the valid range inclusive in a= n offer or answer MUST NOT be used more than once per media section (includ= ing the session-level section). A session update MAY change the direction = qualifiers of extensions under use. A session update MAY add or remove ext= ension(s). Identifiers values in the valid range MUST NOT be altered (rema= pped)." Paul asked what is the scope over which identifiers must not be alt= ered. His thought was only for the current RTP session so when a call is tr= ansferred (one party is still in the call) they may be altered. Any thought= s? 4. Is it valid to use IDs in the (unusable) range in answers? (I gues= s that would give the offerer info that it could use in a future offer.). I= am not sure what was meant here. Is it an answer to an offer with an ID in= the valid range? Or is it about keeping an alternative from the offer with= the unusable space and not remove it? I assume that the answer cannot add = extensions to the ones in the offer, will need a new offer for that. 5. May values from the (unused) range that are used in offers (or ans= wers) be reused differently in subsequent offers? 6. Would the following be valid? (Only the directionality differs.) OFFER: a=3Dextmap:4096/sendonly http://example.com/082005/ext.htm#opt1 a=3Dextmap:4096/recvonly http://example.com/082005/ext.htm#opt1 7. Is it allowed to use the "alternatives" mechanism with only a sing= le alternative? This would be a way to avoid "wasting" an ID value until yo= u know if your peer supports the option. I see this usage in an example, bu= t it is not mentioned in text. If this is an intended usage then it would b= e good to provide some further explanation. Thanks Roni Even As the document editor. --_000_6E58094ECC8D8344914996DAD28F1CCD770167DGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Paul made a very thorough SDP review and had some co= mments on which I am looking for feedback.

 

1.&nb= sp;      In section 7 “= ;If an extension is marked as "sendonly&qu= ot; and the answerer desires to  receive it, the extension MUST be mar= ked as "recvonly" in the SDP answer.  An answerer that has no desire to receive the extension or does not understand the extension SH= OULD remove it from the SDP  answer.” . Is there a reason for th= e “SHOULD” here or should we change it to “MUST” or= maybe if not removed to  respond with “inactive”  or= “sendonly” if want to send and and not receive?

 =

2.&nb= sp;      In this case if the offer is refused by removing the extmap line, = can the ID be re-used?

 =

3.     &= nbsp;  In section 7 “Local identifiers in the valid range inclusive in an offer or answer M= UST NOT be used more than once per media section (including the session-level section).  A session update MAY change t= he direction qualifiers of extensions under use.  A session update MAY= add or remove extension(s).  Identifiers values in the valid range MU= ST NOT be altered (remapped).” Paul asked what is the scope over which identifiers must not be altered. His though= t was only for the current RTP session so when a call is transferred (one p= arty is still in the call) they may be altered. Any thoughts?

 

4.     &= nbsp; Is it valid to use IDs in = the (unusable) range in answers? (I guess that would give the offerer info = that it could use in a future offer.). I am not sure what was meant here. I= s it an answer to an offer with an ID in the valid range? Or is it about keeping an alternative from the offe= r with the unusable space and not remove it? I assume that the answer canno= t add extensions to the ones in the offer, will need a new offer for that.

 

5.     &= nbsp; May values from the (unuse= d) range that are used in offers (or answers) be reused differently in subs= equent offers?

 

6.     &= nbsp; Would the following be val= id? (Only the directionality differs.)

 

     OFFER:

     a=3Dextmap:4096/sendonly= http://example.com/082005/ext.htm#opt1

     a=3Dextmap:4096/recvonly= http://example.com/082005/ext.htm#opt1

 

7.       Is it allowed to use the &= quot;alternatives" mechanism with only a single alternative? This woul= d be a way to avoid "wasting" an ID value until you know if your = peer supports the option. I see this usage in an example, but it is not mentioned in text. If this is an intended usage then it woul= d be good to provide some further explanation.

 

 

Thanks

Roni Even

As the document editor.

 

&n= bsp;

 

--_000_6E58094ECC8D8344914996DAD28F1CCD770167DGGEMM506MBXchina_-- From nobody Wed Feb 1 10:48:28 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A61129474 for ; Wed, 1 Feb 2017 10:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKXw1EgyQkgF for ; Wed, 1 Feb 2017 10:48:06 -0800 (PST) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (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 3EE5C129D11 for ; Wed, 1 Feb 2017 10:48:06 -0800 (PST) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-03v.sys.comcast.net with SMTP id Yzv6cSbkkdEjjYzwrcmvQD; Wed, 01 Feb 2017 18:48:05 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-20v.sys.comcast.net with SMTP id YzwqcAsTnqiCcYzwrcNipe; Wed, 01 Feb 2017 18:48:05 +0000 To: Roni Even , IETF AVTCore WG References: <6E58094ECC8D8344914996DAD28F1CCD770167@DGGEMM506-MBX.china.huawei.com> From: Paul Kyzivat Message-ID: <2f4e19a4-01ae-a056-b18b-6ad7669db3c2@alum.mit.edu> Date: Wed, 1 Feb 2017 13:48:04 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD770167@DGGEMM506-MBX.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfOKPYshS9UIK9sDCybQSPRvwvAvSyzvA9Cwqr18SF/s1Ew0JKX2u9BPRaxhaO/xor9YHbC+JXcemdT7LDx30ujNxJ85QEJgjqy76tBlZSYT8109SrMsf 2QJTbsFXnq4uuZe6eToaJzoyOjek7Ootso2ZAi8LAZTrqiVdFjP69w2jqHVFwIQiiLzM0tnzF/LJAzGMuB312xC1lse7JMa84vlKMwY6JqkLJc7npElcyHxp Archived-At: Cc: David Singer Subject: Re: [AVTCORE] Need feedback on RFC5285bis (RTP header extensions) comments X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 18:48:08 -0000 X-List-Received-Date: Wed, 01 Feb 2017 18:48:08 -0000 On 2/1/17 5:42 AM, Roni Even wrote: > 4. Is it valid to use IDs in the (unusable) range in answers? (I > guess that would give the offerer info that it could use in a future > offer.). I am not sure what was meant here. Is it an answer to an offer > with an ID in the valid range? Or is it about keeping an alternative > from the offer with the unusable space and not remove it? I assume that > the answer cannot add extensions to the ones in the offer, will need a > new offer for that. Clarifying what I meant: My first question is: is it valid an extmap attribute with an ID in the (unusable) range appear in an SDP answer? If the answer to that is Yes, then a followon question is: what does that mean? It occurred to me that it might be used by the answerer to indicate to the offerer some extensions that it is willing to use that were not mentioned in the offer. I ask this mostly for completeness - the spec is silent on the matter. Thanks, Paul From nobody Wed Feb 1 18:45:34 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D739512961A for ; Wed, 1 Feb 2017 18:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9zD9bEYVs2K for ; Wed, 1 Feb 2017 18:45:30 -0800 (PST) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (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 D61F21294AD for ; Wed, 1 Feb 2017 18:45:30 -0800 (PST) Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-09v.sys.comcast.net with SMTP id Z7Ojc0KCa3kZMZ7Orcd3vK; Thu, 02 Feb 2017 02:45:29 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-po-12v.sys.comcast.net with SMTP id Z7OpcGDjbL4A9Z7OqcVqPQ; Thu, 02 Feb 2017 02:45:29 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v122jQjK013827; Wed, 1 Feb 2017 21:45:26 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v122jQse013822; Wed, 1 Feb 2017 21:45:26 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Roni Even In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD770167@DGGEMM506-MBX.china.huawei.com> (roni.even@huawei.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 01 Feb 2017 21:45:25 -0500 Message-ID: <8760kt71kq.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfAVk8xqRL0AzTwx7vlHWT3Yx7SYNQ4dsxsO3z2WYYkv+NZMIrBuzx8Iw+g+DTPBUZa93uCADFeoQmWnisdnyIVjWRAf+KJupedMeAuxMd2PinVNvJnEt R+L8VMBdiwd9SCZoiA39tu5//V+oNlhaDNDrtVQ+vD9buZyM2XPsqW1cB5MJIqv9ql+X1yejjbtNu/l+VSei7yHZMIyQsZAdk90= Archived-At: Cc: avt@ietf.org, singer@apple.com Subject: Re: [AVTCORE] Need feedback on RFC5285bis (RTP header extensions) comments X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 02:45:33 -0000 Roni Even writes: > Paul made a very thorough SDP review and had some comments on which I > am looking for feedback. I didn't realize that this draft was so interesting. Given that it's still under review, even though it's a month after the official end of the last call, I'll post my full comments later. In the mean time: > 1. In section 7 "If an extension is marked as "sendonly" and the > answerer desires to receive it, the extension MUST be marked as > "recvonly" in the SDP answer. An answerer that has no desire to > receive the extension or does not understand the extension SHOULD > remove it from the SDP answer." . Is there a reason for the "SHOULD" > here or should we change it to "MUST" or maybe if not removed to > respond with "inactive" or "sendonly" if want to send and and not > receive? I think the idea is that if the offer contains "sendonly" and the answerer wants to receive it, then the answer must contain "recvonly". But if the answerer doesn't want to receive it, then the answerer must set it to "inactive" or remove the attribute, and the latter is preferred. At least, that makes sense, and it makes the MUSTs and SHOULDs correct, though that's probably not the clearest way to express the meaning. > 2. In this case if the offer is refused by removing the extmap > line, can the ID be re-used? I think the point of this text in section 7 is that if an extension identifier could get used in RTP packets (i.e., is in the answer), then a session update can't immediately define that identifier to a new URI: Identifiers values in the valid range MUST NOT be altered (remapped). That protects packets in flight from misinterpretation. But if the extension identifier isn't accepted in the offer, then there's no problem with packets in flight, and the next session update can allocate the identifier to a different extension. However, this text in section 7 seems to say that if an identifier is in the offer, even if it isn't in the answer, both endpoints can use it: Either party MAY include extensions in the stream other than those negotiated, or those negotiated as "inactive", for example, for the benefit of intermediate nodes. Only extensions that appeared with an identifier in the valid range in SDP originated by the sender can be sent. In that case, packets in flight could be using an identifier that was not accepted in the answer. My opinion is that the latter text is not a good idea. > 3. In section 7 "Local identifiers in the valid range inclusive > in an offer or answer MUST NOT be used more than once per media > section (including the session-level section). A session update MAY > change the direction qualifiers of extensions under use. A session > update MAY add or remove extension(s). Identifiers values in the > valid range MUST NOT be altered (remapped)." Paul asked what is the > scope over which identifiers must not be altered. His thought was only > for the current RTP session so when a call is transferred (one party > is still in the call) they may be altered. Any thoughts? Good point -- this is the same problem as reusing RTP payload types. In theory you don't want to reuse them at all, or at least, not use them for different encodings immediately before and after one single session update, because there may be packets in flight using that payload type. But various call transfer and 3PCC scenarios make that very difficult to ensure in practice. > 4. Is it valid to use IDs in the (unusable) range in answers? (I > guess that would give the offerer info that it could use in a future > offer.). I am not sure what was meant here. Is it an answer to an > offer with an ID in the valid range? Or is it about keeping an > alternative from the offer with the unusable space and not remove it? > I assume that the answer cannot add extensions to the ones in the > offer, will need a new offer for that. I think it's a mechanism to allow the answerer to say "I support that extension" even if it can't allocate a valid identifier for it, or if it doesn't want to use the extension now. (But see the second quoted passage under item 2 and its discussion.) Though it's not clear to me how useful that facility is. In general, a UA should always offer everything that it is willing to support because any information it has cached about the capabilities/desires of the other endpoint could be invalid now. > 5. May values from the (unused) range that are used in offers > (or answers) be reused differently in subsequent offers? I believe the intention is that they may be reused. The text does not forbid that: Identifiers values in the valid range MUST NOT be altered (remapped). And there is no packets-in-flight problem. > 6. Would the following be valid? (Only the directionality differs.) > > OFFER: > > a=extmap:4096/sendonly http://example.com/082005/ext.htm#opt1 > > a=extmap:4096/recvonly http://example.com/082005/ext.htm#opt1 That's subtle: the identifier is mapped to the same extension in both directions, but each direction is mapped by a different extmap attribute. Yeah, that's forbidden in section 5: In addition, as noted above, the IDs used MUST be unique for each stream type for a given media, or for the session for session-level declarations. > 7. Is it allowed to use the "alternatives" mechanism with only a > single alternative? This would be a way to avoid "wasting" an ID value > until you know if your peer supports the option. I see this usage in > an example, but it is not mentioned in text. If this is an intended > usage then it would be good to provide some further explanation. Well, it isn't an "alternative" construction because there's only one attribute with that identifier. But it's not forbidden to write just one attribute with an extended identifier value. However, telling the other UA that you support an extension isn't very useful, because the next time the other UA updates the session, you may not be the UA on this end of the call. Dale From nobody Wed Feb 1 18:46:52 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7EE129620 for ; Wed, 1 Feb 2017 18:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BL0djnWNn8SP for ; Wed, 1 Feb 2017 18:46:49 -0800 (PST) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (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 1646112961A for ; Wed, 1 Feb 2017 18:46:49 -0800 (PST) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-12v.sys.comcast.net with SMTP id Z7Q6cso1onZkvZ7Q8cYkBY; Thu, 02 Feb 2017 02:46:48 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-po-14v.sys.comcast.net with SMTP id Z7Q6cQ5vRhLvUZ7Q7cUens; Thu, 02 Feb 2017 02:46:48 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v122kj3t013890; Wed, 1 Feb 2017 21:46:45 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v122kjjn013887; Wed, 1 Feb 2017 21:46:45 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: avt@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 01 Feb 2017 21:46:45 -0500 Message-ID: <874m0d71ii.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfF6MRNnbUhZajPvPQO6suxBWx//OubPW6nAcf4OR4adIVHO+1QDHwGRS1nvkrQp4ryqNWoCKgxtiLYRAR7tiHDim821r6xw23Luw0jPZs5U0ThkIq9bV 37Rd5KbbEzHyLNoAy48d4qMJ0W6reYJ94lNhC0AQq+P0jKORlUobYpXLyk+UoB6KK6NPYYveYqnVvoFv/lkkDKg11vN10bNwBhE= Archived-At: Cc: singer@apple.com Subject: [AVTCORE] Coments on draft-ietf-avtcore-rfc5285-bis-05 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 02:46:50 -0000 This is rather late, but it seems that the document is still under active development. * Technical items: 4.2. One-Byte Header The ID value 15 is reserved. But there is also the invalid case where the ID field is 0 and the len field is non-zero. That case should probably be included in the same exception processing as for ID value 15. 5. SDP Signaling Design A usable mapping MUST use IDs in the valid range, and each ID in this range MUST be used only once for each media (or only once if the mappings are session level). It would be useful to state early in this section that in order to reduce the complexity of negotiating identifiers, a valid SDP must not have mapping attributes (extmap) at both the session level and the media level. Also, that it is semantically equivalent to have a set of extmaps at the session level and to have the same set of extmaps duplicated in each media section. In particular, if an offer contains extmaps at the session level and the answerer wishes to modify the extension mapping for one media stream but not the others, it can move the extmaps from the session level of the offer to every media section in the answer, and then modify the extmaps in the desired media section. There is some vagueness about the use of extmaps using identifiers outside the valid range, and the use of duplicate IDs. At one point, it seems to be stated that for a session description to be acted upon, only valid identifiers can be specified, and each can be specified only once -- but that in an offer/answer situation, the offer can use duplicate identifiers, and can use identifiers in the extended range, and the answer then produces SDP that obeys the validity rules. Then elsewhere, it is said that the answer can have extmaps in the extended range. I think there needs to be a clear summary of the various combinations that can happen during offer/answer of duplicated identifiers and identifiers in the extended range, because this sort of behavior pattern is unusual in SDP. Also, if an answer uses a different ID for a URI than the offer, do both the offerer and answerer use the answer's IDs? The text suggests so, but that is different from how payload types are used. In any case, the rules need to be made very clear. There's also a question of what URIs may be used and how they are considered. The term "absolute URI" seems to be poorly defined, since RFC 3986 uses "absolute URI" to mean what matches the production "absolute-URI", but that means a URI without a fragment part. I think here we mean "a URI containing a 'path-absolute'", but I don't think that admits URNs. (And all existing registered extension names are URNs.) So this definition needs to be cleaned up. I think in reality, these URIs are used as nearly-opaque identifiers; the exception being that a device that accepts the extension labeled with a URI will necessarily know what the rules are for testing for equality with that URI. But is there any reason to allow URIs that aren't URNs? (Within URNs, issues of equality testing, etc., are generally well-specified.) The text seems to suggest that the URI can be used to look up the meaning of the extension in some way other than using the URI to index a database, but I don't see how that can be made to work in practice. And once the URIs are indexes, it seems best to limit them to being URNs. Then again, XML namespaces are named by URIs, not just URNs. The meaning of the sendonly, etc. attributes seems to be inadequately specified. Given that an extmap attribute can exist at the session level even when media streams have different direction attributes, it seems that the only simple rule is that the direction attribute in the extmap determines which direction(s) the extension may be sent in theoretically, but because of media directionality, the header will only be sent in a direction that is within the directionality of the extmap and also the directionality of the stream. Similarly to media directionality, the directionality given in an answer for a particular extmap URI must be a subset of the directionality given in the offer. URIs that contain a domain name SHOULD also contain a month-date in the form mmyyyy. There isn't any standardized way to do this. Should there be some indicator that the month indication is ad hoc, such as: URIs that contain a domain name SHOULD in some manner contain a month-date in the form mmyyyy. -- If the resource or document defines several extensions, then the URI MUST identify the actual extension in use, e.g., using a fragment or query identifier (characters after a '#' or '?' in the URI). This text suggests that the URI in some way can be processed to directly identify a "resource or document". But there is no general resolution process for doing that; the method by which the URI indicates the extension definition is entirely outside this specification. In practice, the device contains a small table of URIs that it recognizes. Within that conceptual structure, the rule is simply that different extensions must be identified by different URIs, and as a consequence, URIs that differ only by fragment or query identifier identify different extensions. When SDP signaling is used for the RTP session, it is the presence of the 'extmap' attribute(s) that is diagnostic that this style of header extensions is used, not the magic number indicated above. I *think* this means that the presence of this SDP signaling implies that all RTP header extensions will be of the type defined here, regardless of their 16-bit identifiers. But that's not a useful fact, because the header extension can't be parsed without first knowing which variety of extension is it, and that is determined by the 16-bit identifier value. So I think the best you can do is say When SDP signaling is used for the RTP session, if 'extmap' attribute(s) are present, all RTP extension headers MUST be of one of the two forms specified in this document. 6. SDP Signaling for support of mixed one byte and two bytes header For simplicity, it seems that you'd want to allow the positioning of extmap-allow-mixed (session level vs. media level) to be independent of the positioning of extmap. I expect this is intended, but it's worth stating it explicitly, given the limitations on how extmap attributes can be placed. Given that it is envisioned that some systems may not support the two-byte form (section 4.1.2 paragraph 2), should there be a way to enforce the use of only the one-byte form? In particular, this might be desirable: If all of the identifier values in the offer are less than 15, then all of the identifier values in the answer MUST be either less than 15 or greater than 4095. If all of the identifier values in the answer are less than 15, then the RTP stream MUST NOT user the two-byte extension form. That allows both the offerer and the answerer to force use of the one-byte form. 7. Offer/Answer Extensions, with their directions, MAY be signaled for an "inactive" stream. It is an error to use an extension direction incompatible with the stream direction (e.g., a "sendonly" attribute for a "recvonly" stream). This is unworkable if the extension attribute is at the session level. E.g., there could be one media stream that is "sendonly" and one that is "recvonly", which would require all extension attribute directions to be "inactive". I think you need to allow the extension attribute direction specifications to be orthogonal to the medial directions. Local identifiers in the valid range inclusive in an offer or answer MUST NOT be used more than once per media section (including the session-level section). A session update MAY change the direction qualifiers of extensions under use. A session update MAY add or remove extension(s). Identifiers values in the valid range MUST NOT be altered (remapped). There is a lot here. The duplicate identifiers are clearly allowed -- that is discussed elsewhere in these comments. A session update may change the direction qualifiers, of course, because a session update is an entirely new negotiation, so that need not be stated. Similarly for adding or removing extensions. But what does the last sentence mean? There is much discussion of remapping identifier values in earlier sections. Does it perhaps mean that if an identifier value goes into use (by being in the valid range and in the answer), then a session update offer MAY NOT map it to a different URI? This may be a good rule, because it ensures that RTP extension headers in-flight won't be misinterpreted. But it might be better phrased: A session update offer or answer may not specify a different URI for an identifier that is in currently in use in the session (i.e., that is in the valid range and was specified in the answer that describes the session). (However, an identifier that is currently in use can be unmapped in one session update offer/answer cycle and then subsequently mapped to a different URI in a later session update.) -- Either party MAY include extensions in the stream other than those negotiated, or those negotiated as "inactive", for example, for the benefit of intermediate nodes. Only extensions that appeared with an identifier in the valid range in SDP originated by the sender can be sent. This seems odd. If the negotiated SDP (the answer) doesn't contain an extmap or marks it inactive, why should both endpoints be allowed to send it? And isn't it the identifier number in the answer that control (because the answer is allowed to remap the extension types in the offer)? I think this needs to be rethought. 8. BNF Syntax (only absolute URIs are permitted here) If we maintain this restriction, a clear definition or reference for "absolute URI" needs to be made. The BNF allows five-digit identifiers, whereas the text allows identifiers only up to 4351. I see that the intention is that the range may be increased later, but I would think four digit numbers would suffice. 9. Security Considerations Extensions usage is negotiated using [RFC3264] so integrity protection and end-to-end authentication MUST be used. This seems remarkably strict, since roughly nobody uses end-to-end integrity/authentication in SIP. * Editorial items: Abstract The document obsoletes RFC5285 s/The/This/ Add a final full stop. 1. Introduction both one byte and two bytes header I think the standard usage is "two byte" when that phrase is being used as a modifier. 4.1. General The value defined for an RTP extension (defined below for the one-byte and two-byte header forms) is ... This is awkwardly phrased; what is "the value defined for an extension". Unfortunately, RFC 3550 didn't give a proper name to the field in question. I suggest copying the wording in the introduction, which was clearer: The 16-bit identifiers for the two forms of RTP extension defined here are only architectural constants (e.g., for use by network analyzers); it is the out-of-band negotiation/definition (e.g., in SDP) that is the definitive indication that this header extension is present. 4.1.1. transmission considertions s/considertions/considerations/ actually, s/transmission considertions/Transmission Considerations/ 4.1.2. Header Extension type consideration s/type consideration/Type Consideration/ Perhaps change "one-byte form" and "two-byte form" to "one-byte format" and "two-byte format"? The latter read better to me. Each RTP packet with an RTP header extension following this specification will indicate if it contains one or two byte header extensions through the use of the "defined by profile" field. Better, "...though the value of the...". Transmitters SHOULD NOT use the two-byte form when all extensions are small enough for the one-byte header form. You should probably add, "... when all extension use IDs less than 15 and the extension data is small enough ...". That makes it correct, and makes it clearer why negotiating an ID over 14 signals an intention to use the two-byte form. Transmitters that intend to send the two-byte form SHOULD use IDs above 14 if they want to let the Receivers know that they intend to use two-byte form ... Better to say "... SHOULD negotiate the use of IDs above 14 to let ...". 4.3. Two-Byte Header For the purposes of signaling, this field is treated as a special extension value assigned to the local identifier 256. This is awkwardly phrased, since this isn't a signaling datum. I assume you mean This field is treated as the data field of the extension assigned to the local identifier 256. (Of course, an extension assigned identifier 256 must define the interpretation of four-bit values.) -- Note that there is one ID space for both one-byte and two-byte form this means that the lower values (1-14) can be used in the 4-bit ID field in the one-byte header format as well. The clauses don't join together correctly. Perhaps: Note that there is one ID space for both one-byte and two-byte forms. This means that the lower values (1-14) can be used in the 4-bit ID field in the one-byte format with the same meanings. 5. SDP Signaling Design An extension URI with the same attributes MUST NOT appear more than It would be clearer if you phrased this: There must not be multiple identifier definitions applying to one stream with the same extension URI and extension-attributes. (Then s/// in the BNF.) ... can appear differently parameterized for the same stream. s/differently parameterized/with different extension-attributes/ In addition, as noted above, the IDs used MUST be unique for each stream type for a given media, or for the session for session-level declarations. It is not clear what this means. As noted above, the same extended ID can be used multiple times in an offer. And what a "stream type" is is not defined. Each local identifier potentially used in the stream is mapped to a string using an attribute of the form: What does "is mapped to a string" mean? Does it mean "is mapped to an extension identified by a URI"? is an integer in the valid range inclusive (0 is reserved for padding in both forms, and 15 is reserved in the one- byte header form, as noted above) The phrase "valid range inclusive" is used in several places and is unclear. I think "valid range" is what is intended. There's no particular reason to partially describe the valid range here, as it has already been explained. And the text about 15 is irrelevant, as ID 15 can validly be used in two-byte headers. is one of "sendonly", "recvonly", "sendrecv", or "inactive" (without the quotes) with relation to the device being configured. Within the context of the above proposal that the extmap direction value is orthogonal to stream direction attribute, it should be noted here that "sendrecv" is the default value. 6. SDP Signaling for support of mixed one byte and two bytes header The formal definition of this attribute is: Name: extmap-allow-mixed I would expect this formal definition to be in the IANA considerations section. Indeed, it *is* in the IANA considerations. Why is it duplicated here? When doing SDP Offer/Answer [RFC3264] an offering client that wishes to use both one and two bytes extensions MUST include the attribute "a= extmap-allow-mixed " in the SDP offer. If "a= extmap-allow-mixed " is present in the offer SDP, the answerer that supports this mode and wishes to use it SHALL include the "a=extmap-allow-mixed " attribute in the answer. There are extra spaces in the various occurrences of "a=extmap-allow-mixed", which triggers poor line breaks in the current draft. In cases the answer has been excluded, I think s/the answer/where the attribute/. In cases the answer has been excluded, neither clients SHALL use mixed one bytes and two bytes extensions in the same RTP stream but MAY use one-byte or two-bytes form (see section 4.1.2). I think you want to clarify this as In cases where the attribute has been excluded, both clients SHALL NOT use mixed one bytes and two bytes extensions in the same RTP stream. But they MAY use either the one-byte or two-byte form exclusively. 7. Offer/Answer If an offer or answer contains session-level mappings (and hence no media-level mappings), and different behavior is desired for each stream, then the entire set of extension map declarations MAY be moved into the media-level section(s) of the SDP. (Note that this specification does not permit mixing global and local declarations, to make identifier management easier.) Above I propose hoisting this to an earlier position in the document. If an extension map is offered as "sendrecv", explicitly or implicitly, and asymmetric behavior is desired, the SDP MAY be modified to modify or add direction qualifiers for that extension. What does this mean? Do you mean if *the answerer* desires asymmetric behavior? I think you want to replace this paragraph and the following two paragraphs with something like If the answerer desires to not use an extension in a direction which the extmap attribute in the offer allows, it can change the direction attribute in the extmap attribute to a more restrictive value. I.e., "sendrecv" can be replaced with another value, and "sendonly" and "recvonly" can be replaced with "inactive". If the answerer does not understand the extension or does not desire to use it, it should remove the extmap attribute in the answer (in preference to changing its direction to "inactive"). -- If a party wishes to offer mutually exclusive alternatives, then multiple extensions with the same identifier in the (unusable) range 4096-4351 MAY be offered; the answerer SHOULD select at most one of the offered extensions with the same identifier, and remap it to a free identifier in the valid range, for that extension to be usable. I've discussed this above, but additionally, "(unusable) range" is peculiar. There needs to be a term for the range 4096 to 4351. I think I've used the term "extended range" above. It is always allowed to place the offered identifier value "as is" in the SDP answer (for example, due to lack of a free identifier value in the valid range). Extensions with an identifier outside the valid range MUST NOT, of course, be used. If needed, the offerer or answerer can update the session to make space for such an extension. I think this would be clearer as An answerer may copy an extmap for an identifier in the extended range into the answer to indicate to the offerer that it supports that extension. Of course, such an extension cannot be used, since there is no way to specify them in an extension header. If needed, the offerer or answerer can update the session to assign a valid identifier to that extension URI. 11. Changes from RFC5285 The support for this case is negotiated using a new SDP attribute "extmap-allowed-mixed" specified in this document. s/extmap-allowed-mixed/extmap-allow-mixed/ [END] From nobody Wed Feb 1 19:09:12 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D3E126579 for ; Wed, 1 Feb 2017 19:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQSrjWBTWo5c for ; Wed, 1 Feb 2017 19:09:10 -0800 (PST) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 4F2E0129620 for ; Wed, 1 Feb 2017 19:09:10 -0800 (PST) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-08v.sys.comcast.net with SMTP id Z7llc8HuZjvz4Z7llcD6YR; Thu, 02 Feb 2017 03:09:09 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-20v.sys.comcast.net with SMTP id Z7ljcCaS5qiCcZ7lkcOd6y; Thu, 02 Feb 2017 03:09:09 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v12397qH015122; Wed, 1 Feb 2017 22:09:07 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v12396qE015119; Wed, 1 Feb 2017 22:09:06 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: avt@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 01 Feb 2017 22:09:06 -0500 Message-ID: <87zii55lwt.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfJhGb6SeveKPAMOuwamSV4Vv69Dc4bhur/3lCRAUJMBoXSOxMEFwLdsgls8KLN/qdkLHEMYtdX8k5r96w7uH/OX6Ij55Sf7rz3/oiOltyJ11XiDNFc6q 7210O3nQOmXkjAWcz9hNu8cYmP2xoDSUDRS0t2fqcf+bfCOKkF+I56ZV2PsTkrSKOHnCRc8ayMOYqjOi8vC/ivM3W8cCJ8lQdmI= Archived-At: Cc: singer@apple.com Subject: [AVTCORE] draft-ietf-avtcore-rfc5285-bis-05 -- fun special case X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 03:09:11 -0000 Suppose that in the offer and the answer all of the identifiers are less than 15. And suppose that mixing one-byte and two-byte formats is *not* negotiated. RTP packets are sent containing one-byte extension headers, and everything is going along well, and suddenly, the current data part for an extension is over 16 bytes. That data can't be encoded in the one-byte format. I think there needs to be a rule that a UA can't commit to the one-byte format unless all of the extensions that might be sent are defined to have data lengths between 1 and 16 bytes. So instead of the current rule A client MUST NOT send an extension header with the one-byte format if any negotiated valid identifier exceeds 14 and extmap-allow-mixed is not negotiated. we need A client MUST NOT send an extension header with the one-byte format if: (1) extmap-allow-mixed is not negotiated, and (2) (a) some negotiated valid identifier is more than 14, or (b)some negotiated extension may have a data length of 0 bytes or more than 16 bytes. Dale From nobody Wed Feb 1 22:21:00 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58271293E9 for ; Wed, 1 Feb 2017 22:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHyQlC5btGpM for ; Wed, 1 Feb 2017 22:20:55 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60AF4128B44 for ; Wed, 1 Feb 2017 22:20:54 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFQ57584; Thu, 02 Feb 2017 06:20:51 +0000 (GMT) Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 2 Feb 2017 06:20:43 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0301.000; Thu, 2 Feb 2017 14:18:37 +0800 From: Roni Even To: "Dale R. Worley" Thread-Topic: [AVTCORE] Need feedback on RFC5285bis (RTP header extensions) comments Thread-Index: AQHSfRwvRdEGhFAiR0abdcnNJyNsCg== Date: Thu, 2 Feb 2017 06:18:36 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD7705F5@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD770167@DGGEMM506-MBX.china.huawei.com> (roni.even@huawei.com) <8760kt71kq.fsf@hobgoblin.ariadne.com> In-Reply-To: <8760kt71kq.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.150] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5892CFC4.0095, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 554869703f155d9f7c5b552de619d40c Archived-At: Cc: "avt@ietf.org" , "singer@apple.com" Subject: Re: [AVTCORE] Need feedback on RFC5285bis (RTP header extensions) comments X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 06:20:58 -0000 Hi Dale, I will look at all your comments but just to clarify rfc5285bis history. This bis draft was created to add the support for mixing one byte and two b= ytes in an RTP session. It is good to clarify the text but we cannot change= any RC5285 or RFC3550 policies in order to keep interoperability. RFC5285 is an update to RFC3550 which allowed for RTP header extensions wit= hout any negotiation so for backward interoperability it is noted that RTP = header extensions can appear in the RTP stream without being negotiated fir= st, note that RTP header extensions can be ignored and the RTP will still b= e OK.=20 This was not a late review by Paul but it was part of the SDP directorate r= eview that is needed for all documents with SDP.=20 Roni=20 > -----Original Message----- > From: Dale R. Worley [mailto:worley@ariadne.com] > Sent: =E9=E5=ED=A0=E4 02 =F4=E1=F8=E5=E0=F8 2017 04:45 > To: Roni Even > Cc: avt@ietf.org; singer@apple.com > Subject: Re: [AVTCORE] Need feedback on RFC5285bis (RTP header > extensions) comments >=20 > Roni Even writes: > > Paul made a very thorough SDP review and had some comments on which I > > am looking for feedback. >=20 > I didn't realize that this draft was so interesting. Given that it's sti= ll under > review, even though it's a month after the official end of the last call,= I'll post > my full comments later. In the mean time: >=20 > > 1. In section 7 "If an extension is marked as "sendonly" and the > > answerer desires to receive it, the extension MUST be marked as > > "recvonly" in the SDP answer. An answerer that has no desire to > > receive the extension or does not understand the extension SHOULD > > remove it from the SDP answer." . Is there a reason for the "SHOULD" > > here or should we change it to "MUST" or maybe if not removed to > > respond with "inactive" or "sendonly" if want to send and and not > > receive? >=20 > I think the idea is that if the offer contains "sendonly" and the answere= r > wants to receive it, then the answer must contain "recvonly". > But if the answerer doesn't want to receive it, then the answerer must se= t it > to "inactive" or remove the attribute, and the latter is preferred. At l= east, > that makes sense, and it makes the MUSTs and SHOULDs correct, though > that's probably not the clearest way to express the meaning. >=20 > > 2. In this case if the offer is refused by removing the extmap > > line, can the ID be re-used? >=20 > I think the point of this text in section 7 is that if an extension ident= ifier could > get used in RTP packets (i.e., is in the answer), then a session update c= an't > immediately define that identifier to a new URI: >=20 > Identifiers values in the valid range MUST NOT > be altered (remapped). >=20 > That protects packets in flight from misinterpretation. >=20 > But if the extension identifier isn't accepted in the offer, then there's= no > problem with packets in flight, and the next session update can allocate = the > identifier to a different extension. >=20 > However, this text in section 7 seems to say that if an identifier is in = the offer, > even if it isn't in the answer, both endpoints can use it: >=20 > Either party MAY include extensions in the stream other than those > negotiated, or those negotiated as "inactive", for example, for the > benefit of intermediate nodes. Only extensions that appeared with an > identifier in the valid range in SDP originated by the sender can be > sent. >=20 > In that case, packets in flight could be using an identifier that was not > accepted in the answer. >=20 > My opinion is that the latter text is not a good idea. >=20 > > 3. In section 7 "Local identifiers in the valid range inclusive > > in an offer or answer MUST NOT be used more than once per media > > section (including the session-level section). A session update MAY > > change the direction qualifiers of extensions under use. A session > > update MAY add or remove extension(s). Identifiers values in the > > valid range MUST NOT be altered (remapped)." Paul asked what is the > > scope over which identifiers must not be altered. His thought was only > > for the current RTP session so when a call is transferred (one party > > is still in the call) they may be altered. Any thoughts? >=20 > Good point -- this is the same problem as reusing RTP payload types. In > theory you don't want to reuse them at all, or at least, not use them for > different encodings immediately before and after one single session updat= e, > because there may be packets in flight using that payload type. > But various call transfer and 3PCC scenarios make that very difficult to = ensure > in practice. >=20 > > 4. Is it valid to use IDs in the (unusable) range in answers? (I > > guess that would give the offerer info that it could use in a future > > offer.). I am not sure what was meant here. Is it an answer to an > > offer with an ID in the valid range? Or is it about keeping an > > alternative from the offer with the unusable space and not remove it? > > I assume that the answer cannot add extensions to the ones in the > > offer, will need a new offer for that. >=20 > I think it's a mechanism to allow the answerer to say "I support that > extension" even if it can't allocate a valid identifier for it, or if it = doesn't want > to use the extension now. (But see the second quoted passage under item = 2 > and its discussion.) >=20 > Though it's not clear to me how useful that facility is. In general, a U= A should > always offer everything that it is willing to support because any informa= tion it > has cached about the capabilities/desires of the other endpoint could be > invalid now. >=20 > > 5. May values from the (unused) range that are used in offers > > (or answers) be reused differently in subsequent offers? >=20 > I believe the intention is that they may be reused. The text does not fo= rbid > that: >=20 > Identifiers values in the valid range MUST NOT > be altered (remapped). >=20 > And there is no packets-in-flight problem. >=20 > > 6. Would the following be valid? (Only the directionality differs= .) > > > > OFFER: > > > > a=3Dextmap:4096/sendonly http://example.com/082005/ext.htm#opt1 > > > > a=3Dextmap:4096/recvonly http://example.com/082005/ext.htm#opt1 >=20 > That's subtle: the identifier is mapped to the same extension in both > directions, but each direction is mapped by a different extmap attribute. > Yeah, that's forbidden in section 5: >=20 > In addition, as noted above, > the IDs used MUST be unique for each stream type for a given media, > or for the session for session-level declarations. >=20 > > 7. Is it allowed to use the "alternatives" mechanism with only a > > single alternative? This would be a way to avoid "wasting" an ID value > > until you know if your peer supports the option. I see this usage in > > an example, but it is not mentioned in text. If this is an intended > > usage then it would be good to provide some further explanation. >=20 > Well, it isn't an "alternative" construction because there's only one att= ribute > with that identifier. But it's not forbidden to write just one attribute= with an > extended identifier value. However, telling the other UA that you suppor= t > an extension isn't very useful, because the next time the other UA update= s > the session, you may not be the UA on this end of the call. >=20 > Dale From nobody Thu Feb 2 18:49:47 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B641129AC8 for ; Thu, 2 Feb 2017 18:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpUXalbqNvs6 for ; Thu, 2 Feb 2017 18:49:44 -0800 (PST) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (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 62CB4129628 for ; Thu, 2 Feb 2017 18:49:43 -0800 (PST) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-08v.sys.comcast.net with SMTP id ZTvZc7euYGya1ZTwTcfJ7L; Fri, 03 Feb 2017 02:49:41 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-po-14v.sys.comcast.net with SMTP id ZTwRcUzPzqUWeZTwScbOnf; Fri, 03 Feb 2017 02:49:41 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v132ndqK029327; Thu, 2 Feb 2017 21:49:39 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v132ncHc029324; Thu, 2 Feb 2017 21:49:38 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Roni Even In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD7705F5@DGGEMM506-MBX.china.huawei.com> (roni.even@huawei.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 02 Feb 2017 21:49:38 -0500 Message-ID: <87y3xo7zul.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfCxy1rKwTMoG8P9q9gBjsBEG/l1/AJKnEd4E0trI2NRH56Dn/EyfQHbtLg0B/cgjcSMZWaFSfMPXiprF+wGjHMAorSRG7j9FtB7lOujFaQGkR62E6Trn PeRMYOWp1H8YexeVkCD+7avd2gVkkcdtrMSnvQSc/T2gxxkmxWbB8zB8Vc1n3d9v4Eioi0+hBwyYCCFgUcm0COQJwTPZghIwiK0= Archived-At: Cc: avt@ietf.org, singer@apple.com Subject: Re: [AVTCORE] Need feedback on RFC5285bis (RTP header extensions) comments X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 02:49:45 -0000 Roni Even writes: > This bis draft was created to add the support for mixing one byte and > two bytes in an RTP session. It is good to clarify the text but we > cannot change any RC5285 or RFC3550 policies in order to keep > interoperability. Hmmm, yes, I hadn't figured that this was just a small modification of 5285. There seem to be some places where the behavior it specifies/allows is questionable. Fortunately, I suppose, most of my comments were about clarifying exactly what it means or making it easier to see the overal structure. I do think you could safely add that in the one-byte format, bytes 0x01 through 0x0F should be handled like bytes 0xF0 through 0xFF, as that is now unspecified. Dale From nobody Wed Feb 8 22:16:38 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF641294CE for ; Wed, 8 Feb 2017 22:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Af60w2_myB5p for ; Wed, 8 Feb 2017 22:16:35 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E329012940C for ; Wed, 8 Feb 2017 22:16:34 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAG71806; Thu, 09 Feb 2017 06:16:30 +0000 (GMT) Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 9 Feb 2017 06:16:25 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0301.000; Thu, 9 Feb 2017 14:15:47 +0800 From: Roni Even To: "avt@ietf.org" Thread-Topic: NomCom 2016-2017: Call for Nominations to fill the ART AD Vacancy Thread-Index: AQHSgi2b+QPFcZXuVEyb/64SCdkU7qFgM38Q Date: Thu, 9 Feb 2017 06:15:47 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD772F1E@DGGEMM506-MBX.china.huawei.com> References: <148657345278.4391.7886665273772302944.idtracker@ietfa.amsl.com> In-Reply-To: <148657345278.4391.7886665273772302944.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.589C0940.0039, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 316c239aa70ab891332157cdeb913762 Archived-At: Subject: [AVTCORE] FW: NomCom 2016-2017: Call for Nominations to fill the ART AD Vacancy X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 06:16:37 -0000 RllJDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpZXRmIFttYWlsdG86aWV0 Zi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTm9tQ29tIENoYWlyIDIwMTYNClNlbnQ6 INeZ15XXncKg15MgMDgg16TXkdeo15XXkNeoIDIwMTcgMTk6MDQNClRvOiBJRVRGIEFubm91bmNl bWVudCBMaXN0DQpDYzogaWV0ZkBpZXRmLm9yZw0KU3ViamVjdDogTm9tQ29tIDIwMTYtMjAxNzog Q2FsbCBmb3IgTm9taW5hdGlvbnMgdG8gZmlsbCB0aGUgQVJUIEFEIFZhY2FuY3kNCg0KVGhlIDIw MTYtMTcgTm9taW5hdGluZyBDb21taXR0ZWUgKE5vbWNvbSkgaXMgc2Vla2luZyBub21pbmF0aW9u cyBmcm9tIG5vdyB1bnRpbCBGZWJydWFyeSAxNywgMjAxNyBmb3IgdGhlIHBvc2l0aW9uIG9mIEFS VCBBRC4gVGhpcyBhcHBvaW50IHdpbGwgZmlsbCB0aGUgMSB5ZWFyIHZhY2FuY3kgY3JlYXRlZCBi eSBBbGlzc2EgQ29vcGVyJ3MgcmVzaWduYXRpb24gYXMgc2hlIG1vdmVzIHRvIHRoZSBJRVRGIENo YWlyIHNlYXQuDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbm9tY29tLzIwMTYvDQoN Ck5vbWluYXRpb25zIG1heSBiZSBtYWRlIGJ5IHNlbGVjdGluZyB0aGUgTm9taW5hdGUgbGluayBh dCB0aGUgdG9wIG9mIHRoZSBOb21jb20gMjAxNiBob21lIHBhZ2UsIG9yIGJ5IHZpc2l0aW5nIHRo ZSBmb2xsb3dpbmcgVVJMOg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL25vbWNvbS8y MDE2L25vbWluYXRlLw0KDQogIHtOb3RlIHRoYXQgbm9taW5hdGlvbnMgbWFkZSB1c2luZyB0aGUg d2ViIHRvb2wgcmVxdWlyZSBhbiBpZXRmLm9yZw0KICAgZGF0YXRyYWNrZXIgYWNjb3VudC4gWW91 IGNhbiBjcmVhdGUgYSBkYXRhdHJhY2tlciBpZXRmLm9yZyBhY2NvdW50DQogICBpZiB5b3UgZG9u J3QgaGF2ZSBvbmUgYWxyZWFkeSBieSB2aXNpdGluZyB0aGUgZm9sbG93aW5nIFVSTDoNCiAgIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvYWNjb3VudHMvY3JlYXRlLyB9DQoNCklmIHlvdSBh cmUgdW5hYmxlIHRvIHVzZSB0aGUgd2ViIGZvcm0sIG5vbWluYXRpb25zIG1heSBpbnN0ZWFkIGJl IG1hZGUgYnkgZW1haWwgdG8gbm9tY29tLTE2QGlldGYub3JnLiBJZiB1c2luZyBlbWFpbCwgcGxl YXNlIGluY2x1ZGUgdGhlIHdvcmQgIk5vbWluYXRlIiBpbiB0aGUgU3ViamVjdCBhbmQgaW5kaWNh dGUgaW4gdGhlIGVtYWlsIHdobyBpcyBiZWluZyBub21pbmF0ZWQgYW5kIHRoZWlyIGVtYWlsIGFk ZHJlc3MgKHRvIGNvbmZpcm0gYWNjZXB0YW5jZSBvZiB0aGUgbm9taW5hdGlvbikuDQoNCklmIHlv dSBhcmUgbm9taW5hdGluZyBzb21lb25lIG90aGVyIHRoYW4geW91cnNlbGYsIHBsZWFzZSB0ZWxs IHVzIGlmIHdlIG1heSB0ZWxsIHRoZSBub21pbmVlIHRoYXQgeW91IHdlcmUgdGhlIG9uZSB3aG8g bWFkZSB0aGUgbm9taW5hdGlvbi4NCg0KU2VsZi1ub21pbmF0aW9uIGlzIHdlbGNvbWUhDQoNCldp bGxpbmcgbm9taW5lZXMgd2lsbCBiZSBhc2tlZCB0byBmaWxsIG91dCBhIHF1ZXN0aW9ubmFpcmUg Zm9yIHRoZSBBUlQgQUQgcG9zaXRpb24uIFRoZSBxdWVzdGlvbm5haXJlcyB3aWxsIGJlIGF2YWls YWJsZSBGZWJydWFyeSA4LCAyMDE3IGFuZCBoYXZlIGEgc3VibWlzc2lvbiBkZWFkbGluZSBvZiBG ZWJydWFyeSAxNywgMjAxNy4NCg0KTm9tQ29tIDIwMTYtMTcgd2lsbCBmb2xsb3cgdGhlIHBvbGlj eSBmb3IgIk9wZW4gRGlzY2xvc3VyZSBvZiBXaWxsaW5nIE5vbWluZWVzIiBkZXNjcmliZWQgaW4g QkNQIDEwL1JGQyA3NDM3LiAgQXMgc3RhdGVkIGluIFJGQyA3NDM3OiAiVGhlIGxpc3Qgb2Ygbm9t aW5lZXMgd2lsbGluZyB0byBiZSBjb25zaWRlcmVkIGZvciBwb3NpdGlvbnMgdW5kZXIgcmV2aWV3 IGluIHRoZSBjdXJyZW50IE5vbWNvbSBjeWNsZSBpcyBub3QgY29uZmlkZW50aWFsIi4gV2lsbGlu ZyBub21pbmVlcyBmb3IgdGhlIEFSVCBBRCBwb3NpdGlvbiB3aWxsIGJlIGxpc3RlZCBpbiBhIHB1 YmxpY2x5IGFjY2Vzc2libGUgd2F5IC0gYW55b25lIHdpdGggYSBkYXRhdHJhY2tlciBhY2NvdW50 IG1heSBhY2Nlc3MgdGhlIGxpc3RzLiAgQWRkaXRpb25hbGx5LCB0aGUgbm9taW5hdGlvbiBmb3Jt IGFza3MgaWYgd2UgbWF5IHNoYXJlIHlvdXIgb3duIG5hbWUgd2l0aCB0aGUgbm9taW5lZS4gSW4g YWxsIG90aGVyIHdheXMsIHRoZSBjb25maWRlbnRpYWxpdHkgcmVxdWlyZW1lbnRzIG9mIEJDUDEw IHJlbWFpbiBpbiBlZmZlY3QuICBBbGwgZmVlZGJhY2sgYW5kIGFsbCBOb21jb20gZGVsaWJlcmF0 aW9ucyB3aWxsIHJlbWFpbiBjb25maWRlbnRpYWwgYW5kIHdpbGwgbm90IGJlIGRpc2Nsb3NlZC4N Cg0KVGhlcmUgaXMgYSBmaWVsZCBvbiB0aGUgZm9ybSB5b3UgY2FuIG1hcmsgaW4gb3JkZXIgdG8g YWxsb3cgdGhlIE5vbWNvbSB0byB0ZWxsIHRoZSBub21pbmVlIHRoYXQgeW91IHdlcmUgdGhlIG9u ZSB3aG8gbWFkZSB0aGUgbm9taW5hdGlvbi4gVGhpcyBkZWZhdWx0cyB0byDigJxub+KAnSAtIHNv IGlmIHlvdSBkb24ndCBtYXJrIHRoZSBmaWVsZCB3ZSB3b27igJl0IHRlbGwuDQoNCkluIG9yZGVy IHRvIGVuc3VyZSB0aW1lIHRvIGNvbGxlY3Qgc3VmZmljaWVudCBjb21tdW5pdHkgZmVlZGJhY2sg YWJvdXQgZWFjaCBvZiB0aGUgd2lsbGluZyBub21pbmVlcywgbm9taW5hdGlvbnMgbXVzdCBiZSBy ZWNlaXZlZCBieSB0aGUgTm9tQ29tIG9uIG9yIGJlZm9yZSBGZWJydWFyeSAxNywgMjAxNy4NCg0K UGxlYXNlIHN1Ym1pdCB5b3VyIG5vbWluYXRpb25zIGFzIGVhcmx5IGFzIHBvc3NpYmxlIGZvciB0 aGUgc2FrZSBvZiB5b3VyIG5vbWluZWVzLiBOb3RlIHRoYXQgbm9taW5hdGlvbnMgc2hvdWxkIG5v dCB3YWl0IGZvciBtYW5hZ2VtZW50IHBlcm1pc3Npb24sIGFzIGl0IGlzIGVhc2llciB0byBkZWNs aW5lIHRoZSBub21pbmF0aW9uIHRoYW4gcHV0IG9uZSBpbiBsYXRlLg0KDQo= From nobody Mon Feb 13 05:38:02 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6D212949B for ; Mon, 13 Feb 2017 05:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOKEWkrzPxo2 for ; Mon, 13 Feb 2017 05:37:58 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8E7A129494 for ; Mon, 13 Feb 2017 05:37:56 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGK07372; Mon, 13 Feb 2017 13:37:53 +0000 (GMT) Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 13 Feb 2017 13:37:52 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0301.000; Mon, 13 Feb 2017 21:37:47 +0800 From: Roni Even To: "Dale R. Worley" , "avt@ietf.org" Thread-Topic: Coments on draft-ietf-avtcore-rfc5285-bis-05 Thread-Index: AQHSfP6dIfSPcQFwOU6TOV+/cLavZKFmxlRA Date: Mon, 13 Feb 2017 13:37:46 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD7737BA@DGGEMM506-MBX.china.huawei.com> References: <874m0d71ii.fsf@hobgoblin.ariadne.com> In-Reply-To: <874m0d71ii.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.150] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.58A1B6B2.0080, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2dd1ce6a0250a101eb3717c1f374c6cf Archived-At: Cc: "singer@apple.com" Subject: Re: [AVTCORE] Coments on draft-ietf-avtcore-rfc5285-bis-05 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 13:38:01 -0000 Dale, Thanks for the detailed review.=20 Inline Roni > -----Original Message----- > From: Dale R. Worley [mailto:worley@ariadne.com] > Sent: =E9=E5=ED=A0=E4 02 =F4=E1=F8=E5=E0=F8 2017 04:47 > To: avt@ietf.org > Cc: Roni Even; singer@apple.com > Subject: Coments on draft-ietf-avtcore-rfc5285-bis-05 >=20 > This is rather late, but it seems that the document is still under active > development. >=20 > * Technical items: >=20 > 4.2. One-Byte Header >=20 > The ID value 15 is reserved. But there is also the invalid case where th= e ID > field is 0 and the len field is non-zero. That case should probably be i= ncluded > in the same exception processing as for ID value 15. [Roni Even]It says that ID=3D0 MUST not be used value =3D0 is padding (both= ID and len field) so you are asking for text about what to do if there is = header with 0 in the ID part but some value in the len part. I assume that= good policy will be the same as for ID 15 but any error behavior can be ex= pected (ignore all header extension ,treat like padding ...) since this cas= e is not discussed in RFC5285. >=20 > 5. SDP Signaling Design >=20 > A usable mapping MUST use IDs in the valid range, and each ID in this > range MUST be used only once for each media (or only once if the > mappings are session level). >=20 > It would be useful to state early in this section that in order to reduce= the > complexity of negotiating identifiers, a valid SDP must not have mapping > attributes (extmap) at both the session level and the media level. Also,= that > it is semantically equivalent to have a set of extmaps at the session lev= el and > to have the same set of extmaps duplicated in each media section. In > particular, if an offer contains extmaps at the session level and the ans= werer > wishes to modify the extension mapping for one media stream but not the > others, it can move the extmaps from the session level of the offer to ev= ery > media section in the answer, and then modify the extmaps in the desired > media section. [Roni Even] this appears later in the section >=20 > There is some vagueness about the use of extmaps using identifiers outsid= e > the valid range, and the use of duplicate IDs. At one point, it seems to= be > stated that for a session description to be acted upon, only valid identi= fiers > can be specified, and each can be specified only once -- but that in an > offer/answer situation, the offer can use duplicate identifiers, and can = use > identifiers in the extended range, and the answer then produces SDP that > obeys the validity rules. Then elsewhere, it is said that the answer can= have > extmaps in the extended range. I think there needs to be a clear summary > of the various combinations that can happen during offer/answer of > duplicated identifiers and identifiers in the extended range, because thi= s sort > of behavior pattern is unusual in SDP. [Roni Even] I think that section 7 (offer answer) clarifies that ids from t= he unusable space are used for mutually exclusive offers. It is an offer an= swer since it does not make sense to use unusable IDs for descriptive SDP. = as for comparing to sdp offer answer I am not sure that it is a good idea = because SDP and offer answer is not very good in offering alternatives. >=20 > Also, if an answer uses a different ID for a URI than the offer, do both = the > offerer and answerer use the answer's IDs? The text suggests so, but tha= t is > different from how payload types are used. In any case, the rules need t= o be > made very clear. [Roni Even] according to rfc3264 for sendonly and sendrecv the answerer pay= load type number is used. >=20 > There's also a question of what URIs may be used and how they are > considered. The term "absolute URI" seems to be poorly defined, since RF= C > 3986 uses "absolute URI" to mean what matches the production "absolute- > URI", but that means a URI without a fragment part. I think here we mean= "a > URI containing a 'path-absolute'", but I don't think that admits URNs. (= And all > existing registered extension names are > URNs.) So this definition needs to be cleaned up. [Roni Even] For extensions defined in RFC URN must be used. As for the case= for other URIs, it is there from RFC5285 and I do not think it is good to = change the text since we do not know if there are usages. >=20 > I think in reality, these URIs are used as nearly-opaque identifiers; the > exception being that a device that accepts the extension labeled with a U= RI > will necessarily know what the rules are for testing for equality with th= at URI. >=20 > But is there any reason to allow URIs that aren't URNs? (Within URNs, is= sues > of equality testing, etc., are generally well-specified.) The text seems= to > suggest that the URI can be used to look up the meaning of the extension = in > some way other than using the URI to index a database, but I don't see ho= w > that can be made to work in practice. > And once the URIs are indexes, it seems best to limit them to being URNs. > Then again, XML namespaces are named by URIs, not just URNs. >=20 > The meaning of the sendonly, etc. attributes seems to be inadequately > specified. Given that an extmap attribute can exist at the session level= even > when media streams have different direction attributes, it seems that the > only simple rule is that the direction attribute in the extmap determines > which direction(s) the extension may be sent in theoretically, but becaus= e of > media directionality, the header will only be sent in a direction that is= within > the directionality of the extmap and also the directionality of the strea= m. [Roni Even] OK, this is understood from the text since you do not send head= er extensions but adds them to an RTP packet. So I not sure that anyone wil= l think to send RTP header extension to a unidirectional send stream. Yet i= t may be an interesting case when you support sending the same SDES item in= both RTCP, which is in RFC7941. I assume that in that case only RTCP will= be used.=20 > Similarly to media directionality, the directionality given in an answer = for a > particular extmap URI must be a subset of the directionality given in the > offer. >=20 > URIs > that contain a domain name SHOULD also contain a month-date in the > form mmyyyy. >=20 > There isn't any standardized way to do this. Should there be some indica= tor > that the month indication is ad hoc, such as: >=20 > URIs that contain a domain name SHOULD in some manner contain a > month-date in the form mmyyyy. [Roni Even] I think that this is too late, for RFC URNs are used for any ot= her usages we do not have information to mandate anything >=20 > -- >=20 > If the resource or document defines several extensions, > then the URI MUST identify the actual extension in use, e.g., using a > fragment or query identifier (characters after a '#' or '?' in the > URI). >=20 > This text suggests that the URI in some way can be processed to directly > identify a "resource or document". But there is no general resolution > process for doing that; the method by which the URI indicates the extensi= on > definition is entirely outside this specification. In practice, the devi= ce > contains a small table of URIs that it recognizes. >=20 > Within that conceptual structure, the rule is simply that different exten= sions > must be identified by different URIs, and as a consequence, URIs that dif= fer > only by fragment or query identifier identify different extensions. >=20 > When SDP signaling is used for the RTP session, it is the presence of > the 'extmap' attribute(s) that is diagnostic that this style of > header extensions is used, not the magic number indicated above. >=20 > I *think* this means that the presence of this SDP signaling implies that= all > RTP header extensions will be of the type defined here, regardless of the= ir > 16-bit identifiers. But that's not a useful fact, because the header ext= ension > can't be parsed without first knowing which variety of extension is it, a= nd > that is determined by the 16-bit identifier value. So I think the best y= ou can > do is say >=20 > When SDP signaling is used for the RTP session, if > 'extmap' attribute(s) are present, all RTP extension headers MUST > be of one of the two forms specified in this document. >=20 > 6. SDP Signaling for support of mixed one byte and two bytes header >=20 > For simplicity, it seems that you'd want to allow the positioning of extm= ap- > allow-mixed (session level vs. media level) to be independent of the > positioning of extmap. I expect this is intended, but it's worth stating= it > explicitly, given the limitations on how extmap attributes can be placed. >=20 > Given that it is envisioned that some systems may not support the two-byt= e > form (section 4.1.2 paragraph 2),=20 [Roni Even] where does it say it? should there be a way to enforce the use of > only the one-byte form? In particular, this might be desirable: >=20 > If all of the identifier values in the offer are less than 15, > then all of the identifier values in the answer MUST be either > less than 15 or greater than 4095. If all of the identifier > values in the answer are less than 15, then the RTP stream MUST > NOT user the two-byte extension form. >=20 > That allows both the offerer and the answerer to force use of the one-byt= e > form. [Roni Even] why do we need to force one-byte extension only.=20 >=20 > 7. Offer/Answer >=20 > Extensions, with their directions, MAY be signaled for an "inactive" > stream. It is an error to use an extension direction incompatible > with the stream direction (e.g., a "sendonly" attribute for a > "recvonly" stream). >=20 > This is unworkable if the extension attribute is at the session level. > E.g., there could be one media stream that is "sendonly" and one that is > "recvonly", which would require all extension attribute directions to be > "inactive". I think you need to allow the extension attribute direction > specifications to be orthogonal to the medial directions. [Roni Even] This will be a change from RC5285, I assume that in your exampl= e you must use media level extmap, I think that this is what the text say. >=20 > Local identifiers in the valid range inclusive in an offer or answer > MUST NOT be used more than once per media section (including the > session-level section). A session update MAY change the direction > qualifiers of extensions under use. A session update MAY add or > remove extension(s). Identifiers values in the valid range MUST NOT > be altered (remapped). >=20 > There is a lot here. The duplicate identifiers are clearly allowed=20 [Roni Even] only in the unusable range. This is not contradictory to the ab= ove sentence that talks about valid range -- that is > discussed elsewhere in these comments. A session update may change the > direction qualifiers, of course, because a session update is an entirely = new > negotiation, so that need not be stated. Similarly for adding or removin= g > extensions. >=20 > But what does the last sentence mean? There is much discussion of > remapping identifier values in earlier sections. Does it perhaps mean th= at if > an identifier value goes into use (by being in the valid range and in the > answer), then a session update offer MAY NOT map it to a different URI? > This may be a good rule, because it ensures that RTP extension headers in= - > flight won't be misinterpreted. But it might be better phrased: >=20 > A session update offer or answer may not specify a different URI > for an identifier that is in currently in use in the session (i.e., > that is in the valid range and was specified in the answer that > describes the session). (However, an identifier that is currently > in use can be unmapped in one session update offer/answer cycle and > then subsequently mapped to a different URI in a later session > update.) [Roni Even] it is probably not may not but must not and this is what the te= xt say about remapping >=20 > -- >=20 > Either party MAY include extensions in the stream other than those > negotiated, or those negotiated as "inactive", for example, for the > benefit of intermediate nodes. Only extensions that appeared with an > identifier in the valid range in SDP originated by the sender can be > sent. >=20 > This seems odd. If the negotiated SDP (the answer) doesn't contain an > extmap or marks it inactive, why should both endpoints be allowed to send > it? And isn't it the identifier number in the answer that control (becau= se the > answer is allowed to remap the extension types in the offer)? I think th= is > needs to be rethought. >=20 > 8. BNF Syntax >=20 > (only absolute URIs are permitted here) >=20 > If we maintain this restriction, a clear definition or reference for "abs= olute > URI" needs to be made. >=20 > The BNF allows five-digit identifiers, whereas the text allows identifier= s only > up to 4351. I see that the intention is that the range may be increased = later, > but I would think four digit numbers would suffice. >=20 > 9. Security Considerations >=20 > Extensions usage is negotiated using [RFC3264] so integrity > protection and end-to-end authentication MUST be used. >=20 > This seems remarkably strict, since roughly nobody uses end-to-end > integrity/authentication in SIP. >=20 > * Editorial items: [Roni Even] I will try to address them in the new revision >=20 > Abstract >=20 > The document obsoletes RFC5285 >=20 > s/The/This/ >=20 > Add a final full stop. >=20 > 1. Introduction >=20 > both one byte and two bytes header >=20 > I think the standard usage is "two byte" when that phrase is being used a= s a > modifier. >=20 > 4.1. General >=20 > The value defined for an RTP extension > (defined below for the one-byte and two-byte header forms) is ... >=20 > This is awkwardly phrased; what is "the value defined for an extension". > Unfortunately, RFC 3550 didn't give a proper name to the field in questio= n. I > suggest copying the wording in the introduction, which was clearer: >=20 > The 16-bit identifiers for the two forms of RTP extension defined > here are only architectural constants (e.g., for use by network > analyzers); it is the out-of-band negotiation/definition (e.g., in > SDP) that is the definitive indication that this header extension > is present. >=20 > 4.1.1. transmission considertions >=20 > s/considertions/considerations/ >=20 > actually, >=20 > s/transmission considertions/Transmission Considerations/ >=20 > 4.1.2. Header Extension type consideration >=20 > s/type consideration/Type Consideration/ >=20 > Perhaps change "one-byte form" and "two-byte form" to "one-byte format" > and "two-byte format"? The latter read better to me. >=20 > Each RTP packet with an RTP header extension following > this specification will indicate if it contains one or two byte > header extensions through the use of the "defined by profile" field. >=20 > Better, "...though the value of the...". >=20 > Transmitters SHOULD NOT use the two-byte form when all extensions are > small enough for the one-byte header form. >=20 > You should probably add, "... when all extension use IDs less than 15 and= the > extension data is small enough ...". That makes it correct, and makes it > clearer why negotiating an ID over 14 signals an intention to use the two= -byte > form. >=20 > Transmitters that intend > to send the two-byte form SHOULD use IDs above 14 if they want to let > the Receivers know that they intend to use two-byte form ... >=20 > Better to say "... SHOULD negotiate the use of IDs above 14 to let ...". >=20 > 4.3. Two-Byte Header >=20 > For the purposes of signaling, this field is treated > as a special extension value assigned to the local identifier 256. >=20 > This is awkwardly phrased, since this isn't a signaling datum. I assume = you > mean >=20 > This field is treated as the data field of the extension assigned > to the local identifier 256. (Of course, an extension assigned > identifier 256 must define the interpretation of four-bit values.) >=20 > -- >=20 > Note that there is one ID space for both one-byte > and two-byte form this means that the lower values (1-14) can be used > in the 4-bit ID field in the one-byte header format as well. >=20 > The clauses don't join together correctly. Perhaps: >=20 > Note that there is one ID space for both one-byte > and two-byte forms. This means that the lower values (1-14) can be us= ed > in the 4-bit ID field in the one-byte format with the same meanings. >=20 > 5. SDP Signaling Design >=20 > An extension URI with the same attributes MUST NOT appear more than >=20 > It would be clearer if you phrased this: >=20 > There must not be multiple identifier definitions applying to > one stream with the same extension URI and extension-attributes. >=20 > (Then s/// in the BNF.) >=20 > ... can appear > differently parameterized for the same stream. >=20 > s/differently parameterized/with different extension-attributes/ >=20 > In addition, as noted above, > the IDs used MUST be unique for each stream type for a given media, > or for the session for session-level declarations. >=20 > It is not clear what this means. As noted above, the same extended ID ca= n > be used multiple times in an offer. And what a "stream type" is is not > defined. >=20 > Each local identifier potentially used in the stream is mapped to a > string using an attribute of the form: >=20 > What does "is mapped to a string" mean? Does it mean "is mapped to an > extension identified by a URI"? >=20 > is an integer in the valid range inclusive (0 > is reserved for padding in both forms, and 15 is reserved in the one- > byte header form, as noted above) >=20 > The phrase "valid range inclusive" is used in several places and is uncle= ar. I > think "valid range" is what is intended. >=20 > There's no particular reason to partially describe the valid range here, = as it > has already been explained. And the text about 15 is irrelevant, as ID 1= 5 can > validly be used in two-byte headers. >=20 > is one of > "sendonly", "recvonly", "sendrecv", or "inactive" (without the > quotes) with relation to the device being configured. >=20 > Within the context of the above proposal that the extmap direction value = is > orthogonal to stream direction attribute, it should be noted here that > "sendrecv" is the default value. >=20 > 6. SDP Signaling for support of mixed one byte and two bytes header >=20 > The formal definition of this attribute is: >=20 > Name: extmap-allow-mixed >=20 > I would expect this formal definition to be in the IANA considerations > section. Indeed, it *is* in the IANA considerations. Why is it duplicat= ed > here? >=20 > When doing SDP Offer/Answer [RFC3264] an offering client that wishes > to use both one and two bytes extensions MUST include the attribute > "a=3D extmap-allow-mixed " in the SDP offer. If "a=3D extmap-allow-mi= xed > " is present in the offer SDP, the answerer that supports this mode > and wishes to use it SHALL include the "a=3Dextmap-allow-mixed " > attribute in the answer. >=20 > There are extra spaces in the various occurrences of "a=3Dextmap-allow- > mixed", which triggers poor line breaks in the current draft. >=20 > In cases the answer has been excluded, >=20 > I think s/the answer/where the attribute/. >=20 > In cases the answer has been excluded, > neither clients SHALL use mixed one bytes and two bytes extensions in > the same RTP stream but MAY use one-byte or two-bytes form (see > section 4.1.2). >=20 > I think you want to clarify this as >=20 > In cases where the attribute has been excluded, > both clients SHALL NOT use mixed one bytes and two bytes extensions in > the same RTP stream. But they MAY use either the one-byte or two-byte > form exclusively. >=20 > 7. Offer/Answer >=20 > If an offer or answer contains session-level mappings (and hence no > media-level mappings), and different behavior is desired for each > stream, then the entire set of extension map declarations MAY be > moved into the media-level section(s) of the SDP. (Note that this > specification does not permit mixing global and local declarations, > to make identifier management easier.) >=20 > Above I propose hoisting this to an earlier position in the document. >=20 > If an extension map is offered as "sendrecv", explicitly or > implicitly, and asymmetric behavior is desired, the SDP MAY be > modified to modify or add direction qualifiers for that extension. >=20 > What does this mean? Do you mean if *the answerer* desires asymmetric > behavior? I think you want to replace this paragraph and the following t= wo > paragraphs with something like >=20 > If the answerer desires to not use an extension in a direction > which the extmap attribute in the offer allows, it can change the > direction attribute in the extmap attribute to a more restrictive > value. I.e., "sendrecv" can be replaced with another value, and > "sendonly" and "recvonly" can be replaced with "inactive". If the > answerer does not understand the extension or does not desire to > use it, it should remove the extmap attribute in the answer (in > preference to changing its direction to "inactive"). >=20 > -- >=20 > If a party wishes to offer mutually exclusive alternatives, then > multiple extensions with the same identifier in the (unusable) range > 4096-4351 MAY be offered; the answerer SHOULD select at most one of > the offered extensions with the same identifier, and remap it to a > free identifier in the valid range, for that extension to be usable. >=20 > I've discussed this above, but additionally, "(unusable) range" is peculi= ar. > There needs to be a term for the range 4096 to 4351. I think I've used t= he > term "extended range" above. >=20 > It is always allowed to place the offered identifier value "as is" in > the SDP answer (for example, due to lack of a free identifier value > in the valid range). Extensions with an identifier outside the valid > range MUST NOT, of course, be used. If needed, the offerer or > answerer can update the session to make space for such an extension. >=20 > I think this would be clearer as >=20 > An answerer may copy an extmap for an identifier in the extended > range into the answer to indicate to the offerer that it supports > that extension. Of course, such an extension cannot be used, since > there is no way to specify them in an extension header. If needed, > the offerer or answerer can update the session to assign a valid > identifier to that extension URI. >=20 > 11. Changes from RFC5285 >=20 > The support for this case is negotiated > using a new SDP attribute "extmap-allowed-mixed" specified in this > document. >=20 > s/extmap-allowed-mixed/extmap-allow-mixed/ >=20 > [END] From nobody Mon Feb 13 09:50:51 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373CE129706 for ; Mon, 13 Feb 2017 09:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.195 X-Spam-Level: * X-Spam-Status: No, score=1.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.795, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbApCC1ILAQC for ; Mon, 13 Feb 2017 09:50:49 -0800 (PST) Received: from mx0b-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (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 04C0A1296FC for ; Mon, 13 Feb 2017 09:50:49 -0800 (PST) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v1DHmePb024412; Mon, 13 Feb 2017 12:50:37 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 28hvkq98u6-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Mon, 13 Feb 2017 12:50:37 -0500 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, 13 Feb 2017 11:50:36 -0600 From: Jonathan Lennox To: Roni Even Thread-Topic: [AVTCORE] Coments on draft-ietf-avtcore-rfc5285-bis-05 Thread-Index: AQHSfP6dIfSPcQFwOU6TOV+/cLavZKFmxlRAgADnnoA= Date: Mon, 13 Feb 2017 17:50:35 +0000 Message-ID: References: <874m0d71ii.fsf@hobgoblin.ariadne.com> <6E58094ECC8D8344914996DAD28F1CCD7737BA@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD7737BA@DGGEMM506-MBX.china.huawei.com> 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="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-13_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702130172 Archived-At: Cc: IETF AVTCore WG , "singer@apple.com" Subject: Re: [AVTCORE] Coments on draft-ietf-avtcore-rfc5285-bis-05 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 17:50:50 -0000 DQo+PiBJIHRoaW5rIGluIHJlYWxpdHksIHRoZXNlIFVSSXMgYXJlIHVzZWQgYXMgbmVhcmx5LW9w YXF1ZSBpZGVudGlmaWVyczsgdGhlDQo+PiBleGNlcHRpb24gYmVpbmcgdGhhdCBhIGRldmljZSB0 aGF0IGFjY2VwdHMgdGhlIGV4dGVuc2lvbiBsYWJlbGVkIHdpdGggYSBVUkkNCj4+IHdpbGwgbmVj ZXNzYXJpbHkga25vdyB3aGF0IHRoZSBydWxlcyBhcmUgZm9yIHRlc3RpbmcgZm9yIGVxdWFsaXR5 IHdpdGggdGhhdCBVUkkuDQo+PiANCj4+IEJ1dCBpcyB0aGVyZSBhbnkgcmVhc29uIHRvIGFsbG93 IFVSSXMgdGhhdCBhcmVuJ3QgVVJOcz8gIChXaXRoaW4gVVJOcywgaXNzdWVzDQo+PiBvZiBlcXVh bGl0eSB0ZXN0aW5nLCBldGMuLCBhcmUgZ2VuZXJhbGx5IHdlbGwtc3BlY2lmaWVkLikgIFRoZSB0 ZXh0IHNlZW1zIHRvDQo+PiBzdWdnZXN0IHRoYXQgdGhlIFVSSSBjYW4gYmUgdXNlZCB0byBsb29r IHVwIHRoZSBtZWFuaW5nIG9mIHRoZSBleHRlbnNpb24gaW4NCj4+IHNvbWUgd2F5IG90aGVyIHRo YW4gdXNpbmcgdGhlIFVSSSB0byBpbmRleCBhIGRhdGFiYXNlLCBidXQgSSBkb24ndCBzZWUgaG93 DQo+PiB0aGF0IGNhbiBiZSBtYWRlIHRvIHdvcmsgaW4gcHJhY3RpY2UuDQo+PiBBbmQgb25jZSB0 aGUgVVJJcyBhcmUgaW5kZXhlcywgaXQgc2VlbXMgYmVzdCB0byBsaW1pdCB0aGVtIHRvIGJlaW5n IFVSTnMuDQo+PiBUaGVuIGFnYWluLCBYTUwgbmFtZXNwYWNlcyBhcmUgbmFtZWQgYnkgVVJJcywg bm90IGp1c3QgVVJOcy4NCj4+IA0KPj4gVGhlIG1lYW5pbmcgb2YgdGhlIHNlbmRvbmx5LCBldGMu IGF0dHJpYnV0ZXMgc2VlbXMgdG8gYmUgaW5hZGVxdWF0ZWx5DQo+PiBzcGVjaWZpZWQuICBHaXZl biB0aGF0IGFuIGV4dG1hcCBhdHRyaWJ1dGUgY2FuIGV4aXN0IGF0IHRoZSBzZXNzaW9uIGxldmVs IGV2ZW4NCj4+IHdoZW4gbWVkaWEgc3RyZWFtcyBoYXZlIGRpZmZlcmVudCBkaXJlY3Rpb24gYXR0 cmlidXRlcywgaXQgc2VlbXMgdGhhdCB0aGUNCj4+IG9ubHkgc2ltcGxlIHJ1bGUgaXMgdGhhdCB0 aGUgZGlyZWN0aW9uIGF0dHJpYnV0ZSBpbiB0aGUgZXh0bWFwIGRldGVybWluZXMNCj4+IHdoaWNo IGRpcmVjdGlvbihzKSB0aGUgZXh0ZW5zaW9uIG1heSBiZSBzZW50IGluIHRoZW9yZXRpY2FsbHks IGJ1dCBiZWNhdXNlIG9mDQo+PiBtZWRpYSBkaXJlY3Rpb25hbGl0eSwgdGhlIGhlYWRlciB3aWxs IG9ubHkgYmUgc2VudCBpbiBhIGRpcmVjdGlvbiB0aGF0IGlzIHdpdGhpbg0KPj4gdGhlIGRpcmVj dGlvbmFsaXR5IG9mIHRoZSBleHRtYXAgYW5kIGFsc28gdGhlIGRpcmVjdGlvbmFsaXR5IG9mIHRo ZSBzdHJlYW0uDQo+IFtSb25pIEV2ZW5dIE9LLCB0aGlzIGlzIHVuZGVyc3Rvb2QgZnJvbSB0aGUg dGV4dCBzaW5jZSB5b3UgZG8gbm90IHNlbmQgaGVhZGVyIGV4dGVuc2lvbnMgYnV0IGFkZHMgdGhl bSB0byBhbiBSVFAgcGFja2V0LiBTbyBJIG5vdCBzdXJlIHRoYXQgYW55b25lIHdpbGwgdGhpbmsg dG8gc2VuZCBSVFAgaGVhZGVyIGV4dGVuc2lvbiB0byBhIHVuaWRpcmVjdGlvbmFsIHNlbmQgc3Ry ZWFtLiBZZXQgaXQgbWF5IGJlIGFuIGludGVyZXN0aW5nIGNhc2Ugd2hlbiB5b3Ugc3VwcG9ydCBz ZW5kaW5nIHRoZSBzYW1lIFNERVMgaXRlbSBpbiBib3RoIFJUQ1AsIHdoaWNoIGlzICBpbiBSRkM3 OTQxLiBJIGFzc3VtZSB0aGF0IGluIHRoYXQgY2FzZSBvbmx5IFJUQ1Agd2lsbCBiZSB1c2VkLiAN Cg0KVGhlIGNvbnZlbnRpb24gaXMgdG8gdXNlIFVSTHMgZm9yIHByb3ByaWV0YXJ5IC8gbm9uLXN0 YW5kYXJkaXplZCBoZWFkZXIgZXh0ZW5zaW9ucywgYW5kIHRoaXMgaXMgZXhpc3RpbmcgcHJhY3Rp Y2UgaW4gdGhlIHdpbGQuICBGb3IgZXhhbXBsZSwgQ2hyb21l4oCZcyBKU0VQIG5lZ290aWF0ZXMg aHR0cDovL3d3dy53ZWJydGMub3JnL2V4cGVyaW1lbnRzL3J0cC1oZHJleHQvYWJzLXNlbmQtdGlt ZS4NCg0KDQo= From nobody Mon Feb 13 10:35:46 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1861297C1 for ; Mon, 13 Feb 2017 10:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8iPxYvxkceP for ; Mon, 13 Feb 2017 10:35:44 -0800 (PST) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (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 3F69F129603 for ; Mon, 13 Feb 2017 10:35:44 -0800 (PST) Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-07v.sys.comcast.net with SMTP id dLSAcCJ5HO8EmdLTTc4Cep; Mon, 13 Feb 2017 18:35:43 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-po-08v.sys.comcast.net with SMTP id dLTQcK2y7JE5zdLTRceDaC; Mon, 13 Feb 2017 18:35:42 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v1DIZels019153; Mon, 13 Feb 2017 13:35:40 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v1DIZdOZ019150; Mon, 13 Feb 2017 13:35:39 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Roni Even In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD7737BA@DGGEMM506-MBX.china.huawei.com> (roni.even@huawei.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 13 Feb 2017 13:35:39 -0500 Message-ID: <87r332uef8.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfMa+cU3aumsHWwcsK3o0GJETGk7sVk5JTSE8oJ8Bsn3s9nS8UnMt75HxfgBKx1vw7wJckYayXZh91hXW01BRt1SSZj/GTEm1P140GpkOPb1N+CWE8Hdi +C53Ad6FnUYTE45ryaTf8H2ogFxB5iKqeeXCDJ9CQuVS9rlwjnUyH6k+VacvV0WPUgfg1aWtYnVO+N7f+odbMwkkL2g84s9Ew/g= Archived-At: Cc: avt@ietf.org, singer@apple.com Subject: Re: [AVTCORE] Coments on draft-ietf-avtcore-rfc5285-bis-05 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 18:35:45 -0000 Thanks for looking at my comments and doing what you can with them. I suppose overall, I wish that 5285 was a lot clearer, and in particular, that it put in one place all the rules that relate offers and answers. But that would require a complete editorial overhaul. However, there is are a couple of point that could be addressed. In section 4.1.2 paragraph 2, it says Since it is expected that (a) the number of extensions in any given RTP session is small and (b) the extensions themselves are small, the one-byte header form is preferred and MUST be supported by all receivers. This says that all receivers must support the one-byte format. But I can't find a similar statement that all receivers must support the two-byte format, so it seems that support for that format is optional. And if that's true, it means that a device that can receive only the one-byte format needs a way to force the sender to only send the one-byte format. Another point is: > > 4.2. One-Byte Header > > > > The ID value 15 is reserved. But there is also the invalid case > > where the ID field is 0 and the len field is non-zero. That case > > should probably be included in the same exception processing as for > > ID value 15. > > > [Roni Even] It says that ID=0 MUST not be used value =0 is padding > > (both ID and len field) so you are asking for text about what to do > > if there is header with 0 in the ID part but some value in the len > > part. I assume that good policy will be the same as for ID 15 but > > any error behavior can be expected (ignore all header extension > > ,treat like padding ...) since this case is not discussed in > > RFC5285. My thinking is that if the draft is careful to specify the processing of the invalid case of ID=15 in the one-byte format, then it would similarly make sense for the draft to specify the processing of the invalid case ID=0,len>0. Dale From nobody Tue Feb 14 10:09:19 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61481296DE for ; Tue, 14 Feb 2017 10:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WId_uOONynsy for ; Tue, 14 Feb 2017 10:09:16 -0800 (PST) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (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 9280A1295EE for ; Tue, 14 Feb 2017 10:09:16 -0800 (PST) Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-02v.sys.comcast.net with SMTP id dhVmctrO6J5z3dhXOcobCh; Tue, 14 Feb 2017 18:09:14 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-po-08v.sys.comcast.net with SMTP id dhXLcOTAuJE5zdhXMcgZWt; Tue, 14 Feb 2017 18:09:14 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v1EI9A4J005989; Tue, 14 Feb 2017 13:09:10 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v1EI99hG005966; Tue, 14 Feb 2017 13:09:09 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Jonathan Lennox In-Reply-To: (jonathan@vidyo.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 14 Feb 2017 13:09:09 -0500 Message-ID: <87h93wtzju.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfCAXrzR5azGMVFALaJk0dPR5mcQ8hwK2Qk63TYIda/q18on87Kf6VIRjE4aF5DJGZ+TdNc3WfqsRoIaGRnFRJA9yCEr7q8kNFSa0qTxJRCI8/72jb+oi YOWL61BJbZM11KQMa2WgXtN5DjnXqQd3SsfujJCWCWSvo579cN4EV2sic5EHF1vC9HnstTalR5e1xVmt/lQD+adHUjC+hfHscHDSdQn2Fcir6sEPpttfRTCp rup2Gi3j0mxbkrC4UTDL4w== Archived-At: Cc: avt@ietf.org, singer@apple.com Subject: Re: [AVTCORE] Coments on draft-ietf-avtcore-rfc5285-bis-05 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 18:09:18 -0000 Jonathan Lennox writes: > The convention is to use URLs for proprietary / non-standardized > header extensions, and this is existing practice in the wild. For > example, Chrome's JSEP negotiates > http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time. Yeah, I suppose so. People use URLs all the time for XML namespaces. And yet, they could use URNs just as easily (since object-id URNs are free). Dale From nobody Wed Feb 15 02:00:43 2017 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1110012954F; Wed, 15 Feb 2017 02:00:42 -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: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148715284206.17349.15961577379542353753.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 02:00:42 -0800 Archived-At: Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rfc5285-bis-06.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 10:00:42 -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 Core Maintenance of the IETF. Title : A General Mechanism for RTP Header Extensions Authors : Roni Even David Singer Harikishan Desineni Filename : draft-ietf-avtcore-rfc5285-bis-06.txt Pages : 22 Date : 2017-02-14 Abstract: This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session. This document obsoletes RFC5285. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtcore-rfc5285-bis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rfc5285-bis-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 15 02:34:47 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDCCA129A0F for ; Wed, 15 Feb 2017 02:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kepFNzPlnIAY for ; Wed, 15 Feb 2017 02:34:44 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BED821204D9 for ; Wed, 15 Feb 2017 02:34:43 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGN32504; Wed, 15 Feb 2017 10:34:11 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 15 Feb 2017 10:34:11 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0301.000; Wed, 15 Feb 2017 18:34:04 +0800 From: Roni Even To: "Dale R. Worley" Thread-Topic: Coments on draft-ietf-avtcore-rfc5285-bis-05 Thread-Index: AQHShif/MTfJguDwLEeJeDQ5x7YBB6Fp36CA Date: Wed, 15 Feb 2017 10:34:04 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD77415F@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD7737BA@DGGEMM506-MBX.china.huawei.com> (roni.even@huawei.com) <87r332uef8.fsf@hobgoblin.ariadne.com> In-Reply-To: <87r332uef8.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.150] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.58A42EC2.0170, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2dd1ce6a0250a101eb3717c1f374c6cf Archived-At: Cc: "avt@ietf.org" , "singer@apple.com" Subject: Re: [AVTCORE] Coments on draft-ietf-avtcore-rfc5285-bis-05 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 10:34:46 -0000 Dale, If extmap-allow-mixed is declared it means support for both one-byte and tw= o-byte. Without it there is no way to signal support for just one-byte (or= declare support for two-byte) in RFC5285 . It can be assumed based when th= e IDs used in the offer are with IDs 1-14, still it does not say that in = this case only 1-byte are supported. Since this is the text in RFC5285, I a= m not sure if we can change without agreement from the WG. Roni > -----Original Message----- > From: Dale R. Worley [mailto:worley@ariadne.com] > Sent: =E9=E5=ED=A0=E1 13 =F4=E1=F8=E5=E0=F8 2017 20:36 > To: Roni Even > Cc: avt@ietf.org; singer@apple.com > Subject: Re: Coments on draft-ietf-avtcore-rfc5285-bis-05 >=20 > Thanks for looking at my comments and doing what you can with them. I > suppose overall, I wish that 5285 was a lot clearer, and in particular, t= hat it put > in one place all the rules that relate offers and answers. > But that would require a complete editorial overhaul. >=20 > However, there is are a couple of point that could be addressed. In sect= ion > 4.1.2 paragraph 2, it says >=20 > Since it is expected that (a) the number of extensions in > any given RTP session is small and (b) the extensions themselves are > small, the one-byte header form is preferred and MUST be supported by > all receivers. >=20 > This says that all receivers must support the one-byte format. But I can= 't find > a similar statement that all receivers must support the two-byte format, = so it > seems that support for that format is optional. > And if that's true, it means that a device that can receive only the one-= byte > format needs a way to force the sender to only send the one-byte format. >=20 > Another point is: >=20 > > > 4.2. One-Byte Header > > > > > > The ID value 15 is reserved. But there is also the invalid case > > > where the ID field is 0 and the len field is non-zero. That case > > > should probably be included in the same exception processing as for > > > ID value 15. > > > > > [Roni Even] It says that ID=3D0 MUST not be used value =3D0 is paddin= g > > > (both ID and len field) so you are asking for text about what to do > > > if there is header with 0 in the ID part but some value in the len > > > part. I assume that good policy will be the same as for ID 15 but > > > any error behavior can be expected (ignore all header extension > > > ,treat like padding ...) since this case is not discussed in > > > RFC5285. >=20 > My thinking is that if the draft is careful to specify the processing of = the > invalid case of ID=3D15 in the one-byte format, then it would similarly m= ake > sense for the draft to specify the processing of the invalid case ID=3D0,= len>0. >=20 > Dale From nobody Thu Feb 16 05:49:13 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA72E126BF7 for ; Thu, 16 Feb 2017 05:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PeGg8V1g4Dd for ; Thu, 16 Feb 2017 05:49:12 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 AB90B129A0F for ; Thu, 16 Feb 2017 05:49:11 -0800 (PST) X-AuditID: c1b4fb25-93e1698000001738-75-58a5add52012 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id 35.4F.05944.5DDA5A85; Thu, 16 Feb 2017 14:49:09 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.3.319.2; Thu, 16 Feb 2017 14:48:21 +0100 To: "Dale R. Worley" , Roni Even References: <87y3xo7zul.fsf@hobgoblin.ariadne.com> From: Magnus Westerlund Message-ID: Date: Thu, 16 Feb 2017 14:48:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <87y3xo7zul.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyM2K7qO7VtUsjDG5sMrZ42bOS3eLTsfMs FvP7P7JYvDxR5sDisfXkDzaPyfu/Mnu0HHnL6rFkyU+mAJYoLpuU1JzMstQifbsEroy7b6wK TghWNL1bzdjA+Iu3i5GTQ0LARGLbkxNMXYxcHEIC6xgl/nYeZoVwljNK3H11mRmkSlggVGLb jYNMILaIgLfEov8djCC2kICRxKtdF9hBbGYBNYnXzxezgthsAhYSN380snUxcnDwCthLnJmh DBJmEVCVWH2vgw3EFhWIkdjbfx9sJK+AoMTJmU9YQGxOAWOJTdtmsIO0MgO1PthaBjFdXqJ5 62xmiK3aEg1NHawTGAVmIemehdAxC0nHAkbmVYyixanFSbnpRsZ6qUWZycXF+Xl6eaklmxiB YXtwy2/VHYyX3zgeYhTgYFTi4f2QsyRCiDWxrLgy9xCjBAezkggv45KlEUK8KYmVValF+fFF pTmpxYcYpTlYlMR5zVbeDxcSSE8sSc1OTS1ILYLJMnFwSjUwikyZ0r9YOb45tHZdf+KSxT92 VH6QX8HMKxkW3eAk+DXa9wLT6x33EnaEpjp4Tcp6sDH+ubum4+I2Lefvr249iD1wSNy4+qSi 25nn6g0rzm90mfuMLbLav0zuZl2WhtYHgS+nmds7rkx2aXSaoTE7jOf52+cvI1rl/u87zzm1 /m6/s8mpusydSizFGYmGWsxFxYkAt+uM7lcCAAA= Archived-At: Cc: avt@ietf.org, singer@apple.com Subject: Re: [AVTCORE] Need feedback on RFC5285bis (RTP header extensions) comments X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 13:49:13 -0000 Den 2017-02-03 kl. 03:49, skrev Dale R. Worley: > Roni Even writes: >> This bis draft was created to add the support for mixing one byte and >> two bytes in an RTP session. It is good to clarify the text but we >> cannot change any RC5285 or RFC3550 policies in order to keep >> interoperability. > > Hmmm, yes, I hadn't figured that this was just a small modification of > 5285. There seem to be some places where the behavior it > specifies/allows is questionable. Fortunately, I suppose, most of my > comments were about clarifying exactly what it means or making it easier > to see the overal structure. > > I do think you could safely add that in the one-byte format, bytes 0x01 > through 0x0F should be handled like bytes 0xF0 through 0xFF, as that is > now unspecified. > Yes, I think that is a reasonable interpretation. A padding byte is 0x00, and ID=0 and L=1-15 is not supported. Being explicit about this is fine and treat this as broken extension appear to me also as fine. I have assumed you are refering to the second sentence of this paragraph (Section 4.2): The local identifier value 15 is reserved for future extension and MUST NOT be used as an identifier. If the ID value 15 is encountered, its length field MUST be ignored, processing of the entire extension MUST terminate at that point, and only the extension elements present prior to the element with ID 15 SHOULD be considered. You want something similar for ID value 0 with L>0? There are a remote chance that such a behavior could result in discarding some extensions, and if one want to be more tolerant, then the alternative is to interpret anything with ID=0 as a padding byte. 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 Feb 16 06:18:39 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0884E129629 for ; Thu, 16 Feb 2017 06:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39IipfXHetVf for ; Thu, 16 Feb 2017 06:18:36 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 14B0B1295E3 for ; Thu, 16 Feb 2017 06:18:36 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id r141so16247989wmg.1 for ; Thu, 16 Feb 2017 06:18:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=y/R4oW9W7/sjpAOoUYzGmtR72oBXw1BdzoOHeLQ3s4c=; b=yKM7xm6m5QoUhrsDRc9x3cd1sQhctfcO8/3nxu6nM3tDdCnzxb0asnrTXtZ0ZGaM9O N7a8XTWKJxOXCAcncrETjMNiVRk+Mv0F+vzyPUT76BYlcOUMVcaG24eY80PHpe733HMh 7oM4pJlCNj0ooqwjAUuPARUtkIWzltZ00w3qx9AukIzza9YoipY8pVWoKl0gu6BTcSVd wk8kwmH5w8xU+lMrf85HMDBMw3Bk2r/6VNd9/j7Nv+SBnUBjDDz84J4hmTQlyqd91+iO hWyeXDiZc1fA01fXzOANtWah93l9tgk1pq8jpy7Xe9g5pqhUQbVSgk0J68aGiBepN2rI x0Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=y/R4oW9W7/sjpAOoUYzGmtR72oBXw1BdzoOHeLQ3s4c=; b=VR+sDcQm5D+t5eerokys0lgKE/bueK91BTkyGRa8WTSA9s3tT7unadbS/6A5Jtbtd5 udP3u6u67cQZ3rtGYu7XSxNATJHytmRUjBMPqvGIex+Mk4W56jt9uljDpkCF3vxkPw+M 19IJgjke68ZRdR88kvigrU5mKwzMpsAN/yP/1H2dRJBSTnVsgZW3rYjywawUsE7mrDAt iKdd3hTU/W8rNM1dex5ArIiVTmEy0nHa6FaY5Tih6Wc+yWgRh1SEfb2O7H4zTmhe382d kuo/yJqdl9QgJGgdaPPoJsHqfELUvPLYYmyMZCRMANqZD9JpECkMRHd53ZQu4bbZYnSt 1QAw== X-Gm-Message-State: AMke39lf+aWoL5Uh6wnnrPvSPEcEPRPR22r6ucUTtPCCP7cmQkQ3K5Hxw5MLbAHyyV/EhfYIgsyZCA8PKmfxXw== X-Received: by 10.28.92.83 with SMTP id q80mr2835770wmb.108.1487254714620; Thu, 16 Feb 2017 06:18:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.182.85 with HTTP; Thu, 16 Feb 2017 06:18:14 -0800 (PST) In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD770167@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD770167@DGGEMM506-MBX.china.huawei.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 16 Feb 2017 15:18:14 +0100 Message-ID: To: Roni Even Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF AVTCore WG , David Singer Subject: Re: [AVTCORE] Need feedback on RFC5285bis (RTP header extensions) comments X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 14:18:38 -0000 2017-02-01 11:42 GMT+01:00 Roni Even : > In section 7 =E2=80=9CIf an extension is marked as "sendonly" and the a= nswerer > desires to receive it, the extension MUST be marked as "recvonly" in the > SDP answer. Is it so bad if the answer contains the same RTP extension with no directio= n? --=20 I=C3=B1aki Baz Castillo From nobody Thu Feb 16 06:58:13 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C35129A3B for ; Thu, 16 Feb 2017 06:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4c17rvjFHfBe for ; Thu, 16 Feb 2017 06:58:09 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 8CC21129A39 for ; Thu, 16 Feb 2017 06:58:09 -0800 (PST) X-AuditID: c1b4fb30-2868b98000002c77-0d-58a5bdff4d8d Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id 8B.7F.11383.FFDB5A85; Thu, 16 Feb 2017 15:58: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.319.2; Thu, 16 Feb 2017 15:57:08 +0100 To: "Dale R. Worley" , References: <87zii55lwt.fsf@hobgoblin.ariadne.com> From: Magnus Westerlund Message-ID: <98c8fc83-3965-8f3d-1b6b-b9ec335a2cd6@ericsson.com> Date: Thu, 16 Feb 2017 15:57:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <87zii55lwt.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyM2K7h+7/vUsjDPasNLd42bOS3WJ+/0cW i5cnyhyYPbae/MHmMXn/V2aPJUt+MgUwR3HZpKTmZJalFunbJXBlbHoYXbBHouLAjPWsDYyz hbsYOTkkBEwkZl24zNrFyMUhJLCOUWLulMNMEM5yRolLC5uYuxg5OIQFfCTOfg8HaRARsJTY 0tHLDGILCRhJHN1ymQXEZhYQk1iy8B5YnE3AQuLmj0Y2EJtXwF5i97zpTCBjWARUJbY8zQQJ iwrESOztv88EUSIocXLmExaQEk4BY4lFbyJATGagzgdbyyCGy0s0b50NtVRboqGpg3UCo8As JM2zEDpmIelYwMi8ilG0OLU4KTfdyEgvtSgzubg4P08vL7VkEyMwPA9u+W2wg/Hlc8dDjAIc jEo8vB9ylkQIsSaWFVfmHmKU4GBWEuHNWLs0Qog3JbGyKrUoP76oNCe1+BCjNAeLkjiv2cr7 4UIC6YklqdmpqQWpRTBZJg5OqQZG/qpE/6v3vbTWa9o63b6ReVTwmd7Tn5VnA8/W3Ui6frRQ lPO25H2BYp3+1E2MR79P+PdHyH+b8cINMu6h/Hv3rv26wil63Y+ed1tms0S5R3zR+bJMYZ7G 7JvrcxT6I85N5954cVVnkEHpoY97tDvXxqjoprR2S5REHJVfVZrzdNWmV1L/P0/bosRSnJFo qMVcVJwIAG1+ULRLAgAA Archived-At: Cc: singer@apple.com Subject: Re: [AVTCORE] draft-ietf-avtcore-rfc5285-bis-05 -- fun special case X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 14:58:11 -0000 Hi, If one follows RFC5285, then one can setup a number of formats with IDs in 1-14 range. Then one can decide on RTP stream level which format one or two byte. However, one you started sending one or two-byte in a particular RTP stream, you are not allowed to switch. In addition the sender doesn't know if two-byte will work. It can assume that one-byte is available. So there is clearly issues here about capability determination from a sender perspective. Which is why RFC 5285bis exists. So the limiation on length is clearly present. I think the question is if this needs to be lifted in this part or not. I would note that actually the rule needs to be considered in the context of a particular RTP stream. Because one can actually consider that one RTP stream will only send a sub-set of header extension and thus be capable of using one-byte headers in this RTP stream, but another RTP stream requires the 2-byte header and thus should use that from the start if the extmap-allow-mixed is not negotiated. Looking at the -05 and -06 I can't find this rule in either version. Where was it included? Based on that I can't find the context for this, I can't judge how important it is to make any changes. Cheers Magnus Den 2017-02-02 kl. 04:09, skrev Dale R. Worley: > Suppose that in the offer and the answer all of the identifiers are less > than 15. And suppose that mixing one-byte and two-byte formats is *not* > negotiated. > > RTP packets are sent containing one-byte extension headers, and > everything is going along well, and suddenly, the current data part for > an extension is over 16 bytes. That data can't be encoded in the > one-byte format. > > I think there needs to be a rule that a UA can't commit to the one-byte > format unless all of the extensions that might be sent are defined to > have data lengths between 1 and 16 bytes. So instead of the current > rule > > A client MUST NOT send an extension header with the one-byte format > if any negotiated valid identifier exceeds 14 and extmap-allow-mixed > is not negotiated. > > we need > > A client MUST NOT send an extension header with the one-byte format > if: > (1) extmap-allow-mixed is not negotiated, and > (2) (a) some negotiated valid identifier is more than 14, or > (b)some negotiated extension may have a data length of 0 > bytes or more than 16 bytes. > > Dale > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- 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 Feb 16 07:52:35 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D82129639 for ; Thu, 16 Feb 2017 07:52:33 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iyb1-mIHXewp for ; Thu, 16 Feb 2017 07:52:32 -0800 (PST) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA48412944D for ; Thu, 16 Feb 2017 07:52:31 -0800 (PST) Received: by mail-wr0-x235.google.com with SMTP id i10so14587963wrb.0 for ; Thu, 16 Feb 2017 07:52:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=F/WauUS89e/dtS6NCZpVRTQborTw/WQ+43ww4Aeu9eg=; b=k7pgS3xBftKcJpYEAQomfK7hpy25aEYiCf7WZtN7kyOHqV/Srg+09MOCbcOQIdY74o dGgYvB2fv2RguXjSlWdWIL8d0mLp1/YWCv2zK1cu9uS273na9I9Xred0WBbTGcr551wQ PGSyV0GtWoHYZ2FAjkPF+cjDx3dhQGYbcW/VBzDMx2NUl4zqeaQzkmCA19CjJJ2GKe+y gr+rue/yZcN/p6Kx6Jw/WIs1xAK1YcmIRFVsoyR4PMkuN3j4QD4+rSLBjYiLDO/LiFkm 9rx13i5jKQNUbpiJgxBrZnq8F0WFL7HkVN3sOULhqIwsg5A4z2owmFjsyJEJBvpVnE2P SskA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=F/WauUS89e/dtS6NCZpVRTQborTw/WQ+43ww4Aeu9eg=; b=gNR2jN7pWndAzMzpY1o+YApl+giz/89cphIM3N55mWbqgDHtCFsMbt8/WKREbA5lWL nNGbXbIBcZ2VL1qmWXCMb/E66to73Z0O4C8MVlYaQLz3OqSJ86IIoLoFp6h0254QlIcC 3N1WccJwOtxrYc0o51wg3SiDl6gvgOqybeVhAuggyd7/Q9LwcrE+CeqQ3y/7u2AYnfr1 kynv3WkZd0eX6S/JRZGEPQ3EZ8unBQLNGEcaowkPtLwF0N1ZkzPwZ4xLtU8PKBPRJCsJ iGBoAppREqkjs7QhC6dDFcb0//dMRlst9AXqwetKOPDP4ioOrfqRXA001m0RZZ6iQT9m 1StQ== X-Gm-Message-State: AMke39k2Omyfvi2LhSze5mWQHeoPEYpI2047xFXdykN2UStaY+qyY1X5u03Xplj//NZj/GzLjegPufICgq8inw== X-Received: by 10.223.133.226 with SMTP id 31mr2766678wru.137.1487260350243; Thu, 16 Feb 2017 07:52:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.182.85 with HTTP; Thu, 16 Feb 2017 07:52:09 -0800 (PST) In-Reply-To: <87poii2mef.fsf@hobgoblin.ariadne.com> References: <87poii2mef.fsf@hobgoblin.ariadne.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 16 Feb 2017 16:52:09 +0100 Message-ID: To: "Dale R. Worley" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "avt@ietf.org" , David Singer Subject: Re: [AVTCORE] Need feedback on RFC5285bis (RTP header extensions) comments X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 15:52:33 -0000 2017-02-16 16:19 GMT+01:00 Dale R. Worley : > It seems to me that the handling of extension directions should be done > in the same way as the SDP directionality attributes, where the > directionality in the answer must be a subset of the directionality in > the offer (accounting for the fact that the offer and the answer name > directions with opposite polarity). See e.g., RFC 3264 section 6.1. Makes sense. It's just that it's a bit artificial. If a party sends "sendonly" both of them already know that the other party can just receive. --=20 I=C3=B1aki Baz Castillo From nobody Thu Feb 16 12:01:05 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC721296C8; Thu, 16 Feb 2017 12:01:02 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7brmvFkhM-Q; Thu, 16 Feb 2017 12:01:00 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA5512941A; Thu, 16 Feb 2017 12:00:49 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v1GK0jNi025345 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 16 Feb 2017 14:00:45 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Magnus Westerlund" Date: Thu, 16 Feb 2017 14:00:44 -0600 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5344) Archived-At: Cc: "avtext@ietf.org" , IETF AVTCore WG Subject: Re: [AVTCORE] [avtext] Proposed charter for merger of AVTCORE and AVTEXT into AVT X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 20:01:03 -0000 Hi AVTCORE and AVTEXT: Since we had support for this in previous discussion, and unless I missed something, no objections to the charter text below, I'm going to schedule this for the next available IESG telechat. Hopefully we can complete this before Chicago. Please note that, from a tools perspective, it looks like the easiest thing will be to keep the AVTCORE name for the combined group. That will keep the post-split history of the AVTCORE work, and we can put a link to the history for AVTEXT. Going back to AVT would favor ancient pre-split history, and force people to follow links to find any recent history. Thanks! Ben. On 31 Jan 2017, at 3:42, Magnus Westerlund wrote: > WGs, > > Below you find the chairs and ADs proposal for an AVT WG charter, > covering the work currently done by AVTCORE and AVTEXT WG. If you have > any issues, suggestions or other proposals, please provide them no > later than the 14th of February. > > > Charter text > ------------ > > The Real-time Transport Protocol (RTP) along with its associated > profiles and payload formats provides for real-time transmission of > audio and video over unicast and multicast transports. RTP is widely > implemented, and deployed for a wide range of applications, ranging > from telephony to television over IP. RTP itself has been shepherded > to Full Standard. Its associated profiles, extensions, and payload > formats are currently at various levels of standards maturity. As new > applications have emerged, the need for guidelines for the use of the > RTP/RTCP protocols and extensions specific to those applications has > been identified. > > The AVT working group is chartered to maintain the core RTP/RTCP > specifications and the AVP, SAVP, AVPF, and SAVPF profiles. The group > will provide architectural guidance for extending the protocols and > guidelines for their proper use. While other working groups are > chartered to work on RTCP Extended Report Extensions (XRBLOCK) and RTP > Payload Formats (PAYLOAD), extensions that are generally applicable > will be developed in AVT. The AVT working group is also charted to > develop application-specific guidelines for the use of RTP/RTCP > protocols with the AVP, SAVP, AVPF, and SAVPF profiles, and extensions > to those protocols that are driven by application-specific needs. > > The AVT working group will coordinate closely with the Security Area > while working on maintenance and enhancements to the SRTP Profile > (SAVP). > > ---- End of Charter Text > > Milestone that exist in either of the groups will be moved to the AVT > WG. > > -- > > 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 Sun Feb 19 07:06:58 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0394812951F for ; Sun, 19 Feb 2017 07:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uA78ROZZKgzB for ; Sun, 19 Feb 2017 07:06:54 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 501311296BF for ; Sun, 19 Feb 2017 07:06:54 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAW58943; Sun, 19 Feb 2017 15:06:51 +0000 (GMT) Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 19 Feb 2017 15:06:50 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0301.000; Sun, 19 Feb 2017 23:06:47 +0800 From: Roni Even To: "avt@ietf.org" Thread-Topic: RFC5285bis open issues Thread-Index: AdKKwXPucrb9jW2aSFCqJMwiTJKcvw== Date: Sun, 19 Feb 2017 15:06:46 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD77527B@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.150] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD77527BDGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.58A9B48C.0102, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 457ba6f577104296b9867f4956859899 Archived-At: Subject: [AVTCORE] RFC5285bis open issues X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2017 15:06:57 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD77527BDGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the email discussion I see some issues that need conclusion 1. For the one-byte RTP header extension if id=3D0 and len>0 what act= ion to take since there is no current text a. This is also padding b. This is an error so stop interpreting following header extensions -= similar to id=3D15 2. Can we conclude from RFC5285 that if only IDs between 1-14 are off= ered it means that only one-byte RTP header extension are supported? Thanks Roni Even As editor of RFC5285bis --_000_6E58094ECC8D8344914996DAD28F1CCD77527BDGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Based on the email discussion I see some issues that= need conclusion

 

1.     &= nbsp; For the one-byte RTP heade= r extension if id=3D0 and len>0 what action to take since there is no cu= rrent text

a.       This is also padding =

b.      This is an error so stop i= nterpreting following header extensions – similar to id=3D15

2.     &= nbsp; Can we conclude from RFC52= 85 that if only IDs between 1-14 are offered it means that only one-byte RT= P header extension are supported?

 

 

Thanks

Roni Even

As editor of RFC5285bis

--_000_6E58094ECC8D8344914996DAD28F1CCD77527BDGGEMM506MBXchina_-- From nobody Sun Feb 19 09:04:19 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3D0129531 for ; Thu, 16 Feb 2017 12:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tipOElA4-219 for ; Thu, 16 Feb 2017 12:23:30 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADB791294C2 for ; Thu, 16 Feb 2017 12:23:30 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 94C25B8020D; Thu, 16 Feb 2017 12:23:30 -0800 (PST) To: mcgrew@cisco.com, mythicalkevin@yahoo.com, ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, roni.even@huawei.com, magnus.westerlund@ericsson.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20170216202330.94C25B8020D@rfc-editor.org> Date: Thu, 16 Feb 2017 12:23:30 -0800 (PST) Archived-At: X-Mailman-Approved-At: Sun, 19 Feb 2017 09:04:18 -0800 Cc: text/plain@rfc-editor.org, rfc-editor@rfc-editor.orgContent-Type, avt@ietf.org, charset=UTF-8@rfc-editor.org Subject: [AVTCORE] [Technical Errata Reported] RFC7714 (4938) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 20:23:32 -0000 The following errata report has been submitted for RFC7714, "AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7714&eid=4938 -------------------------------------- Type: Technical Reported by: Paul E. Jones Section: 11 Original Text ------------- A Key Derivation Function (KDF) is used to derive all of the required encryption and authentication keys from a secret value shared by the endpoints. The AEAD_AES_128_GCM algorithm MUST use the (128-bit) AES_CM PRF KDF described in [RFC3711]. AEAD_AES_256_GCM MUST use the AES_256_CM_PRF KDF described in [RFC6188]. Corrected Text -------------- A Key Derivation Function (KDF) is used to derive all of the required encryption and authentication keys from a secret value shared by the endpoints. The AEAD_AES_128_GCM algorithm MUST use the (128-bit) AES_CM PRF KDF described in [RFC3711]. AEAD_AES_256_GCM MUST use the AES_256_CM_PRF KDF described in [RFC6188]. Since the KDF functions in those RFCs assume as input a 112-bit master salt, the 96-bit master salt specified in this document must be multiplied by 2^16 to form the 112-bit salt used as the master salt in those key derivation functions. Notes ----- The salt specified in RFC 7714 is 96 bits in length, but intended for use in KDF functions defined in RFC 3711. This led to different interpretations when implementing this RFC. A more complete description was presented on the avtcore mailing list (https://mailarchive.ietf.org/arch/msg/avt/IRfLuNKglD3qhqwSz3v3t0CG6fA) and, after some dialog, there seemed to be agreement to adopt the approach most widely implemented (https://mailarchive.ietf.org/arch/msg/avt/-C1cIWQXpyzS2KfBjGR6B2kK92w). This suggested text is intended to reflect that agreement. In effect, 16 zero bits are padded to the right of the salt value defined in RFC 7714 (creating a 112 bit salt value) before it is used as described in the KDF functions defined in RFC 3711 that require a 112 bit salt value. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7714 (draft-ietf-avtcore-srtp-aes-gcm-17) -------------------------------------- Title : AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP) Publication Date : December 2015 Author(s) : D. McGrew, K. Igoe Category : PROPOSED STANDARD Source : Audio/Video Transport Core Maintenance Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Sun Feb 19 09:04:25 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51ABE129629 for ; Thu, 16 Feb 2017 13:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-RsYdifM1M9 for ; Thu, 16 Feb 2017 13:45:36 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 1C248129504 for ; Thu, 16 Feb 2017 13:45:36 -0800 (PST) Received: from [192.168.1.20] (cpe-098-122-167-029.nc.res.rr.com [98.122.167.29] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id v1GLj8hC009062 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Feb 2017 16:45:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1487281513; bh=TWCA/fSwfQFtbJJKBM/5mxvvXkbxDFR9DPmzsA0jxd8=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=IVDYLzaIG1GCoCeo8GyY+61TBskb/ylKiyhk40mYv6ciRihFhAGoufyS0XYH4fIQJ l2DH0wKlrfwUIpSypslrUPMCB9g3BhZx9aGyNyaf59+9e+rSTgMFGriO5ukL2F64K7 VwerKdKnQ6GB8uGn0AFvG4wwn9ODGzeJsHRWUKLE= From: "Paul E. Jones" To: "RFC Errata System" , mcgrew@cisco.com, mythicalkevin@yahoo.com, ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, roni.even@huawei.com, magnus.westerlund@ericsson.com Date: Thu, 16 Feb 2017 21:45:08 +0000 Message-Id: In-Reply-To: <20170216202330.94C25B8020D@rfc-editor.org> References: <20170216202330.94C25B8020D@rfc-editor.org> User-Agent: eM_Client/7.0.28492.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (dublin.packetizer.com [10.165.122.250]); Thu, 16 Feb 2017 16:45:13 -0500 (EST) Archived-At: X-Mailman-Approved-At: Sun, 19 Feb 2017 09:04:18 -0800 Cc: text/plain@rfc-editor.org, avt@ietf.org Subject: Re: [AVTCORE] [Technical Errata Reported] RFC7714 (4938) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Paul E. Jones" List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 21:45:38 -0000 Since this issue needs closure in order to ensure that we have=20 interoperable solutions, it would be good to have confirmation /=20 agreement on the proposed change. Paul ------ Original Message ------ From: "RFC Errata System" To: mcgrew@cisco.com; mythicalkevin@yahoo.com; ben@nostrum.com;=20 alissa@cooperw.in; aamelnikov@fastmail.fm; roni.even@huawei.com;=20 magnus.westerlund@ericsson.com Cc: paulej@packetizer.com; avt@ietf.org; rfc-editor@rfc-editor.org=20 Content-Type; text/plain@rfc-editor.org; ; charset=3DUTF-8@rfc-editor.org Sent: 2/16/2017 3:23:30 PM Subject: [Technical Errata Reported] RFC7714 (4938) >The following errata report has been submitted for RFC7714, >"AES-GCM Authenticated Encryption in the Secure Real-time Transport=20 >Protocol (SRTP)". > >-------------------------------------- >You may review the report below and at: >http://www.rfc-editor.org/errata_search.php?rfc=3D7714&eid=3D4938 > >-------------------------------------- >Type: Technical >Reported by: Paul E. Jones > >Section: 11 > >Original Text >------------- >A Key Derivation Function (KDF) is used to derive all of the required >encryption and authentication keys from a secret value shared by the >endpoints. The AEAD_AES_128_GCM algorithm MUST use the (128-bit) >AES_CM PRF KDF described in [RFC3711]. AEAD_AES_256_GCM MUST use the >AES_256_CM_PRF KDF described in [RFC6188]. > >Corrected Text >-------------- >A Key Derivation Function (KDF) is used to derive all of the required >encryption and authentication keys from a secret value shared by the >endpoints. The AEAD_AES_128_GCM algorithm MUST use the (128-bit) >AES_CM PRF KDF described in [RFC3711]. AEAD_AES_256_GCM MUST use the >AES_256_CM_PRF KDF described in [RFC6188]. Since the KDF functions in >those RFCs assume as input a 112-bit master salt, the 96-bit master >salt specified in this document must be multiplied by 2^16 to form the >112-bit salt used as the master salt in those key derivation functions. > >Notes >----- >The salt specified in RFC 7714 is 96 bits in length, but intended for=20 >use in KDF functions defined in RFC 3711. This led to different=20 >interpretations when implementing this RFC. A more complete=20 >description was presented on the avtcore mailing list=20 >(https://mailarchive.ietf.org/arch/msg/avt/IRfLuNKglD3qhqwSz3v3t0CG6fA)=20 >and, after some dialog, there seemed to be agreement to adopt the=20 >approach most widely implemented=20 >(https://mailarchive.ietf.org/arch/msg/avt/-C1cIWQXpyzS2KfBjGR6B2kK92w).= =20 > This suggested text is intended to reflect that agreement. In effect,= =20 >16 zero bits are padded to the right of the salt value defined in RFC=20 >7714 (creating a 112 bit salt value) before it is used as described in=20 >the KDF functions defined in RFC 3711 that require a 112 bit salt=20 >value. > >Instructions: >------------- >This erratum is currently posted as "Reported". If necessary, please >use "Reply All" to discuss whether it should be verified or >rejected. When a decision is reached, the verifying party >can log in to change the status and edit the report, if necessary. > >-------------------------------------- >RFC7714 (draft-ietf-avtcore-srtp-aes-gcm-17) >-------------------------------------- >Title : AES-GCM Authenticated Encryption in the Secure=20 >Real-time Transport Protocol (SRTP) >Publication Date : December 2015 >Author(s) : D. McGrew, K. Igoe >Category : PROPOSED STANDARD >Source : Audio/Video Transport Core Maintenance >Area : Applications and Real-Time >Stream : IETF >Verifying Party : IESG From nobody Sun Feb 19 09:04:29 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA63128824 for ; Sat, 18 Feb 2017 23:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9imjnT54SXh4 for ; Sat, 18 Feb 2017 23:39:09 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7E59126D74 for ; Sat, 18 Feb 2017 23:39:08 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGU52127; Sun, 19 Feb 2017 07:38:29 +0000 (GMT) Received: from LHREML709-CAH.china.huawei.com (10.201.108.32) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 19 Feb 2017 07:38:28 +0000 Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 19 Feb 2017 07:38:27 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0301.000; Sun, 19 Feb 2017 15:38:21 +0800 From: Roni Even To: "Paul E. Jones" , RFC Errata System , "mcgrew@cisco.com" , "mythicalkevin@yahoo.com" , "ben@nostrum.com" , "alissa@cooperw.in" , "aamelnikov@fastmail.fm" , "magnus.westerlund@ericsson.com" Thread-Topic: [Technical Errata Reported] RFC7714 (4938) Thread-Index: AQHSiJKQXzMQWGJmPEujV7rwsR/poKFrpKAAgARP0bA= Date: Sun, 19 Feb 2017 07:38:21 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD7751D9@DGGEMM506-MBX.china.huawei.com> References: <20170216202330.94C25B8020D@rfc-editor.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.58A94B75.01F1, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 16cfadb55cdfe9a5ecf38e3bf52abe3c Archived-At: X-Mailman-Approved-At: Sun, 19 Feb 2017 09:04:18 -0800 Cc: "text/plain@rfc-editor.org" , "avt@ietf.org" Subject: Re: [AVTCORE] [Technical Errata Reported] RFC7714 (4938) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2017 07:39:11 -0000 UGF1bCwNCkkgc2F3IHRoZSBlbWFpbCB3aXRoIHdoYXQgbG9va3MgbGlrZSB0aGlzIGRpcmVjdGlv biBidXQgbWF5YmUgdGhlIG5ldyB0ZXh0IHNob3VsZCBtZW50aW9uIGFzIGEgbm90ZSB0aGF0IHNp bmNlIHRoaXMgd2FzIG5vdCBzcGVjaWZpZWQgYmVmb3JlIHRoZXJlIG1heSBiZSBmZXcgaW1wbGVt ZW50YXRpb25zIHRoYXQgYWRkZWQgcGFkZGluZyBvbiB0aGUgb3RoZXIgc2lkZS4NClJvbmkgRXZl bg0KQXMgaW5kaXZpZHVhbA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IFBhdWwgRS4gSm9uZXMgW21haWx0bzpwYXVsZWpAcGFja2V0aXplci5jb21dDQo+IFNlbnQ6INeZ 15XXncKg15QgMTYg16TXkdeo15XXkNeoIDIwMTcgMjM6NDUNCj4gVG86IFJGQyBFcnJhdGEgU3lz dGVtOyBtY2dyZXdAY2lzY28uY29tOyBteXRoaWNhbGtldmluQHlhaG9vLmNvbTsNCj4gYmVuQG5v c3RydW0uY29tOyBhbGlzc2FAY29vcGVydy5pbjsgYWFtZWxuaWtvdkBmYXN0bWFpbC5mbTsgUm9u aSBFdmVuOw0KPiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCj4gQ2M6IGF2dEBpZXRm Lm9yZzsgdGV4dC9wbGFpbkByZmMtZWRpdG9yLm9yZw0KPiBTdWJqZWN0OiBSZTogW1RlY2huaWNh bCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzc3MTQgKDQ5MzgpDQo+IA0KPiBTaW5jZSB0aGlzIGlzc3Vl IG5lZWRzIGNsb3N1cmUgaW4gb3JkZXIgdG8gZW5zdXJlIHRoYXQgd2UgaGF2ZSBpbnRlcm9wZXJh YmxlDQo+IHNvbHV0aW9ucywgaXQgd291bGQgYmUgZ29vZCB0byBoYXZlIGNvbmZpcm1hdGlvbiAv IGFncmVlbWVudCBvbiB0aGUNCj4gcHJvcG9zZWQgY2hhbmdlLg0KPiANCj4gUGF1bA0KPiANCj4g LS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tDQo+IEZyb206ICJSRkMgRXJyYXRhIFN5c3Rl bSIgPHJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmc+DQo+IFRvOiBtY2dyZXdAY2lzY28uY29tOyBt eXRoaWNhbGtldmluQHlhaG9vLmNvbTsgYmVuQG5vc3RydW0uY29tOw0KPiBhbGlzc2FAY29vcGVy dy5pbjsgYWFtZWxuaWtvdkBmYXN0bWFpbC5mbTsgcm9uaS5ldmVuQGh1YXdlaS5jb207DQo+IG1h Z251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KPiBDYzogcGF1bGVqQHBhY2tldGl6ZXIuY29t OyBhdnRAaWV0Zi5vcmc7IHJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmcgQ29udGVudC0NCj4gVHlw ZTsgdGV4dC9wbGFpbkByZmMtZWRpdG9yLm9yZzsgOyBjaGFyc2V0PVVURi04QHJmYy1lZGl0b3Iu b3JnDQo+IFNlbnQ6IDIvMTYvMjAxNyAzOjIzOjMwIFBNDQo+IFN1YmplY3Q6IFtUZWNobmljYWwg RXJyYXRhIFJlcG9ydGVkXSBSRkM3NzE0ICg0OTM4KQ0KPiANCj4gPlRoZSBmb2xsb3dpbmcgZXJy YXRhIHJlcG9ydCBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9yIFJGQzc3MTQsICJBRVMtR0NNDQo+ID5B dXRoZW50aWNhdGVkIEVuY3J5cHRpb24gaW4gdGhlIFNlY3VyZSBSZWFsLXRpbWUgVHJhbnNwb3J0 IFByb3RvY29sDQo+ID4oU1JUUCkiLg0KPiA+DQo+ID4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiA+WW91IG1heSByZXZpZXcgdGhlIHJlcG9ydCBiZWxvdyBhbmQgYXQ6 DQo+ID5odHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0YV9zZWFyY2gucGhwP3JmYz03NzE0 JmVpZD00OTM4DQo+ID4NCj4gPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+ID5UeXBlOiBUZWNobmljYWwNCj4gPlJlcG9ydGVkIGJ5OiBQYXVsIEUuIEpvbmVzIDxwYXVs ZWpAcGFja2V0aXplci5jb20+DQo+ID4NCj4gPlNlY3Rpb246IDExDQo+ID4NCj4gPk9yaWdpbmFs IFRleHQNCj4gPi0tLS0tLS0tLS0tLS0NCj4gPkEgS2V5IERlcml2YXRpb24gRnVuY3Rpb24gKEtE RikgaXMgdXNlZCB0byBkZXJpdmUgYWxsIG9mIHRoZSByZXF1aXJlZA0KPiA+ZW5jcnlwdGlvbiBh bmQgYXV0aGVudGljYXRpb24ga2V5cyBmcm9tIGEgc2VjcmV0IHZhbHVlIHNoYXJlZCBieSB0aGUN Cj4gPmVuZHBvaW50cy4gIFRoZSBBRUFEX0FFU18xMjhfR0NNIGFsZ29yaXRobSBNVVNUIHVzZSB0 aGUgKDEyOC1iaXQpDQo+ID5BRVNfQ00gUFJGIEtERiBkZXNjcmliZWQgaW4gW1JGQzM3MTFdLiAg QUVBRF9BRVNfMjU2X0dDTSBNVVNUIHVzZQ0KPiB0aGUNCj4gPkFFU18yNTZfQ01fUFJGIEtERiBk ZXNjcmliZWQgaW4gW1JGQzYxODhdLg0KPiA+DQo+ID5Db3JyZWN0ZWQgVGV4dA0KPiA+LS0tLS0t LS0tLS0tLS0NCj4gPkEgS2V5IERlcml2YXRpb24gRnVuY3Rpb24gKEtERikgaXMgdXNlZCB0byBk ZXJpdmUgYWxsIG9mIHRoZSByZXF1aXJlZA0KPiA+ZW5jcnlwdGlvbiBhbmQgYXV0aGVudGljYXRp b24ga2V5cyBmcm9tIGEgc2VjcmV0IHZhbHVlIHNoYXJlZCBieSB0aGUNCj4gPmVuZHBvaW50cy4g IFRoZSBBRUFEX0FFU18xMjhfR0NNIGFsZ29yaXRobSBNVVNUIHVzZSB0aGUgKDEyOC1iaXQpDQo+ ID5BRVNfQ00gUFJGIEtERiBkZXNjcmliZWQgaW4gW1JGQzM3MTFdLiAgQUVBRF9BRVNfMjU2X0dD TSBNVVNUIHVzZQ0KPiB0aGUNCj4gPkFFU18yNTZfQ01fUFJGIEtERiBkZXNjcmliZWQgaW4gW1JG QzYxODhdLiAgU2luY2UgdGhlIEtERiBmdW5jdGlvbnMgaW4NCj4gPnRob3NlIFJGQ3MgYXNzdW1l IGFzIGlucHV0IGEgMTEyLWJpdCBtYXN0ZXIgc2FsdCwgdGhlIDk2LWJpdCBtYXN0ZXINCj4gPnNh bHQgc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQgbXVzdCBiZSBtdWx0aXBsaWVkIGJ5IDJeMTYg dG8gZm9ybSB0aGUNCj4gPjExMi1iaXQgc2FsdCB1c2VkIGFzIHRoZSBtYXN0ZXIgc2FsdCBpbiB0 aG9zZSBrZXkgZGVyaXZhdGlvbiBmdW5jdGlvbnMuDQo+ID4NCj4gPk5vdGVzDQo+ID4tLS0tLQ0K PiA+VGhlIHNhbHQgc3BlY2lmaWVkIGluIFJGQyA3NzE0IGlzIDk2IGJpdHMgaW4gbGVuZ3RoLCBi dXQgaW50ZW5kZWQgZm9yDQo+ID51c2UgaW4gS0RGIGZ1bmN0aW9ucyBkZWZpbmVkIGluIFJGQyAz NzExLiAgVGhpcyBsZWQgdG8gZGlmZmVyZW50DQo+ID5pbnRlcnByZXRhdGlvbnMgd2hlbiBpbXBs ZW1lbnRpbmcgdGhpcyBSRkMuICBBIG1vcmUgY29tcGxldGUNCj4gPmRlc2NyaXB0aW9uIHdhcyBw cmVzZW50ZWQgb24gdGhlIGF2dGNvcmUgbWFpbGluZyBsaXN0DQo+ID4oaHR0cHM6Ly9tYWlsYXJj aGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9hdnQvSVJmTHVOS2dsRDNxaHF3U3ozdjN0MENHNmZBDQo+ ICkNCj4gPmFuZCwgYWZ0ZXIgc29tZSBkaWFsb2csIHRoZXJlIHNlZW1lZCB0byBiZSBhZ3JlZW1l bnQgdG8gYWRvcHQgdGhlDQo+ID5hcHByb2FjaCBtb3N0IHdpZGVseSBpbXBsZW1lbnRlZA0KPiA+ KGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvYXZ0Ly0NCj4gQzFjSVdRWHB5 elMyS2ZCakdSNkIya0s5MncpLg0KPiA+ICBUaGlzIHN1Z2dlc3RlZCB0ZXh0IGlzIGludGVuZGVk IHRvIHJlZmxlY3QgdGhhdCBhZ3JlZW1lbnQuICBJbg0KPiA+ZWZmZWN0LA0KPiA+MTYgemVybyBi aXRzIGFyZSBwYWRkZWQgdG8gdGhlIHJpZ2h0IG9mIHRoZSBzYWx0IHZhbHVlICBkZWZpbmVkIGlu IFJGQw0KPiA+NzcxNCAoY3JlYXRpbmcgYSAxMTIgYml0IHNhbHQgdmFsdWUpIGJlZm9yZSBpdCBp cyB1c2VkIGFzIGRlc2NyaWJlZCBpbg0KPiA+dGhlIEtERiBmdW5jdGlvbnMgZGVmaW5lZCBpbiBS RkMgMzcxMSB0aGF0IHJlcXVpcmUgYSAxMTIgYml0IHNhbHQNCj4gPnZhbHVlLg0KPiA+DQo+ID5J bnN0cnVjdGlvbnM6DQo+ID4tLS0tLS0tLS0tLS0tDQo+ID5UaGlzIGVycmF0dW0gaXMgY3VycmVu dGx5IHBvc3RlZCBhcyAiUmVwb3J0ZWQiLiBJZiBuZWNlc3NhcnksIHBsZWFzZQ0KPiA+dXNlICJS ZXBseSBBbGwiIHRvIGRpc2N1c3Mgd2hldGhlciBpdCBzaG91bGQgYmUgdmVyaWZpZWQgb3IgcmVq ZWN0ZWQuDQo+ID5XaGVuIGEgZGVjaXNpb24gaXMgcmVhY2hlZCwgdGhlIHZlcmlmeWluZyBwYXJ0 eSBjYW4gbG9nIGluIHRvIGNoYW5nZQ0KPiA+dGhlIHN0YXR1cyBhbmQgZWRpdCB0aGUgcmVwb3J0 LCBpZiBuZWNlc3NhcnkuDQo+ID4NCj4gPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+ID5SRkM3NzE0IChkcmFmdC1pZXRmLWF2dGNvcmUtc3J0cC1hZXMtZ2NtLTE3KQ0K PiA+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPlRpdGxlICAgICAg ICAgICAgICAgOiBBRVMtR0NNIEF1dGhlbnRpY2F0ZWQgRW5jcnlwdGlvbiBpbiB0aGUgU2VjdXJl DQo+ID5SZWFsLXRpbWUgVHJhbnNwb3J0IFByb3RvY29sIChTUlRQKQ0KPiA+UHVibGljYXRpb24g RGF0ZSAgICA6IERlY2VtYmVyIDIwMTUNCj4gPkF1dGhvcihzKSAgICAgICAgICAgOiBELiBNY0dy ZXcsIEsuIElnb2UNCj4gPkNhdGVnb3J5ICAgICAgICAgICAgOiBQUk9QT1NFRCBTVEFOREFSRA0K PiA+U291cmNlICAgICAgICAgICAgICA6IEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50 ZW5hbmNlDQo+ID5BcmVhICAgICAgICAgICAgICAgIDogQXBwbGljYXRpb25zIGFuZCBSZWFsLVRp bWUNCj4gPlN0cmVhbSAgICAgICAgICAgICAgOiBJRVRGDQo+ID5WZXJpZnlpbmcgUGFydHkgICAg IDogSUVTRw0KDQo= From nobody Sun Feb 19 09:04:31 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE3712950C for ; Sun, 19 Feb 2017 06:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.991 X-Spam-Level: X-Spam-Status: No, score=-0.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=packetizer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5vWKm66KDiP for ; Sun, 19 Feb 2017 06:18:35 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 1055F129559 for ; Sun, 19 Feb 2017 06:18:34 -0800 (PST) Received: from dyn-167.arid.us (cpe-098-122-167-029.nc.res.rr.com [98.122.167.29] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id v1JEIDQx028412 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 19 Feb 2017 09:18:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1487513896; bh=wOZpAEYUmvcSdAI08hijg1k0/f71XZb2HxqKAKue7bM=; h=Date:In-Reply-To:References:Subject:To:CC:From; b=JfMk+ZXrddgheMeNwwWoGCZ9b1bHVYeYCYme17x7yc4+vy5gRKrGoZ0jbC2qFNhmM wcTxgjx/rEgzp1OeEaB5kSHKBUCWZ2VsdizxkpRw9y8BKmQssCUtjvsBe9VKt/NHYZ C3VMQXxbagw68QMqXNVibEzRYXd6vVFvzNlMDfuY= Date: Sun, 19 Feb 2017 09:18:12 -0500 User-Agent: K-9 Mail for Android In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD7751D9@DGGEMM506-MBX.china.huawei.com> References: <20170216202330.94C25B8020D@rfc-editor.org> <6E58094ECC8D8344914996DAD28F1CCD7751D9@DGGEMM506-MBX.china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----QSRUG4JENTCMVSOIDHURID6FWMA9R7" Content-Transfer-Encoding: 7bit To: Roni Even , RFC Errata System , "mcgrew@cisco.com" , "mythicalkevin@yahoo.com" , "ben@nostrum.com" , "alissa@cooperw.in" , "aamelnikov@fastmail.fm" , "magnus.westerlund@ericsson.com" From: "Paul E. Jones" Message-ID: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (dublin.packetizer.com [10.165.122.250]); Sun, 19 Feb 2017 09:18:16 -0500 (EST) Archived-At: X-Mailman-Approved-At: Sun, 19 Feb 2017 09:04:18 -0800 Cc: "text/plain@rfc-editor.org" , "avt@ietf.org" Subject: Re: [AVTCORE] [Technical Errata Reported] RFC7714 (4938) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2017 14:18:37 -0000 ------QSRUG4JENTCMVSOIDHURID6FWMA9R7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Roni, Sure, we could do that=2E However, I do wonder how useful that would be= =2E In the outside chance one encounters such an implementation, what woul= d they do about it? Paul -------- Original Message -------- From: Roni Even Sent: February 19, 2017 2:38:21 AM EST To: "Paul E=2E Jones" , RFC Errata System , "mcgrew@cisco=2Ecom" , "mythica= lkevin@yahoo=2Ecom" , "ben@nostrum=2Ecom" , "alissa@cooperw=2Ein" , "aamelnikov@fas= tmail=2Efm" , "magnus=2Ewesterlund@ericsson=2Ecom= " Cc: "avt@ietf=2Eorg" , "text/plain@rfc-editor=2Eorg" Subject: RE: [Technical Errata Reported] RFC7714 (4938) Paul, I saw the email with what looks like this direction but maybe the new text= should mention as a note that since this was not specified before there ma= y be few implementations that added padding on the other side=2E Roni Even As individual > -----Original Message----- > From: Paul E=2E Jones [mailto:paulej@packetizer=2Ecom] > Sent: =D7=99=D7=95=D7=9D=C2=A0=D7=94 16 =D7=A4=D7=91=D7=A8=D7=95=D7=90= =D7=A8 2017 23:45 > To: RFC Errata System; mcgrew@cisco=2Ecom; mythicalkevin@yahoo=2Ecom; > ben@nostrum=2Ecom; alissa@cooperw=2Ein; aamelnikov@fastmail=2Efm; Roni E= ven; > magnus=2Ewesterlund@ericsson=2Ecom > Cc: avt@ietf=2Eorg; text/plain@rfc-editor=2Eorg > Subject: Re: [Technical Errata Reported] RFC7714 (4938) >=20 > Since this issue needs closure in order to ensure that we have interoper= able > solutions, it would be good to have confirmation / agreement on the > proposed change=2E >=20 > Paul >=20 > ------ Original Message ------ > From: "RFC Errata System" > To: mcgrew@cisco=2Ecom; mythicalkevin@yahoo=2Ecom; ben@nostrum=2Ecom; > alissa@cooperw=2Ein; aamelnikov@fastmail=2Efm; roni=2Eeven@huawei=2Ecom; > magnus=2Ewesterlund@ericsson=2Ecom > Cc: paulej@packetizer=2Ecom; avt@ietf=2Eorg; rfc-editor@rfc-editor=2Eorg= Content- > Type; text/plain@rfc-editor=2Eorg; ; charset=3DUTF-8@rfc-editor=2Eorg > Sent: 2/16/2017 3:23:30 PM > Subject: [Technical Errata Reported] RFC7714 (4938) >=20 > >The following errata report has been submitted for RFC7714, "AES-GCM > >Authenticated Encryption in the Secure Real-time Transport Protocol > >(SRTP)"=2E > > > >-------------------------------------- > >You may review the report below and at: > >http://www=2Erfc-editor=2Eorg/errata_search=2Ephp?rfc=3D7714&eid=3D4938 > > > >-------------------------------------- > >Type: Technical > >Reported by: Paul E=2E Jones > > > >Section: 11 > > > >Original Text > >------------- > >A Key Derivation Function (KDF) is used to derive all of the required > >encryption and authentication keys from a secret value shared by the > >endpoints=2E The AEAD_AES_128_GCM algorithm MUST use the (128-bit) > >AES_CM PRF KDF described in [RFC3711]=2E AEAD_AES_256_GCM MUST use > the > >AES_256_CM_PRF KDF described in [RFC6188]=2E > > > >Corrected Text > >-------------- > >A Key Derivation Function (KDF) is used to derive all of the required > >encryption and authentication keys from a secret value shared by the > >endpoints=2E The AEAD_AES_128_GCM algorithm MUST use the (128-bit) > >AES_CM PRF KDF described in [RFC3711]=2E AEAD_AES_256_GCM MUST use > the > >AES_256_CM_PRF KDF described in [RFC6188]=2E Since the KDF functions i= n > >those RFCs assume as input a 112-bit master salt, the 96-bit master > >salt specified in this document must be multiplied by 2^16 to form the > >112-bit salt used as the master salt in those key derivation functions= =2E > > > >Notes > >----- > >The salt specified in RFC 7714 is 96 bits in length, but intended for > >use in KDF functions defined in RFC 3711=2E This led to different > >interpretations when implementing this RFC=2E A more complete > >description was presented on the avtcore mailing list > >(https://mailarchive=2Eietf=2Eorg/arch/msg/avt/IRfLuNKglD3qhqwSz3v3t0CG= 6fA > ) > >and, after some dialog, there seemed to be agreement to adopt the > >approach most widely implemented > >(https://mailarchive=2Eietf=2Eorg/arch/msg/avt/- > C1cIWQXpyzS2KfBjGR6B2kK92w)=2E > > This suggested text is intended to reflect that agreement=2E In > >effect, > >16 zero bits are padded to the right of the salt value defined in RFC > >7714 (creating a 112 bit salt value) before it is used as described in > >the KDF functions defined in RFC 3711 that require a 112 bit salt > >value=2E > > > >Instructions: > >------------- > >This erratum is currently posted as "Reported"=2E If necessary, please > >use "Reply All" to discuss whether it should be verified or rejected=2E > >When a decision is reached, the verifying party can log in to change > >the status and edit the report, if necessary=2E > > > >-------------------------------------- > >RFC7714 (draft-ietf-avtcore-srtp-aes-gcm-17) > >-------------------------------------- > >Title : AES-GCM Authenticated Encryption in the Secure > >Real-time Transport Protocol (SRTP) > >Publication Date : December 2015 > >Author(s) : D=2E McGrew, K=2E Igoe > >Category : PROPOSED STANDARD > >Source : Audio/Video Transport Core Maintenance > >Area : Applications and Real-Time > >Stream : IETF > >Verifying Party : IESG ------QSRUG4JENTCMVSOIDHURID6FWMA9R7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Roni,

Sure, we could do that=2E However, I do wonder how useful that would be= =2E In the outside chance one encounters such an implementation, what woul= d they do about it?

Paul

From: Roni Even <roni=2Eeven@huawei=2Ecom>
Sent: February 19, 2017 2:38:21 AM EST
To: "Paul E=2E Jones" <paulej@packetizer=2Ecom>, RF= C Errata System <rfc-editor@rfc-editor=2Eorg>, "mcgrew@cisco=2Ec= om" <mcgrew@cisco=2Ecom>, "mythicalkevin@yahoo=2Ecom" = <mythicalkevin@yahoo=2Ecom>, "ben@nostrum=2Ecom" <ben@no= strum=2Ecom>, "alissa@cooperw=2Ein" <alissa@cooperw=2Ein>= ;, "aamelnikov@fastmail=2Efm" <aamelnikov@fastmail=2Efm>, &= quot;magnus=2Ewesterlund@ericsson=2Ecom" <magnus=2Ewesterlund@erics= son=2Ecom>
Cc: "avt@ietf=2Eorg" <avt@ietf=2Eorg>, "text/p= lain@rfc-editor=2Eorg" <text/plain@rfc-editor=2Eorg>
Subject: RE: [Technical Errata Reported] RFC7714 (4938)

Paul,
I saw the email with what looks like this=
 direction but maybe the new text should mention as a note that since this =
was not specified before there may be few implementations that added paddin=
g on the other side=2E
Roni Even
As individual

 -----Original Message-----
=
 From: Paul E=2E Jones [mailto:paulej@packetizer=2Ecom]
 Sent: =D7=99=
=D7=95=D7=9D =D7=94 16 =D7=A4=D7=91=D7=A8=D7=95=D7=90=D7=A8 2017 23:45=

 To: RFC Errata System; mcgrew@cisco=2Ecom; mythicalkevin@yahoo=2Ecom=
;
 ben@nostrum=2Ecom; alissa@cooperw=2Ein; aamelnikov@fastmail=2Efm; R=
oni Even;
 magnus=2Ewesterlund@ericsson=2Ecom
 Cc: avt@ietf=2Eorg=
; text/plain@rfc-editor=2Eorg
 Subject: Re: [Technical Errata Reported=
] RFC7714 (4938)
 
 Since this issue needs closure in order to en=
sure that we have interoperable
 solutions, it would be good to have c=
onfirmation / agreement on the
 proposed change=2E
 
 Paul 
 ------ Original Message ------
 From: "RFC Errata Sys=
tem" <rfc-editor@rfc-editor=2Eorg>
 To: mcgrew@cisco=2Ecom;=
 mythicalkevin@yahoo=2Ecom; ben@nostrum=2Ecom;
 alissa@cooperw=2Ein; a=
amelnikov@fastmail=2Efm; roni=2Eeven@huawei=2Ecom;
 magnus=2Ewesterlun=
d@ericsson=2Ecom
 Cc: paulej@packetizer=2Ecom; avt@ietf=2Eorg; rfc-edi=
tor@rfc-editor=2Eorg Content-
 Type; text/plain@rfc-editor=2Eorg; ; ch=
arset=3DUTF-8@rfc-editor=2Eorg
 Sent: 2/16/2017 3:23:30 PM
 Subje=
ct: [Technical Errata Reported] RFC7714 (4938)
 
The following errata report has been submi=
tted for RFC7714, "AES-GCM
Authenticated Encryption in the Secure=
 Real-time Transport Protocol
(SRTP)"=2E


Y=
ou may review the report below and at:
http://www=2Erfc-e=
ditor=2Eorg/errata_search=2Ephp?rfc=3D7714&eid=3D4938


Type: Technical
Reported by: Paul E=2E Jones <paulej@pack=
etizer=2Ecom>

Section: 11

Original Text
-----=
--------
A Key Derivation Function (KDF) is used to derive all of the =
required
encryption and authentication keys from a secret value shared=
 by the
endpoints=2E  The AEAD_AES_128_GCM algorithm MUST use the (128=
-bit)
AES_CM PRF KDF described in [RFC3711]=2E  AEAD_AES_256_GCM MUST =
use
 the
AES_256_CM_PRF KDF described in [RFC6188]=2E

Corrected Tex=
t
--------------
A Key Derivation Function (KDF) is used to deriv=
e all of the required
encryption and authentication keys from a secret=
 value shared by the
endpoints=2E  The AEAD_AES_128_GCM algorithm MUST=
 use the (128-bit)
AES_CM PRF KDF described in [RFC3711]=2E  AEAD_AES_=
256_GCM MUST use
 the
AES_256_CM_PRF KDF described in [RFC6188]=2E  Since the =
KDF functions in
those RFCs assume as input a 112-bit master salt, the=
 96-bit master
salt specified in this document must be multiplied by 2=
^16 to form the
112-bit salt used as the master salt in those key deri=
vation functions=2E

Notes
-----
The salt specified in =
RFC 7714 is 96 bits in length, but intended for
use in KDF functions d=
efined in RFC 3711=2E  This led to different
interpretations when impl=
ementing this RFC=2E  A more complete
description was presented on the=
 avtcore mailing list
(https://mailarchive=2Eietf=2Eorg/arc=
h/msg/avt/IRfLuNKglD3qhqwSz3v3t0CG6fA
 )
and, after some dialog, there see=
med to be agreement to adopt the
approach most widely implemented
(https://mailarc=
hive=2Eietf=2Eorg/arch/msg/avt/-
 C1cIWQXpyzS2KfBjGR6=
B2kK92w)=2E
  This su=
ggested text is intended to reflect that agreement=2E  In
effect,
16 zero bits are padded to the right of the salt value  defined in RFC
7714 (creating a 112 bit salt value) before it is used as described inthe KDF functions defined in RFC 3711 that require a 112 bit salt
v=
alue=2E

Instructions:
-------------
This erratum is cu=
rrently posted as "Reported"=2E If necessary, please
use &qu=
ot;Reply All" to discuss whether it should be verified or rejected=2E<=
br />When a decision is reached, the verifying party can log in to changethe status and edit the report, if necessary=2E


=
RFC7714 (draft-ietf-avtcore-srtp-aes-gcm-17)

Title        =
       : AES-GCM Authenticated Encryption in the Secure
Real-time Tran=
sport Protocol (SRTP)
Publication Date    : December 2015
Author(=
s)           : D=2E McGrew, K=2E Igoe
Category            : PROPOSED S=
TANDARD
Source              : Audio/Video Transport Core MaintenanceArea                : Applications and Real-Time
Stream           =
   : IETF
Verifying Party     : IESG
------QSRUG4JENTCMVSOIDHURID6FWMA9R7-- From nobody Mon Feb 20 01:46:59 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78086128B38 for ; Mon, 20 Feb 2017 01:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjQ9O7VzwBO2 for ; Mon, 20 Feb 2017 01:46:56 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 B4449129432 for ; Mon, 20 Feb 2017 01:46:55 -0800 (PST) X-AuditID: c1b4fb3a-b9bff700000021e0-99-58aabb0b4ae0 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id 72.A2.08672.B0BBAA85; Mon, 20 Feb 2017 10:46:53 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.3.319.2; Mon, 20 Feb 2017 10:46:51 +0100 To: Roni Even , "avt@ietf.org" References: <6E58094ECC8D8344914996DAD28F1CCD77527B@DGGEMM506-MBX.china.huawei.com> From: Magnus Westerlund Message-ID: <32ce8d94-303f-aa7e-545e-498b99cab0e5@ericsson.com> Date: Mon, 20 Feb 2017 10:46:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD77527B@DGGEMM506-MBX.china.huawei.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUyM2K7qC7v7lURBp+/y1u87FnJbvHp2HkW ByaPliNvWT2WLPnJFMAUxWWTkpqTWZZapG+XwJUxryO8oFG4om3tXKYGxlb+LkZODgkBE4nz y7azdjFycQgJrGOUWPmkgwXCWc4osW/nayaQKmEBXYkdS94zdzFycIgIOEtcWR0BEhYSCJaY fn0DI4jNJmAhcfNHIxuIzStgL/FsaSM7iM0ioCpxbU0P2BhRgRiJvf33mSBqBCVOznzCAmJz CoRIXNp9gBVkPDNQ74OtZSBhZgF5ieats5khVmlLNDR1sE5g5J+FpHsWQscsJB0LGJlXMYoW pxYX56YbGemlFmUmFxfn5+nlpZZsYgQG3sEtv612MB587niIUYCDUYmH98OmlRFCrIllxZW5 hxglOJiVRHg/L18VIcSbklhZlVqUH19UmpNafIhRmoNFSZzXbOX9cCGB9MSS1OzU1ILUIpgs EwenVAPj6rZd91dlrNQOfJn9Z4vumxRFkdSdy73WMT60jpuwvjKEWzKMX/XeiXnaM1L3BE/+ fOHf9A3COzXfPRSxm782Km9vlb1Q6EYJn8K+g0vL7F8t1F6nevSJdFTxMaGJ7neusJqL3om3 fLQo4IHIfNNypcvuV0KOuPP7zGaw8zA69VbiXKjnC11VJZbijERDLeai4kQAL7DEvDgCAAA= Archived-At: Subject: Re: [AVTCORE] RFC5285bis open issues X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 09:46:57 -0000 Hi, Personal opinions, not responding as WG chair and doc shepherd. Den 2017-02-19 kl. 16:06, skrev Roni Even: > Hi, > > Based on the email discussion I see some issues that need conclusion > > > > 1. For the one-byte RTP header extension if id=0 and len>0 what > action to take since there is no current text > > a. This is also padding > > b. This is an error so stop interpreting following header > extensions – similar to id=15 > From my perspective, RFC 5285 is very clear that padding is a byte with value 0, i.e. all 8 bits are zero. Also, sending for example 0x04 is very undefined and a sender could expect b) option response from the receiver. Without agreed interpretation I rather send a clear message, don't use this. Thus, I would favour option b). > 2. Can we conclude from RFC5285 that if only IDs between 1-14 are > offered it means that only one-byte RTP header extension are supported? > I think I have been involved in discussion about this previously. The conclusion I remember is that it is not possible. It is allowed to negotiate IDs below 16 and still use the two-byte header format for a particular RTP stream. So, it is not a conclusion we can draw. However, the reality was that until we created the SDES header extension we didn't have any header extension that had the possibility to be more than 16 bytes. At least if I remember correctly how the definition of the various registered header extensions. http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-10 But, there could exist proprietary header extensions that are longer. So, not guaranteed, but a fairly safe bet assuming no header extensions that are known to allow longer than 16 bytes. But, I think one has to make it clear that there are no guarantees, but one could write a guideline for a case that is likely to work. 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 Sat Feb 25 23:30:58 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF57A12950F for ; Sat, 25 Feb 2017 23:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PElk3aZAUBZ for ; Sat, 25 Feb 2017 23:30:55 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A06CE12949B for ; Sat, 25 Feb 2017 23:30:54 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DBS50104; Sun, 26 Feb 2017 07:30:52 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 26 Feb 2017 07:30:51 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0301.000; Sun, 26 Feb 2017 15:30:47 +0800 From: Roni Even To: Magnus Westerlund , "avt@ietf.org" Thread-Topic: [AVTCORE] RFC5285bis open issues Thread-Index: AdKKwXPucrb9jW2aSFCqJMwiTJKcvwAWcAQAATmFG5A= Date: Sun, 26 Feb 2017 07:30:47 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD776977@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD77527B@DGGEMM506-MBX.china.huawei.com> <32ce8d94-303f-aa7e-545e-498b99cab0e5@ericsson.com> In-Reply-To: <32ce8d94-303f-aa7e-545e-498b99cab0e5@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.58B2842D.000D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6d98b49ef9d4efaf89411814b1537c4b Archived-At: Subject: Re: [AVTCORE] RFC5285bis open issues X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 07:30:56 -0000 SGkgTWFnbnVzLA0KVGhhbmtzLA0KSSB3aWxsIGFkZCB0aGUgdGV4dCBhYm91dCB0aGUgaWQ9MCBs ZW4+MCB1c2luZyBvcHRpb24gYg0KDQpBcyBmb3Igc3VwcG9ydCBmb3Igb25lLWJ5dGUgb25seSBJ IHRoaW5rIHRoYXQgc2luY2Ugc2VjdGlvbiA0LjEuMiBzYXlzICIgdGhlIG9uZS1ieXRlIGhlYWRl ciBmb3JtIGlzIHByZWZlcnJlZCBhbmQgTVVTVCBiZSBzdXBwb3J0ZWQgYnkNCiAgIGFsbCByZWNl aXZlcnMiIGl0IHByb3ZpZGVzIGd1aWRlbGluZSB0byB1c2Ugb25lLWJ5dGUgc2F5aW5nIHRoYXQg b25lLWJ5dGUgd2lsbCB3b3JrIGJ1dCB0d28tYnl0ZXMgbWF5IG5vdC4gRG8geW91IGhhdmUgYW5v dGhlciBwcm9wb3NlZCB0ZXh0IHRvIGFkZHJlc3MgdGhpcyBwb2ludD8NCg0KUm9uaQ0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1hZ251cyBXZXN0ZXJsdW5kIFttYWls dG86bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tXQ0KPiBTZW50OiDXmdeV153CoNeRIDIw INek15HXqNeV15DXqCAyMDE3IDExOjQ3DQo+IFRvOiBSb25pIEV2ZW47IGF2dEBpZXRmLm9yZw0K PiBTdWJqZWN0OiBSZTogW0FWVENPUkVdIFJGQzUyODViaXMgb3BlbiBpc3N1ZXMNCj4gDQo+IEhp LA0KPiANCj4gUGVyc29uYWwgb3BpbmlvbnMsIG5vdCByZXNwb25kaW5nIGFzIFdHIGNoYWlyIGFu ZCBkb2Mgc2hlcGhlcmQuDQo+IA0KPiBEZW4gMjAxNy0wMi0xOSBrbC4gMTY6MDYsIHNrcmV2IFJv bmkgRXZlbjoNCj4gPiBIaSwNCj4gPg0KPiA+IEJhc2VkIG9uIHRoZSBlbWFpbCBkaXNjdXNzaW9u IEkgc2VlIHNvbWUgaXNzdWVzIHRoYXQgbmVlZCBjb25jbHVzaW9uDQo+ID4NCj4gPg0KPiA+DQo+ ID4gMS4gICAgICAgRm9yIHRoZSBvbmUtYnl0ZSBSVFAgaGVhZGVyIGV4dGVuc2lvbiBpZiBpZD0w IGFuZCBsZW4+MCB3aGF0DQo+ID4gYWN0aW9uIHRvIHRha2Ugc2luY2UgdGhlcmUgaXMgbm8gY3Vy cmVudCB0ZXh0DQo+ID4NCj4gPiBhLiAgICAgICBUaGlzIGlzIGFsc28gcGFkZGluZw0KPiA+DQo+ ID4gYi4gICAgICBUaGlzIGlzIGFuIGVycm9yIHNvIHN0b3AgaW50ZXJwcmV0aW5nIGZvbGxvd2lu ZyBoZWFkZXINCj4gPiBleHRlbnNpb25zIOKAkyBzaW1pbGFyIHRvIGlkPTE1DQo+ID4NCj4gDQo+ ICBGcm9tIG15IHBlcnNwZWN0aXZlLCBSRkMgNTI4NSBpcyB2ZXJ5IGNsZWFyIHRoYXQgcGFkZGlu ZyBpcyBhIGJ5dGUgd2l0aCB2YWx1ZQ0KPiAwLCBpLmUuIGFsbCA4ICBiaXRzIGFyZSB6ZXJvLiBB bHNvLCBzZW5kaW5nIGZvciBleGFtcGxlIDB4MDQgaXMgdmVyeSB1bmRlZmluZWQNCj4gYW5kIGEg c2VuZGVyIGNvdWxkIGV4cGVjdCBiKSBvcHRpb24gcmVzcG9uc2UgZnJvbSB0aGUgcmVjZWl2ZXIu IFdpdGhvdXQNCj4gYWdyZWVkIGludGVycHJldGF0aW9uIEkgcmF0aGVyIHNlbmQgYSBjbGVhciBt ZXNzYWdlLCBkb24ndCB1c2UgdGhpcy4gVGh1cywgSQ0KPiB3b3VsZCBmYXZvdXIgb3B0aW9uIGIp Lg0KPiANCj4gDQo+ID4gMi4gICAgICAgQ2FuIHdlIGNvbmNsdWRlIGZyb20gUkZDNTI4NSB0aGF0 IGlmIG9ubHkgSURzIGJldHdlZW4gMS0xNCBhcmUNCj4gPiBvZmZlcmVkIGl0IG1lYW5zIHRoYXQg b25seSBvbmUtYnl0ZSBSVFAgaGVhZGVyIGV4dGVuc2lvbiBhcmUgc3VwcG9ydGVkPw0KPiA+DQo+ IA0KPiBJIHRoaW5rIEkgaGF2ZSBiZWVuIGludm9sdmVkIGluIGRpc2N1c3Npb24gYWJvdXQgdGhp cyBwcmV2aW91c2x5LiBUaGUNCj4gY29uY2x1c2lvbiBJIHJlbWVtYmVyIGlzIHRoYXQgaXQgaXMg bm90IHBvc3NpYmxlLiBJdCBpcyBhbGxvd2VkIHRvIG5lZ290aWF0ZSBJRHMNCj4gYmVsb3cgMTYg YW5kIHN0aWxsIHVzZSB0aGUgdHdvLWJ5dGUgaGVhZGVyIGZvcm1hdCBmb3IgYSBwYXJ0aWN1bGFy IFJUUA0KPiBzdHJlYW0uIFNvLCBpdCBpcyBub3QgYSBjb25jbHVzaW9uIHdlIGNhbiBkcmF3Lg0K PiANCj4gSG93ZXZlciwgdGhlIHJlYWxpdHkgd2FzIHRoYXQgdW50aWwgd2UgY3JlYXRlZCB0aGUg U0RFUyBoZWFkZXIgZXh0ZW5zaW9uDQo+IHdlIGRpZG4ndCBoYXZlIGFueSBoZWFkZXIgZXh0ZW5z aW9uIHRoYXQgaGFkIHRoZSBwb3NzaWJpbGl0eSB0byBiZSBtb3JlIHRoYW4NCj4gMTYgYnl0ZXMu DQo+IA0KPiBBdCBsZWFzdCBpZiBJIHJlbWVtYmVyIGNvcnJlY3RseSBob3cgdGhlIGRlZmluaXRp b24gb2YgdGhlIHZhcmlvdXMgcmVnaXN0ZXJlZA0KPiBoZWFkZXIgZXh0ZW5zaW9ucy4NCj4gaHR0 cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9ydHAtcGFyYW1ldGVycy9ydHAtDQo+IHBhcmFt ZXRlcnMueGh0bWwjcnRwLXBhcmFtZXRlcnMtMTANCj4gDQo+IEJ1dCwgdGhlcmUgY291bGQgZXhp c3QgcHJvcHJpZXRhcnkgaGVhZGVyIGV4dGVuc2lvbnMgdGhhdCBhcmUgbG9uZ2VyLg0KPiANCj4g U28sIG5vdCBndWFyYW50ZWVkLCBidXQgYSBmYWlybHkgc2FmZSBiZXQgYXNzdW1pbmcgbm8gaGVh ZGVyIGV4dGVuc2lvbnMgdGhhdA0KPiBhcmUga25vd24gdG8gYWxsb3cgbG9uZ2VyIHRoYW4gMTYg Ynl0ZXMuIEJ1dCwgSSB0aGluayBvbmUgaGFzIHRvIG1ha2UgaXQgY2xlYXINCj4gdGhhdCB0aGVy ZSBhcmUgbm8gZ3VhcmFudGVlcywgYnV0IG9uZSBjb3VsZCB3cml0ZSBhIGd1aWRlbGluZSBmb3Ig YSBjYXNlIHRoYXQNCj4gaXMgbGlrZWx5IHRvIHdvcmsuDQo+IA0KPiBDaGVlcnMNCj4gDQo+IE1h Z251cyBXZXN0ZXJsdW5kDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFNlcnZpY2VzLCBNZWRpYSBh bmQgTmV0d29yayBmZWF0dXJlcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RYTQ0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IEVyaWNzc29uIEFCICAgICAgICAgICAgICAgICB8IFBob25lICArNDYgMTAgNzE0 ODI4Nw0KPiBGw6Ryw7ZnYXRhbiA2ICAgICAgICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0 OTA3OQ0KPiBTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4gfCBtYWlsdG86IG1hZ251cy53ZXN0 ZXJsdW5kQGVyaWNzc29uLmNvbQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg== From nobody Sun Feb 26 00:02:35 2017 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D49012953E; Sun, 26 Feb 2017 00:02:27 -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: 6.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148809614711.12583.3417548154950251283.idtracker@ietfa.amsl.com> Date: Sun, 26 Feb 2017 00:02:27 -0800 Archived-At: Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rfc5285-bis-07.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 08:02:27 -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 Core Maintenance of the IETF. Title : A General Mechanism for RTP Header Extensions Authors : Roni Even David Singer Harikishan Desineni Filename : draft-ietf-avtcore-rfc5285-bis-07.txt Pages : 22 Date : 2017-02-25 Abstract: This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session. This document obsoletes RFC5285. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtcore-rfc5285-bis-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rfc5285-bis-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 Sun Feb 26 22:23:30 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7A71296C3; Sun, 26 Feb 2017 22:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTjJUD0Zi5QO; Sun, 26 Feb 2017 22:23:27 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80C06129665; Sun, 26 Feb 2017 22:23:26 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DBT61246; Mon, 27 Feb 2017 06:23:23 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 27 Feb 2017 06:23:21 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0301.000; Mon, 27 Feb 2017 14:23:13 +0800 From: Roni Even To: "avt@ietf.org" Thread-Topic: request for agenda time - IETF98 Thread-Index: AdKQwYooY0mvwOw+RUyvSbWulhs2Dw== Date: Mon, 27 Feb 2017 06:23:13 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD776B6C@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.150] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD776B6CDGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0204.58B3C5DC.006E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: aa3b6eeb01c923fd58f4043a1033a58d Archived-At: Cc: "avtcore-chairs@ietf.org" , "avtext-chairs@ietf.org" Subject: [AVTCORE] request for agenda time - IETF98 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 06:23:29 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD776B6CDGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The AVTcore (or the merged AVT) WG is scheduled to meet on Tuesday March 28= th 2017 from 9:00 in Zurich A If you want to present in this time slot please send us an email Note: this is still the preliminary agenda see https://datatracker.ietf.org= /meeting/agenda/ Roni Even AVTCore co-chair --_000_6E58094ECC8D8344914996DAD28F1CCD776B6CDGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

The AVTcore (or the merged AVT) WG is scheduled to m= eet on Tuesday March 28th 2017 from 9:00 in Zurich A<= /p>

If you want to present in this time slot please send= us an email

 

Note: this is still the preliminary agenda see https://datatracker.ietf.org/meeting/agenda/

 

Roni Even

AVTCore co-chair

--_000_6E58094ECC8D8344914996DAD28F1CCD776B6CDGGEMM506MBXchina_-- From nobody Mon Feb 27 02:24:47 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A681129D18 for ; Mon, 27 Feb 2017 02:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuOmB-rPKasV for ; Mon, 27 Feb 2017 02:24:43 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 1974C12943D for ; Mon, 27 Feb 2017 02:24:42 -0800 (PST) X-AuditID: c1b4fb3a-ae2b298000007c1e-4b-58b3fe68bf9d Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id 29.7A.31774.86EF3B85; Mon, 27 Feb 2017 11:24:41 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.3.319.2; Mon, 27 Feb 2017 11:24:38 +0100 To: Roni Even , "avt@ietf.org" References: <6E58094ECC8D8344914996DAD28F1CCD77527B@DGGEMM506-MBX.china.huawei.com> <32ce8d94-303f-aa7e-545e-498b99cab0e5@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD776977@DGGEMM506-MBX.china.huawei.com> From: Magnus Westerlund Message-ID: <72bbcfb0-d9fa-3703-b100-82821973f2db@ericsson.com> Date: Mon, 27 Feb 2017 11:24:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD776977@DGGEMM506-MBX.china.huawei.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyM2K7gW7mv80RBrMW81q87FnJbvHp2HkW ByaPliNvWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXx7N0P9oLZghWT3uxla2Bs5u1i5OSQEDCR uLJ+NXMXIxeHkMA6Rol/v5eyQzjLGSW+Tf7NCFIlLKArsWPJe6AqDg4RAWeJK6sjIGouM0ps aGtkBqlhE7CQuPmjkQ2khlfAXmLJ81yQMIuAqkTz71VgJaICMRJ7++8zgdi8AoISJ2c+YQGx OQVCJG5d/AlWwww0Zub884wQtrxE89bZYHEhAW2JhqYO1gmM/LOQtM9C0jILScsCRuZVjKLF qcXFuelGRnqpRZnJxcX5eXp5qSWbGIHhd3DLb6sdjAefOx5iFOBgVOLh/RC7OUKINbGsuDL3 EKMEB7OSCG/LN6AQb0piZVVqUX58UWlOavEhRmkOFiVxXrOV98OFBNITS1KzU1MLUotgskwc nFINjH3ar8VTHycpCjNfLJGTb5Jx5uhvT1D1Uv088XWS78Ii58J6GQ2R2AO265d+PFl42+/y 0pXee+O+HXz9TETo+N7Q6qlboxoOMC7i2dYZ9yiijdX8Yrt87oeDHst9hQ16zy5oervk4e6/ U4yYu/1FNx6qqHV4fev1iWaRv6e0JfrWh9VxTJhpr8RSnJFoqMVcVJwIAEvGN1I7AgAA Archived-At: Subject: Re: [AVTCORE] RFC5285bis open issues X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 10:24:46 -0000 Den 2017-02-26 kl. 08:30, skrev Roni Even: > Hi Magnus, > Thanks, > I will add the text about the id=0 len>0 using option b > Regarding this text: Each distinct extension MUST have a unique ID. The value 0 is reserved for padding and MUST NOT be used as a local identifier. an extension element with a value equal 0 MUST NOT have len greater than 0. If such an extension element is encountered, its length field MUST be ignored, processing of the entire extension MUST terminate at that point, and only the extension elements present prior to the element with ID 0 and len greater than 0 SHOULD be considered. I think it could be improved to make it clearer, thus I suggest the following changed: Each distinct extension MUST have a unique ID. The ID value 0 is reserved for padding and MUST NOT be used as a ^^ local identifier. An extension element with an ID value equal 0 MUST NOT have len ^ ^^^^ greater than 0. If such an extension element is encountered, its length field MUST be ignored, processing of the entire extension MUST terminate at that point, and only the extension elements present prior to the element with ID 0 and len greater than 0 SHOULD be considered. > As for support for one-byte only I think that since section 4.1.2 says " the one-byte header form is preferred and MUST be supported by > all receivers" it provides guideline to use one-byte saying that one-byte will work but two-bytes may not. Do you have another proposed text to address this point? No, I don't have any suggestion for improving that text. 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 Mon Feb 27 03:18:34 2017 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C58129AAF; Mon, 27 Feb 2017 03:18:29 -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: 6.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148819430940.21165.7518484053316276835.idtracker@ietfa.amsl.com> Date: Mon, 27 Feb 2017 03:18:29 -0800 Archived-At: Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rfc5285-bis-08.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 11:18:29 -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 Core Maintenance of the IETF. Title : A General Mechanism for RTP Header Extensions Authors : Roni Even David Singer Harikishan Desineni Filename : draft-ietf-avtcore-rfc5285-bis-08.txt Pages : 22 Date : 2017-02-27 Abstract: This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session. This document obsoletes RFC5285. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtcore-rfc5285-bis-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rfc5285-bis-08 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 Feb 27 03:23:20 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CFC129DB5 for ; Mon, 27 Feb 2017 03:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnP9MR0ns32x for ; Mon, 27 Feb 2017 03:23:17 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C02B1129D97 for ; Mon, 27 Feb 2017 03:23:16 -0800 (PST) Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DHV48341; Mon, 27 Feb 2017 11:23:14 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 27 Feb 2017 11:23:12 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0301.000; Mon, 27 Feb 2017 19:23:09 +0800 From: Roni Even To: Magnus Westerlund , "avt@ietf.org" Thread-Topic: [AVTCORE] RFC5285bis open issues Thread-Index: AQHSkOO8T4Ara+XzL0CQ1mYMYo03CaF8tM4w Date: Mon, 27 Feb 2017 11:23:08 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD776C26@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD77527B@DGGEMM506-MBX.china.huawei.com> <32ce8d94-303f-aa7e-545e-498b99cab0e5@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD776977@DGGEMM506-MBX.china.huawei.com> <72bbcfb0-d9fa-3703-b100-82821973f2db@ericsson.com> In-Reply-To: <72bbcfb0-d9fa-3703-b100-82821973f2db@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.58B40C22.025D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1a884eedc42f5868ef897fac54033c72 Archived-At: Subject: Re: [AVTCORE] RFC5285bis open issues X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 11:23:18 -0000 SGkgTWFnbnVzLA0KU3VibWl0dGVkIDA4IHZlcnNpb24gd2l0aCB5b3VyIGNoYW5nZXMuDQpJIHRo aW5rIHRoaXMgdmVyc2lvbiBhZGRyZXNzZXMgdGhlIFdHTEMgY29tbWVudHMuDQpSb25pDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFnbnVzIFdlc3Rlcmx1bmQgW21h aWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb21dDQo+IFNlbnQ6INeZ15XXncKg15Eg Mjcg16TXkdeo15XXkNeoIDIwMTcgMTI6MjUNCj4gVG86IFJvbmkgRXZlbjsgYXZ0QGlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBbQVZUQ09SRV0gUkZDNTI4NWJpcyBvcGVuIGlzc3Vlcw0KPiANCj4g RGVuIDIwMTctMDItMjYga2wuIDA4OjMwLCBza3JldiBSb25pIEV2ZW46DQo+ID4gSGkgTWFnbnVz LA0KPiA+IFRoYW5rcywNCj4gPiBJIHdpbGwgYWRkIHRoZSB0ZXh0IGFib3V0IHRoZSBpZD0wIGxl bj4wIHVzaW5nIG9wdGlvbiBiDQo+ID4NCj4gDQo+IFJlZ2FyZGluZyB0aGlzIHRleHQ6DQo+IA0K PiAgICAgRWFjaCBkaXN0aW5jdCBleHRlbnNpb24gTVVTVCBoYXZlIGEgdW5pcXVlIElELg0KPiAg ICAgVGhlIHZhbHVlIDAgaXMgcmVzZXJ2ZWQgZm9yIHBhZGRpbmcgYW5kIE1VU1QgTk9UIGJlIHVz ZWQgYXMgYSBsb2NhbA0KPiAgICAgaWRlbnRpZmllci4NCj4gDQo+ICAgICBhbiBleHRlbnNpb24g ZWxlbWVudCB3aXRoIGEgdmFsdWUgZXF1YWwgMCBNVVNUIE5PVCBoYXZlIGxlbiBncmVhdGVyDQo+ ICAgICB0aGFuIDAuICBJZiBzdWNoIGFuIGV4dGVuc2lvbiBlbGVtZW50IGlzIGVuY291bnRlcmVk LCBpdHMgbGVuZ3RoDQo+ICAgICBmaWVsZCBNVVNUIGJlIGlnbm9yZWQsIHByb2Nlc3Npbmcgb2Yg dGhlIGVudGlyZSBleHRlbnNpb24gTVVTVA0KPiAgICAgdGVybWluYXRlIGF0IHRoYXQgcG9pbnQs IGFuZCBvbmx5IHRoZSBleHRlbnNpb24gZWxlbWVudHMgcHJlc2VudA0KPiAgICAgcHJpb3IgdG8g dGhlIGVsZW1lbnQgd2l0aCBJRCAwIGFuZCBsZW4gZ3JlYXRlciB0aGFuIDAgU0hPVUxEIGJlDQo+ ICAgICBjb25zaWRlcmVkLg0KPiANCj4gSSB0aGluayBpdCBjb3VsZCBiZSBpbXByb3ZlZCB0byBt YWtlIGl0IGNsZWFyZXIsIHRodXMgSSBzdWdnZXN0IHRoZSBmb2xsb3dpbmcNCj4gY2hhbmdlZDoN Cj4gDQo+ICAgICBFYWNoIGRpc3RpbmN0IGV4dGVuc2lvbiBNVVNUIGhhdmUgYSB1bmlxdWUgSUQu DQo+ICAgICBUaGUgSUQgdmFsdWUgMCBpcyByZXNlcnZlZCBmb3IgcGFkZGluZyBhbmQgTVVTVCBO T1QgYmUgdXNlZCBhcyBhDQo+ICAgICAgICAgXl4NCj4gICAgIGxvY2FsIGlkZW50aWZpZXIuDQo+ IA0KPiAgICAgQW4gZXh0ZW5zaW9uIGVsZW1lbnQgd2l0aCBhbiBJRCB2YWx1ZSBlcXVhbCAwIE1V U1QgTk9UIGhhdmUgbGVuDQo+ICAgICBeICAgICAgICAgICAgICAgICAgICAgICAgICBeXl5eDQo+ ICAgICBncmVhdGVyDQo+ICAgICB0aGFuIDAuICBJZiBzdWNoIGFuIGV4dGVuc2lvbiBlbGVtZW50 IGlzIGVuY291bnRlcmVkLCBpdHMgbGVuZ3RoDQo+ICAgICBmaWVsZCBNVVNUIGJlIGlnbm9yZWQs IHByb2Nlc3Npbmcgb2YgdGhlIGVudGlyZSBleHRlbnNpb24gTVVTVA0KPiAgICAgdGVybWluYXRl IGF0IHRoYXQgcG9pbnQsIGFuZCBvbmx5IHRoZSBleHRlbnNpb24gZWxlbWVudHMgcHJlc2VudA0K PiAgICAgcHJpb3IgdG8gdGhlIGVsZW1lbnQgd2l0aCBJRCAwIGFuZCBsZW4gZ3JlYXRlciB0aGFu IDAgU0hPVUxEIGJlDQo+ICAgICBjb25zaWRlcmVkLg0KPiANCj4gDQo+IA0KPiA+IEFzIGZvciBz dXBwb3J0IGZvciBvbmUtYnl0ZSBvbmx5IEkgdGhpbmsgdGhhdCBzaW5jZSBzZWN0aW9uIDQuMS4y IHNheXMgIiB0aGUNCj4gb25lLWJ5dGUgaGVhZGVyIGZvcm0gaXMgcHJlZmVycmVkIGFuZCBNVVNU IGJlIHN1cHBvcnRlZCBieQ0KPiA+ICAgIGFsbCByZWNlaXZlcnMiIGl0IHByb3ZpZGVzIGd1aWRl bGluZSB0byB1c2Ugb25lLWJ5dGUgc2F5aW5nIHRoYXQgb25lLWJ5dGUNCj4gd2lsbCB3b3JrIGJ1 dCB0d28tYnl0ZXMgbWF5IG5vdC4gRG8geW91IGhhdmUgYW5vdGhlciBwcm9wb3NlZCB0ZXh0IHRv DQo+IGFkZHJlc3MgdGhpcyBwb2ludD8NCj4gDQo+IE5vLCBJIGRvbid0IGhhdmUgYW55IHN1Z2dl c3Rpb24gZm9yIGltcHJvdmluZyB0aGF0IHRleHQuDQo+IA0KPiBDaGVlcnMNCj4gDQo+IE1hZ251 cyBXZXN0ZXJsdW5kDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFNlcnZpY2VzLCBNZWRpYSBhbmQg TmV0d29yayBmZWF0dXJlcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RYTQ0KPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+IEVyaWNzc29uIEFCICAgICAgICAgICAgICAgICB8IFBob25lICArNDYgMTAgNzE0ODI4 Nw0KPiBGw6Ryw7ZnYXRhbiA2ICAgICAgICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3 OQ0KPiBTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4gfCBtYWlsdG86IG1hZ251cy53ZXN0ZXJs dW5kQGVyaWNzc29uLmNvbQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg== From nobody Mon Feb 27 05:48:09 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A68A129FAC for ; Mon, 27 Feb 2017 05:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhDEyI6frx5n for ; Mon, 27 Feb 2017 05:48:06 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 B1DB1129FA6 for ; Mon, 27 Feb 2017 05:48:05 -0800 (PST) X-AuditID: c1b4fb3a-ae2b298000007c1e-28-58b42e13ef85 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id 32.47.31774.31E24B85; Mon, 27 Feb 2017 14:48:03 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.319.2; Mon, 27 Feb 2017 14:48:00 +0100 To: IETF AVTCore WG From: Magnus Westerlund Message-ID: <5e4a567f-622f-ce0e-8715-1bf359726ed4@ericsson.com> Date: Mon, 27 Feb 2017 14:48:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmluLIzCtJLcpLzFFi42KZGbFdS1dYb0uEwcNjJhYve1ayOzB6LFny kymAMYrLJiU1J7MstUjfLoEr48Nkj4LXXBXntrxhb2B8y9HFyMkhIWAisfzveXYQW0hgHaPE zdPlXYxcQPZyRolPSw+xgiREBJQkdkzaxgxiswlYSNz80cgGYgsLuErMe7EezOYVsJe4unMS WA2LgKpEw/GnYHFRgRiJvf33mSBqBCVOznzC0sXIwcEMVP9gaxlImFlAXqJ562xmiBu0JRqa OlgnMPLOQtIxC6FjFpKOBYzMqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjECg+bglt9WOxgP Pnc8xCjAwajEw/shdnOEEGtiWXFl7iFGCQ5mJRHer9pbIoR4UxIrq1KL8uOLSnNSiw8xSnOw KInzmq28Hy4kkJ5YkpqdmlqQWgSTZeLglGpglPPPO/de/+rEH/MfLlnsZXL6pe2CqUvZbry5 +bSQYZr1k/VL3l/+GbXvoqmn6sz1zPe28956c1uyJvbF4gsVkzlClqS5v6zKClMze3NR4+i6 3CVWLTNbPfRfTK4PCThxbPvKv1NVfk7tcVt/Q3bBkwva+0QEvl8I0Jr2saU96/5CZS99k52h 34KUWIozEg21mIuKEwGlD2yBFgIAAA== Archived-At: Subject: [AVTCORE] WG Last call on updates in draft-ietf-avtcore-rfc5285-bis-08 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 13:48:07 -0000 WG, This starts a one week WG last call (until the 6th of March) on the changes that came as a result of the WG LC reviews. Thanks to Colin Perkins, Dale Worley and Paul Kyzivat that provided comments. My reading is that this version should address the issues raised, with one exception. What hasn't resulted in changes is Dale's request for additional guidelines on the choice of one or two byte header format when the new flag is not signalled. The discussion do indicates that it is difficult to draw clear conclusions in that case if one intendes to use 2-byte headers. I do request that you all review if it does address the issues and don't introduce additional issues. Diff between -05 (WG LC version) and current version at the start of this call: https://www.ietf.org/rfcdiff?url1=draft-ietf-avtcore-rfc5285-bis-05&url2=draft-ietf-avtcore-rfc5285-bis-08 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 Mon Feb 27 09:32:12 2017 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C9612A2A3; Mon, 27 Feb 2017 09:32:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148821672663.21085.6087469686956970523.idtracker@ietfa.amsl.com> Date: Mon, 27 Feb 2017 09:32:06 -0800 Archived-At: Cc: avtcore-chairs@ietf.org, avt@ietf.org Subject: [AVTCORE] Spencer Dawkins' Yes on charter-ietf-avtcore-01-00: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 17:32:06 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-avtcore-01-00: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-avtcore/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please note that I'm a Yes, but no ART AD has balloted Yes at this time. From nobody Mon Feb 27 15:10:32 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474C9129452 for ; Mon, 27 Feb 2017 15:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgIlTUm1nQXY for ; Mon, 27 Feb 2017 15:10:27 -0800 (PST) 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 7B5F412944A for ; Mon, 27 Feb 2017 15:10:27 -0800 (PST) Received: from [81.187.2.149] (port=33645 helo=[192.168.0.71]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1ciUQy-000507-I9; Mon, 27 Feb 2017 23:10:26 +0000 From: Colin Perkins Message-Id: <2DC67B2F-C248-42E0-8CFA-60FDD5B62558@csperkins.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_386B9192-C25E-4F8F-AF40-E407C6D6E30C" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 27 Feb 2017 23:10:18 +0000 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD76B075@DGGEMM506-MBX.china.huawei.com> To: Roni Even References: <1413c1e1-ce44-def9-ee7b-1d07d63a9c87@ericsson.com> <7527A28C-77C5-4F35-8BB8-A57782FD1410@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD76B075@DGGEMM506-MBX.china.huawei.com> X-Mailer: Apple Mail (2.3259) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Cc: Magnus Westerlund , IETF AVTCore WG Subject: Re: [AVTCORE] WG Last Call for draft-ietf-avtcore-rfc5285-bis-05 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 23:10:30 -0000 --Apple-Mail=_386B9192-C25E-4F8F-AF40-E407C6D6E30C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Roni, Apologies for the slow reply =E2=80=93 the text you added in -06 to = address this looks good to me. Colin > On 2 Jan 2017, at 13:12, Roni Even wrote: >=20 > Hi Colin, > Your proposed text is better than the current text to reflect the = point that RTP header extension must not disrupt RTP interoperability = but may disrupt higher level interoperability, still maybe it will be = good to have some recommendation for the intermediaries to not discard = RTP headers automatically. Using SHOULD NOT implies that there may be a = reason for the intermediary to remove some of the header extensions. > There is also some text about it in RFC7667 section 4.7( = https://tools.ietf.org/html/rfc7667#section-4.7 = ). In the RTP mixer = case, I think that since the mixer generate new RTP and RTCP messages, = if the RTP mixer is aware of the received RTP header extensions, it will = be good if it can decide what to send in both the RTP and RTCP messages. = With regards to the text in RFC3550 =E2=80=9Cis designed so that the = header extension may be ignored by other interoperating implementations = that have not been extended=E2=80=9D, RFC 5285 adds the end to end = negotiation for the RTP header extensions supported by both ends so the = assumption is that if there is an RTP header extension than it is = understood by the RTP receiver (may even be an MCU or RTP SFM using the = audio level client to mixer RTP header extension ). > =20 > How about adding to your text > =20 > =E2=80=9CThe use of header extensions to > convey information that will, if missing, disrupt the behaviour of = a > higher layer application that builds on top of RTP is only = acceptable > if this doesn't affect interoperability at the RTP layer, still = intermediaries aware of the RTP header extensions are advised to be = cautious when removing or generating RTP header extensions see section = 4.7 of [RFC7667]=E2=80=9D > =20 > =20 > =20 > Roni > =20 > =20 > From: Colin Perkins > > Date: Wed, Dec 21, 2016 at 7:06 PM > Subject: Re: [AVTCORE] WG Last Call for = draft-ietf-avtcore-rfc5285-bis-05 > To: Magnus Westerlund > > Cc: IETF AVTCore WG > >=20 >=20 > > On 9 Dec 2016, at 10:49, Magnus Westerlund = > = wrote: > > > > This starts the 2 week WG last call (ending on the 23rd of December) = on A General Mechanism for RTP Header Extensions to proposed standard. > > > > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285-bis/ = > > > > This document is intended to obsolete RFC 5285 and has currently no = IPR declarations on it. >=20 > I=E2=80=99ve reviewed this document. In general, I think it's in = reasonable shape, although it could perhaps be better proof-read. = However, I think Section 4.1 needs more work before this is ready for = publication. >=20 > This section of the draft says: >=20 > This specification updates the requirement from the RTP = specification > that the header extension "is designed so that the header extension > MAY be ignored". To be specific, header extensions using this > specification SHOULD be used for data that can safely be ignored by > the recipient without affecting interoperability, there can be > essential header extensions for interoperability and intermediaries > SHOULD NOT remove such header extensions. Note that the support of > header extension as specified in this recommendation is negotiated. > RTP Header extensions MUST NOT be used when the presence of the > extension has changed the form or nature of the rest of the packet = in > a way that is not compatible with the way the stream is signaled > (e.g., as defined by the payload type). Valid examples might = include > metadata that is additional to the usual RTP information, e.g. = Audio > level from Client to mixer [RFC6464]. Note that some header > extensions, for example MID = [I-D.ietf-mmusic-sdp-bundle-negotiation] > might, if removed, disrupt the behaviour of the higher-level > application that builds on RTP, but are acceptable since they do = not > affect interoperability of the RTP stack itself. >=20 > This mis-quotes RFC 3550, and is hard to follow since it=E2=80=99s not = clear what types of extension can be ignored, and what it means to = affect interoperability if they are. I find the second sentence, in = particular, to be confusing. My suggested rewording is as follows: >=20 > The RTP specification [RFC3550] states that RTP =E2=80=9Cis = designed so > that the header extension may be ignored by other interoperating > implementations that have not been extended=E2=80=9D. The intent of = this > restriction is that RTP header extensions MUST NOT be used to > extend RTP itself in a manner that is backwards incompatible with > non-extended implementations. For example, a header extension is > not allowed to change the meaning or interpretation of the standard > RTP header fields, or of the RTCP Control Protocol (RTCP). Header > extensions MAY carry metadata in addition to the usual RTP header > information, provided the RTP layer can function if that metadata > is missing. For example, RTP header extensions can be used to carry > data that's also sent in RTCP, as an optimisation to lower latency, > since they'll fall back to the original, non-optimised, behaviour = if > the header extension is not present. The use of header extensions = to > convey information that will, if missing, disrupt the behaviour of = a > higher layer application that builds on top of RTP is only = acceptable > if this doesn't affect interoperability at the RTP layer. For > example, applications that use the SDP BUNDLE extension with the = MID > RTP header extension [I-D.ietf-mmusic-sdp-bundle-negotiation] to > correlate RTP streams with SDP m=3D lines likely won=E2=80=99t work = with full > functionality if the MID is missing, but the operation of the RTP > layer of those applications will be unaffected. >=20 > Note that I removed the text =E2=80=9Cintermediaries SHOULD NOT remove = such header extensions=E2=80=9D because certain types of intermediaries, = such as RTP mixers, have no choice but to remove RTP header extensions. = It might make sense to say instead that some types of intermediary = can=E2=80=99t be used if the higher layer protocol relies on header = extensions to carry metadata, since those intermediaries are = incompatible with header extensions. >=20 > Cheers, > Colin >=20 >=20 >=20 >=20 > -- > Colin Perkins > https://csperkins.org/ >=20 >=20 >=20 >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt = --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_386B9192-C25E-4F8F-AF40-E407C6D6E30C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Roni,

Apologies for the slow reply =E2=80=93 the text you added in = -06 to address this looks good to me.

Colin



On = 2 Jan 2017, at 13:12, Roni Even <roni.even@huawei.com> wrote:

Hi Colin,
Your proposed text is better than the = current text to reflect the point that RTP header extension must not = disrupt RTP interoperability but may disrupt higher level = interoperability, still maybe it will be good to have some = recommendation for the intermediaries to not discard RTP headers = automatically. Using SHOULD NOT implies that there may be a reason for = the intermediary to remove some of  the header extensions.
There is also some text about it in = RFC7667 section 4.7( https://tools.ietf.org/html/rfc7667#section-4.7 ). In the RTP mixer case, I = think that since the mixer generate new RTP and RTCP messages, if the = RTP mixer is aware of the received RTP header extensions, it will be = good if it can decide what to send in both the RTP and RTCP messages. =  With regards to the text in RFC3550 =E2=80=9Cis designed = so  that the header extension may be ignored by other = interoperating  implementations that have not been extended=E2=80=9D,= RFC 5285 adds the end to end negotiation for the RTP header extensions = supported by both ends so the assumption is that if there is an RTP = header extension than it is understood by the RTP receiver (may even be = an MCU or RTP SFM using the audio level client to mixer RTP header = extension ).
 
How about adding to your text
 
=E2=80=9CThe use of header extensions = to
   convey information that will, if missing, = disrupt the behaviour of a
   higher layer = application that builds on top of RTP is only acceptable
   if this doesn't affect interoperability at the = RTP layer, still intermediaries aware of the RTP header extensions are = advised to be cautious when removing or generating RTP header extensions = see section 4.7 of [RFC7667]=E2=80=9D
 
 
 
Roni
 
 
From: Colin = Perkins <csp@csperkins.org>
Date: Wed, Dec 21, 2016 at 7:06 PM
Subject: Re: = [AVTCORE] WG Last Call for draft-ietf-avtcore-rfc5285-bis-05
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Cc: IETF = AVTCore WG <avt@ietf.org>


> On 9 Dec 2016, at 10:49, = Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
>
> This starts the 2 week WG last call = (ending on the 23rd of December)  on A General Mechanism for RTP = Header Extensions to proposed standard.
>
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285-bis= /
>
> This document is intended to = obsolete RFC 5285 and has currently no IPR declarations on it.

I=E2=80=99ve reviewed this document. In = general, I think it's in reasonable shape, although it could perhaps be = better proof-read. However, I think Section 4.1 needs more work before = this is ready for publication.

This section = of the draft says:

   This = specification updates the requirement from the RTP specification
   that the header extension "is designed so that = the header extension
   MAY be ignored".  = To be specific, header extensions using this
  =  specification SHOULD be used for data that can safely be ignored = by
   the recipient without affecting = interoperability, there can be
   essential = header extensions for interoperability and intermediaries
   SHOULD NOT remove such header extensions.  = Note that the support of
   header extension as = specified in this recommendation is negotiated.
  =  RTP Header extensions MUST NOT be used when the presence of the
   extension has changed the form or nature of the = rest of the packet in
   a way that is not = compatible with the way the stream is signaled
  =  (e.g., as defined by the payload type).  Valid examples might = include
   metadata that is additional to the = usual RTP information, e.g.  Audio
   level = from Client to mixer [RFC6464].  Note that some header
   extensions, for example MID = [I-D.ietf-mmusic-sdp-bundle-negotiation]
  =  might, if removed, disrupt the behaviour of the higher-level
   application that builds on RTP, but are = acceptable since they do not
   affect = interoperability of the RTP stack itself.

This mis-quotes RFC 3550, and is hard to follow since it=E2=80=99= s not clear what types of extension can be ignored, and what it means to = affect interoperability if they are. I find the second sentence, in = particular, to be confusing. My suggested rewording is as follows:

   The RTP specification [RFC3550] = states that RTP =E2=80=9Cis designed so
   that = the header extension may be ignored by other interoperating
   implementations that have not been extended=E2=80=9D= . The intent of this
   restriction is that RTP = header extensions MUST NOT be used to
   extend = RTP itself in a manner that is backwards incompatible with
   non-extended implementations. For example, a = header extension is
   not allowed to change the = meaning or interpretation of the standard
   RTP = header fields, or of the RTCP Control Protocol (RTCP). Header
   extensions MAY carry metadata in addition to the = usual RTP header
   information, provided the = RTP layer can function if that metadata
   is = missing. For example, RTP header extensions can be used to carry
   data that's also sent in RTCP, as an = optimisation to lower latency,
   since they'll = fall back to the original, non-optimised, behaviour if
   the header extension is not present. The use of = header extensions to
   convey information that = will, if missing, disrupt the behaviour of a
  =  higher layer application that builds on top of RTP is only = acceptable
   if this doesn't affect = interoperability at the RTP layer. For
  =  example, applications that use the SDP BUNDLE extension with the = MID
   RTP header extension = [I-D.ietf-mmusic-sdp-bundle-negotiation] to
  =  correlate RTP streams with SDP m=3D lines likely won=E2=80=99t = work with full
   functionality if the MID is = missing, but the operation of the RTP
   layer = of those applications will be unaffected.

Note that I removed the text =E2=80=9Cintermediaries SHOULD = NOT remove such header extensions=E2=80=9D because certain types of = intermediaries, such as RTP mixers, have no choice but to remove RTP = header extensions. It might make sense to say instead that some types of = intermediary can=E2=80=99t be used if the higher layer protocol relies = on header extensions to carry metadata, since those intermediaries are = incompatible with header extensions.

Cheers,
Colin




--
Colin Perkins
https://csperkins.org/




_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt
=

=

-- 
Colin Perkins
https://csperkins.org/




= --Apple-Mail=_386B9192-C25E-4F8F-AF40-E407C6D6E30C-- From nobody Mon Feb 27 15:11:52 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FCA12946C for ; Mon, 27 Feb 2017 15:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvEbH3NhUbRg for ; Mon, 27 Feb 2017 15:11:46 -0800 (PST) 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 32960129470 for ; Mon, 27 Feb 2017 15:11:38 -0800 (PST) Received: from [81.187.2.149] (port=36515 helo=[192.168.0.71]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1ciUS8-0005CW-FP; Mon, 27 Feb 2017 23:11:36 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Colin Perkins In-Reply-To: <5e4a567f-622f-ce0e-8715-1bf359726ed4@ericsson.com> Date: Mon, 27 Feb 2017 23:11:35 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <38AACF5D-6A97-4518-8218-A7BB6C0493AA@csperkins.org> References: <5e4a567f-622f-ce0e-8715-1bf359726ed4@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.3259) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Cc: IETF AVTCore WG Subject: Re: [AVTCORE] WG Last call on updates in draft-ietf-avtcore-rfc5285-bis-08 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 23:11:47 -0000 > On 27 Feb 2017, at 13:48, Magnus Westerlund = wrote: >=20 > WG, >=20 > This starts a one week WG last call (until the 6th of March) on the = changes that came as a result of the WG LC reviews. Thanks to Colin = Perkins, Dale Worley and Paul Kyzivat that provided comments. >=20 > My reading is that this version should address the issues raised, with = one exception. What hasn't resulted in changes is Dale's request for = additional guidelines on the choice of one or two byte header format = when the new flag is not signalled. The discussion do indicates that it = is difficult to draw clear conclusions in that case if one intendes to = use 2-byte headers. >=20 > I do request that you all review if it does address the issues and = don't introduce additional issues. This version addresses my comments.=20 Thanks, Colin --=20 Colin Perkins https://csperkins.org/