IETF Logo Mail Archive

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

Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> Fri, 12 May 2017 08:40 UTC

Return-Path: <sergio.garcia.murillo@gmail.com>
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 CC2A1129C12 for <perc@ietfa.amsl.com>; Fri, 12 May 2017 01:40:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Cs8OGraNRdXW for <perc@ietfa.amsl.com>; Fri, 12 May 2017 01:40:22 -0700 (PDT)
Received: from mail-wr0-x242.google.com (mail-wr0-x242.google.com [IPv6:2a00:1450:400c:c0c::242]) (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 A343F127871 for <perc@ietf.org>; Fri, 12 May 2017 01:35:07 -0700 (PDT)
Received: by mail-wr0-x242.google.com with SMTP id 6so6629716wrb.1 for <perc@ietf.org>; Fri, 12 May 2017 01:35:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=gJ8eRwvCdqF4plW5L/CwvC41WSZuwjaJoTZ7fNMcuvY=; b=RzPmZzWFQNoJmPFV1/7b75sRVqDbAsyyuDkZ8atG1ZIeye0l4u01qFRhccFn2onXd0 iwWEhvF0kC6K8PhtfeFER5Iq+xMrIY3ogCvVzPiwLCaWWo7oy6gEyRA/jjhi8lZ1z+5A m6rXAgiplUFASyVtf4fPyOiLJOlHH/Drcg7RvSvMmU5DPCb3UkIvqSznryML+sQ91Zr8 7JjhGiBdwdV35zLSoPndMB+E2RpKd4P9/yjRNjXflQv+H0eRvdUEzjgXsM1cxHT9a2Nf b+pyYYrwHjR+EhM94XXixAPfgAws1xe+HZ8FI4UkB5gtYpP/7xlNoCP1SI1FWnywt+rA f1VA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=gJ8eRwvCdqF4plW5L/CwvC41WSZuwjaJoTZ7fNMcuvY=; b=hETiVy3eRZMVEJMGCJfD3GD+EJ6+1/kWJ0lSFqUvhnY47gaxQD19R+YF1OBVs7Ln9r m/yQOViVfqSo3GsX4QBumNKc/r3ic9ooj6Jy5oucTUXoj4OVm2+DjzH+U4/cGIsYGWob MhgTPz7crhfEOsS11cwfCsyjpIWjufysjSr9wkvULvZLZNNuxrfcUZhY5dLFTdHdDNPY Se1jl3O/bK4ZjM+QR67v4Cs/2a2Yomuzq7CD3ksf6ea55yo21mnaf0bUKD4xdkDHp2t5 lOkzq7OKEy5TYR04f53eMHA585rPn1BpfF3CpI7GZali2jBBCi6+y8f7bVODq8hZBxYv jmdQ==
X-Gm-Message-State: AODbwcBjISrjs2EWLl2m1LR43WtKcQ32oDeKVnYYhWs3uR7fxv01iA1r gpPkch/ZuGVgxw==
X-Received: by 10.223.161.30 with SMTP id o30mr1801913wro.186.1494578106171; Fri, 12 May 2017 01:35:06 -0700 (PDT)
Received: from [192.168.1.43] (84.red-83-36-143.dynamicip.rima-tde.net. [83.36.143.84]) by smtp.googlemail.com with ESMTPSA id m127sm1191399wmb.10.2017.05.12.01.35.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 May 2017 01:35:05 -0700 (PDT)
To: "Paul E. Jones" <paulej@packetizer.com>, perc@ietf.org, Cullen Jennings <fluffy@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>
Cc: Richard Barnes <rlb@ipv.sx>, Nils Ohlmeier <nohlmeier@mozilla.com>, Jonathan Lennox <jonathan@vidyo.com>
From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Message-ID: <095d63e6-ecce-6a07-6e82-fec3448fa1b1@gmail.com>
Date: Fri, 12 May 2017 10:35:05 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <286A6294-EC1E-49D3-88BB-023178DB07BD@packetizer.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/perc/Lscb7bNmYo4_rkQbcQjLXAxhOy0>
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: Fri, 12 May 2017 08:40:25 -0000

On 12/05/2017 8:10, Paul E. Jones wrote:
> I don't see how we can support any E2E extension given the offerer 
> specifies the ID mapping. Multiple endpoints in a conference might 
> indicate any number of didn't ID values for the same extension.
>
Moreover, different endpoints may support different extensions, and they 
can join/leave the the conference at any given time.

So the SFU will not only have to renegotiate de ids of the extensions 
(is that even allowed?), it will have to keep a dynamic list of the 
common extensions and renegotiate it with all participants each time 
each time on of them enters/leaves.

Also, as there is no way of knowing which extensions are HBH and which 
are E2E and which ones are HBH, so the SFU won't be able to use a HBH 
extension with one peer (for example the custom chrome extensions for 
sender side bandwidth estimation) except if all other participants also 
support it, and will have to stop using it if for example a firefox 
participant joins. Even if it is not mean to be used E2E.

> I think we should remove support for E2E extensions. We could leave it 
> open for future support, but I think we should require insertion of 
> the OHB before any other extensions to force HBH use only.

I am against changing the way rtp header extensions are supported today 
by forcing strict ordering "just in case" not even knowing if e2e 
extension will ever be supported, and if so, if this is going to be the 
mechanism used to support it.

Best regards
Sergio

v2.23.0 | Report a Bug | By Email