IETF Logo Mail Archive

Re: [Perc] Drop support for E2E RTP header extensions

Cullen Jennings <fluffy@iii.ca> Wed, 17 May 2017 20:20 UTC

Return-Path: <fluffy@iii.ca>
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874A31242F5 for <perc@ietfa.amsl.com>; Wed, 17 May 2017 13:20:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level:
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 SY8FsT2YI3S0 for <perc@ietfa.amsl.com>; Wed, 17 May 2017 13:20:58 -0700 (PDT)
Received: from smtp125.iad3a.emailsrvr.com (smtp125.iad3a.emailsrvr.com [173.203.187.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 CA88512441E for <perc@ietf.org>; Wed, 17 May 2017 13:20:57 -0700 (PDT)
Received: from smtp24.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp24.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id DCAFF24B15; Wed, 17 May 2017 16:20:51 -0400 (EDT)
X-Auth-ID: fluffy@iii.ca
Received: by smtp24.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id F15B324C75; Wed, 17 May 2017 16:20:50 -0400 (EDT)
X-Sender-Id: fluffy@iii.ca
Received: from [10.24.100.180] ([UNAVAILABLE]. [128.107.241.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Wed, 17 May 2017 16:20:51 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_3402C383-D8FC-46EC-AA78-34E08D5F3A71"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <emf5b957a9-56ec-4bf1-b8d7-2bd117d64769@sydney>
Date: Wed, 17 May 2017 10:20:48 -1000
Cc: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, perc@ietf.org
Message-Id: <30DD26D8-BAC5-4B10-86E0-7869A0BF365D@iii.ca>
References: <49c7de34-8bc6-bb7d-4524-0af26089eecb@gmail.com> <1CF6F66C-939F-484D-8C53-46ACB8CA69BE@vidyo.com> <27ca2993-5c66-8388-7187-b47ed8ae1340@gmail.com> <CAL02cgRDaz7BT+GzxWJ0cM7rebhd2cu2WbPy+Mwjkk0wJK=6mw@mail.gmail.com> <aef9a32f-f761-c9e8-de99-57c4acfd5088@gmail.com> <8FD07F5D-CD52-445B-AF75-BA1696F3A151@mozilla.com> <aff1a9bf-7dcb-71e6-3d01-afe5cac87ca5@gmail.com> <E234DDC1-9AB5-4C64-91C0-A8FCB58DA351@iii.ca> <8ddbf495-ac23-8529-aa0b-a233a0b336c0@gmail.com> <74BE8407-9AC0-45D3-9476-5C109A7B7A3C@iii.ca> <286A6294-EC1E-49D3-88BB-023178DB07BD@packetizer.com> <2810AD6C-0F45-41CC-BC6F-4303B5649CB0@iii.ca> <em9a829f3a-e2ed-4250-8e7e-cad6623a30a2@sydney> <FD826FBD-6D15-4791-8C9F-450E83EA1EC6@iii.ca> <eme27e4a00-19ad-48da-bd9e-1e8bfb69ca8f@sydney> <87C7FDA2-3F7B-4037-BD5D-71BF5D71BC27@iii.ca> <em9f5683f3-880a-46a9-82da-4ab61010529a@sydney> <emf5b957a9-56ec-4bf1-b8d7-2bd117d64769@sydney>
To: Paul Jones <paulej@packetizer.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/perc/pBwTqVX3FJ38jfFN6ksBUgFKDXM>
Subject: Re: [Perc] Drop support for E2E RTP header extensions
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing <perc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perc>, <mailto:perc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/perc/>
List-Post: <mailto:perc@ietf.org>
List-Help: <mailto:perc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perc>, <mailto:perc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 May 2017 20:20:59 -0000

> On May 17, 2017, at 10:15 AM, Paul E. Jones <paulej@packetizer.com> wrote:
> 
> 
> As I now understand, a calling device could send an offer with IDs proposed, and the media distributor would return an answer removing any IDs that are values that are not what the media distributor wants to use (this is what Cullen meant by "reject" and I interpreted that to mean reject the entire offer itself).  The media distributor could then send a new offer and advertise the header extension values it wants to use.  I don't think that would violate the spec in terms of remapping identifiers.
> 
> Another approach might be to only offer ID values in the range 4096-4351, thus allowing the media distributor to return an answer with identifiers assigned.

I had not thought about using the exclusive negotiation stuff. I like that it would work in a single Offer/Answer round instead of needing two.

v2.23.0 | Report a Bug | By Email