Re: [V3] High level comments on the RIPT charter and scope

Magnus Westerlund <> Mon, 30 March 2020 13:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BDC843A1604 for <>; Mon, 30 Mar 2020 06:44:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.201
X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Kafs7XckUmzJ for <>; Mon, 30 Mar 2020 06:44:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A06BF3A15FE for <>; Mon, 30 Mar 2020 06:44:29 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=Tbkcg7bgy2iGKvDlYPKOQalfJ5pT7T4qYx3qNZtIuaoTrzoAmy+gQD+4pzuyXNI/csFoiwcXtFt+9376OYNhdmmoshL+4lQR5m4btRaXz1FCIbLmOwIZiXvCAyCEFXE5FMy/8KnHKc4OJSGLVLB+2Vl2J/w+LkTEPKgiTpanZilC/GMeFq+yzJYnCQ0B6NZLshaH2v+WqgR2nHqH9PL0tt/pPhY8WKHsymW75Bn4LcQ3AhCFPcxFt3Y28NhSZOItUK8/P3sgBUNaJ9nxvFvdIcuobh2g99tmD9e8aZ9fFCNKwcmVoTXdHedpyccxqH1S2LxXe4GdiGMxiMXMYAN1rg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=166QEkeLnGp2t4RdYyWIY8RxtrC9/OMUSzcU/WcOHaQ=; b=VOk5q8Vp/lknMAxhQEBqX7ke0y4LvMyIoLjm1LlvvR/+zs0A8drgBz2CjbBIUOdrSPPhYN3ml9TIDBNUKm0BjP4Cf+lhLoQoooHqeUxO/SXxVUjKJ2FsYwYV9sHUX916PXLxwytJvXz94DZpni0r+ecRW5LO1dzJeR1WlepkZQKZJF/bOS/FF/NbQY3R+hXHH6g3hBkgV8xL5Dx4G6+ltW6+3uQ6J2qpCboiCOXtEWfGRmGCupZqg4u86nz8+/QKO37NRHy10CEkag9LwpNDXUHiKQxGwssDUKF0cVrrMMLb1BnCB7VMbxQJup6uWQjKW0q5qlYf2+VFj9pTIg3EIw==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=166QEkeLnGp2t4RdYyWIY8RxtrC9/OMUSzcU/WcOHaQ=; b=GKWVFOgTZhDHUmLY2RY61emhoBiM/muP1g4lpKEwTieG39u4HZg4+kLihBeXN0ZlMNzH+e+7X8ZAwb0NZaZCwIiZthzVTA4JtepTBrm8Tbb72XF7U/Tj92LIiGDblY/Uklq2hKgzmo1hgSs0ICFNZjVIbQjpmSItvgXn5mOowKI=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.13; Mon, 30 Mar 2020 13:44:26 +0000
Received: from ([fe80::8bd:85b0:d547:9eed]) by ([fe80::8bd:85b0:d547:9eed%6]) with mapi id 15.20.2856.018; Mon, 30 Mar 2020 13:44:26 +0000
From: Magnus Westerlund <>
To: "" <>, "" <>
CC: "" <>
Thread-Topic: [V3] High level comments on the RIPT charter and scope
Thread-Index: AQHWBENbus/fvMWAlEybhl6kdLAG2KhcnlqAgASLxYA=
Date: Mon, 30 Mar 2020 13:44:26 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.1
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6cc56ac7-e366-4ac3-3ca6-08d7d4b076b6
x-ms-traffictypediagnostic: HE1PR0702MB3819:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0358535363
x-forefront-antispam-report: CIP:; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM;; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(376002)(346002)(39860400002)(396003)(136003)(366004)(186003)(6512007)(99936003)(8676002)(71200400001)(36756003)(2906002)(44832011)(66946007)(86362001)(66476007)(66556008)(64756008)(66446008)(76116006)(66616009)(53546011)(2616005)(5660300002)(26005)(478600001)(110136005)(6486002)(4326008)(81156014)(8936002)(81166006)(316002)(6506007)(99106002); DIR:OUT; SFP:1101;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 8w1MN3PiqKEBPZgEvC+eOhFxVUnCoiQg+BYNtI84BKNG8z59ywyjHAn9Q2FBcjRIJTMRnyMbMPpy+7nXW44Id6KJJ7HHLKRbDGFf8Wz+2mOCkPmDVZKvqLO1rnlQwas+yPfKNkJkTZb3pqEGep84f+9r1w7mghHYdLUVTEkGJF8prdm37/sK4bmiFbmRWJAu64YG6uMZH6R2GE/n0QyxtT2aouglBcy+YBoOZgdBBE1Si3fcU+uZ8p0bZKcR4eEfmUvOIwdV0BBmTE/GeJOKxAw+e3fK08iSijxMOTkMwSx1gzGOUfLnUodr8vClPJ69e5xb21yI0iAgHAfeGYnKi1iiGx8sVsG669BlL/kxvc0wHgELlqcvmBLsfxdCOwT12M2JzkjHnkAR8LuaOx8sRaJK4ipy5LCuVBZ30q4waICEaxqYMsVeK89D6kz79qRCplYdM8C2Mq1qdRcoTyXH0kyjH+Zm+OkrZEuZdzFuyxiAdIUTJ9ubsj1Puz4vm+D2
x-ms-exchange-antispam-messagedata: wWa7CN9szzLkOoO6HLd2FztWcKep0tbyhtmtuf0SfBoxp5KRDdE9ehbm2JvpcFh3HS3aplgoTCBPOcrJRnCD7crKbIeQv5oAhYdsMpNJIXnn0jSwm2wu4gsX9M6TVKg2YMHWuC8Xzo7D60Hq/N80KQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-MY2yp3CDfk0LxoOiO2UZ"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6cc56ac7-e366-4ac3-3ca6-08d7d4b076b6
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2020 13:44:26.6092 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 5yqryukWq1OWdKib9QlzamfR6jq1nIkHtgiIl41oviaxslBBjS9/35l6vLCa8qNeMUevT5ILgt0AD7jRIrjAVZ5WD5LwsBfjYvWkkRR+ZO0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3819
Archived-At: <>
Subject: Re: [V3] High level comments on the RIPT charter and scope
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 30 Mar 2020 13:44:32 -0000

