IETF Logo Mail Archive

Re: [dispatch] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT)

westhawk <thp@westhawk.co.uk> Thu, 10 September 2020 14:34 UTC

Return-Path: <thp@westhawk.co.uk>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4873A0B91 for <dispatch@ietfa.amsl.com>; Thu, 10 Sep 2020 07:34:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 NQZa_0M5WMhu for <dispatch@ietfa.amsl.com>; Thu, 10 Sep 2020 07:34:22 -0700 (PDT)
Received: from smtp001-out2.apm-internet.net (smtp001-out2.apm-internet.net [85.119.248.224]) (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 1D9953A0B90 for <dispatch@ietf.org>; Thu, 10 Sep 2020 07:34:21 -0700 (PDT)
Received: (qmail 22378 invoked from network); 10 Sep 2020 14:34:20 -0000
X-APM-Out-ID: 15997484602237
X-APM-Authkey: 255286/0(159927/0) 1135
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 10 Sep 2020 14:34:20 -0000
Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 1504980B36; Thu, 10 Sep 2020 15:34:20 +0100 (BST)
Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id EnWgVsR8oElL; Thu, 10 Sep 2020 15:34:20 +0100 (BST)
Received: from [192.168.0.102] (unknown [192.67.4.128]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id DFAE080B27; Thu, 10 Sep 2020 15:34:19 +0100 (BST)
From: westhawk <thp@westhawk.co.uk>
Message-Id: <44BA90CE-A41F-4FDA-A516-AAF03371D1A7@westhawk.co.uk>
Content-Type: multipart/alternative; boundary="Apple-Mail=_21EFB90A-D401-4520-B341-2FE1C66695C8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Thu, 10 Sep 2020 15:34:12 +0100
In-Reply-To: <159949693494.2875.16993532753477402380@ietfa.amsl.com>
Cc: sframe-chairs@ietf.org, dispatch@ietf.org, sframe@ietf.org
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
References: <159949693494.2875.16993532753477402380@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/kDGhhBNt2smvoYyeaO9gOHRddgE>
Subject: Re: [dispatch] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Sep 2020 14:34:24 -0000


> On 7 Sep 2020, at 17:42, Magnus Westerlund via Datatracker <noreply@ietf.org> wrote:
> 
> Even without these sub-stream SFRAMEs there
> exist a description capability that needs to exist in an RTP payload format for
> the end-consumer to correctly be able to route the protected data after
> decapsulation and that the end-point having that capability.

I think the assumption here (perhaps understated) is that both ends are running compatible 
sframe implementations. In webRTC this is done by them both loading the same javascript or app version.
In a more heterogeneous situation some signalling may be needed, but that’s explicitly out of scope.


> However it creates limitation about what the SFU
> can do, especially when it comes to repair. 

I think that’s an inevitable (and acceptable) consequence of e2e encryption.

T.

v2.28.0 | Report a Bug | By Email | System Status