IETF Logo Mail Archive

Re: [Sframe] [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:41 UTC

Return-Path: <thp@westhawk.co.uk>
X-Original-To: sframe@ietfa.amsl.com
Delivered-To: sframe@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB7B3A0B97 for <sframe@ietfa.amsl.com>; Thu, 10 Sep 2020 07:41:06 -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=unavailable 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 GpcKYIIpmHqS for <sframe@ietfa.amsl.com>; Thu, 10 Sep 2020 07:41:03 -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 A7D503A0B91 for <sframe@ietf.org>; Thu, 10 Sep 2020 07:41:02 -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/sframe/nrcbZm98J3stY_VuKzG92xnmAZI>
Subject: Re: [Sframe] [dispatch] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT)
X-BeenThere: sframe@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <sframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sframe>, <mailto:sframe-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sframe/>
List-Post: <mailto:sframe@ietf.org>
List-Help: <mailto:sframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sframe>, <mailto:sframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Sep 2020 14:41:07 -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.23.0 | Report a Bug | By Email