On Fri, 2020-03-27 at 10:19 -0600, Cullen Jennings wrote:
> > On Mar 27, 2020, at 8:23 AM, Magnus Westerlund <
> >> wrote:
> > 
> > The third big part is the media transport. I think we need to strongly
> > consider
> > if this can be broken out in to it seperate WG.
> I think the WG we are talking about here is the WG to do media of H3. So we
> can talk about other things being in or out of it but that is the core thing. 
> I would like to point out that one of the design properties that has been
> making this easier is that media is self describing. What I mean by that is
> that if a device receives media that is one of the supported formats and
> within in the limits of that device supports, the media has all the
> information the device needs to decode it. No out of band information needed.
> That is key to making this easier to deal with HA and scalability on cloud
> side. I think that is a good property for modern designs. We have been going
> that way for a long time with things like opus and it works out well. 

So, let me ask a question here. How important is it be capable to transmitt
individual media ADU or even RTP payloads in a single HTTP request that ripples
through the system independent compared to have a system that can in a 0-rtt
fashion (re-)establish an point to point by initiating an HTTP request? 

Treating each media ADU as its own request potentially being routed in a non-
sticky way will induce significant jitter would it not? The drafts talks about
sticky routing, and I did notice some comments about that assumption already.
Thus, from my perspective it appears that the high-performance target would be
to establish an point to point quic based transport with the relevant server
node that handles media forwarding. If that fails have a mechanism that can
rapidly re-establish that connection with what ever node that is now the
appointed one for the given call/conference. 

Then I do understand the desire to have a fallback, and maybe that is plain HTTP
requests, but let that be the fallback and not the primary mechanism. Becasue I
think that would unnecessary limit the potential of this system. 

> > here are several aspects here.
> > First of the split in expertise between the media transport and the
> > signalling
> > folks. 
> I’m not sure what you mean by signalling but the the singling here was mostly
> start media , stop media. It is not call routing, forking etc that is done by
> SIP. 

Yes, but even session establishment and control is still signalling from my


Magnus Westerlund 

Networks, Ericsson Research
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: