Re: [AVTCORE] Need feedback on RFC5285bis (RTP header extensions) comments

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 01 February 2017 18:48 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 <avt@ietfa.amsl.com>; 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 <avt@ietfa.amsl.com>; 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 <avt@ietf.org>; 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 <roni.even@huawei.com>, IETF AVTCore WG <avt@ietf.org>
References: <6E58094ECC8D8344914996DAD28F1CCD770167@DGGEMM506-MBX.china.huawei.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <2f4e19a4-01ae-a056-b18b-6ad7669db3c2@alum.mit.edu>
Date: Wed, 01 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: <https://mailarchive.ietf.org/arch/msg/avt/ZCzhyY-nxMyzPViILv9nZAYmJ4s>
Cc: David Singer <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 <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=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