Re: [rtcweb] 5G standards advocating WebRTC protocol violations?

Bo Burman <bo.burman@ericsson.com> Tue, 09 November 2021 22:45 UTC

Return-Path: <bo.burman@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0743A03EE for <rtcweb@ietfa.amsl.com>; Tue, 9 Nov 2021 14:45:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 kTEroFTfRA7l for <rtcweb@ietfa.amsl.com>; Tue, 9 Nov 2021 14:45:16 -0800 (PST)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70048.outbound.protection.outlook.com [40.107.7.48]) (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 8C4FB3A02C1 for <rtcweb@ietf.org>; Tue, 9 Nov 2021 14:45:16 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ewTsWzbEewCqkOKB/JzMeVLHYOu2BLCme2YhWNInt3ELn21ZfkFZWwYBf+8EDtn85BOSSMjqHuVMZjh0+xb/0ZJ8dQ+gbf8CP/aPQMlhAyWOe1zsH+JeuhGTROc4qQ6bwLhZFR0ca1Rz0xiHYYHsjmztLlklyQUDyNOn+cw8yPYjRc2fsWQ/Rvy8wyF3cveroPbNcC+fWRDHuU+gr77Bd58fcX5296mE6VBtbER4fChLZy4ZSFTxCmalS9UtGaKtQDq17IPMSQb7tsirog6EL9dtRfULoeknTIlREaPdeoxiGtS1PwEr6FRGwBv3OFCjCVWsmR6uAcrMpdc0ABjI2g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=h/HCL/eSFxbKphwnTNndTyFO4ag73e63umHWMW7mPSQ=; b=Pg1/QxRiHNLrUoqDgNCHEiObOhJ3yaVKjaqf8zAKwXoSv50oDNDvOg+LIpuGwB79ciDiCWpS2Roi4Xve6A4gvxn9cAqmyYvGQuuQTwyVi4bHZZ0ZBzKDaGRkfTg8b4zJso1bPESWtpdUxRHBk6mkBxiDtBkqylyEP5Xup6D/ont+lj5lPPrABAFiEl4GMwn2DPRzofnwvGEazVtiJJbfeqwNKxFH0EJRzaCI66Q4hbd6GWc2QzbQ4W5ltOMisbdQibgm1ltSXmzILYaPGavPcPX8E4z+xkWc9t9+VvzuloeQLAruq+FlSPHASkOnNTkvn/385NTwhdRM/EdAlrLb5g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h/HCL/eSFxbKphwnTNndTyFO4ag73e63umHWMW7mPSQ=; b=Oicavr1Ao9lM6wFCqaR43VoEqwIDBPL0R0vN5v/Z8ancrd7KrGTka97Fzi6C+z+kW1WcDo29x3hcolP3hqZMc94rw8OGs6SGkngrMZQkBmC7l6ize+qFaxEWQgRsPFzGtG6zchSbMUSPbdK8TPCFvYoaX5CMcrwEFMnKWpTt0ao=
Received: from HE1PR07MB3403.eurprd07.prod.outlook.com (2603:10a6:7:32::25) by HE1PR0702MB3690.eurprd07.prod.outlook.com (2603:10a6:7:7e::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.9; Tue, 9 Nov 2021 22:45:07 +0000
Received: from HE1PR07MB3403.eurprd07.prod.outlook.com ([fe80::4c9f:2388:31aa:af0e]) by HE1PR07MB3403.eurprd07.prod.outlook.com ([fe80::4c9f:2388:31aa:af0e%7]) with mapi id 15.20.4690.016; Tue, 9 Nov 2021 22:45:07 +0000
From: Bo Burman <bo.burman@ericsson.com>
To: Ted Hardie <ted.ietf@gmail.com>, Harald Alvestrand <harald@alvestrand.no>
CC: RTCWeb IETF <rtcweb@ietf.org>
Thread-Topic: [rtcweb] 5G standards advocating WebRTC protocol violations?
Thread-Index: AQHX0KdAAYfD9gxH+U6UWkCWLMimFavxxvYAgAe6/ZA=
Date: Tue, 09 Nov 2021 22:45:07 +0000
Message-ID: <HE1PR07MB34038C7F4DF8907E96F33C948D929@HE1PR07MB3403.eurprd07.prod.outlook.com>
References: <ca569473-975c-b11d-eaa6-4aa215c8c7c9@alvestrand.no> <CA+9kkMA1GfFY_Uemhvu7PZNj-rJGUMyxYcMbS4_vVu5MTq75Bg@mail.gmail.com>
In-Reply-To: <CA+9kkMA1GfFY_Uemhvu7PZNj-rJGUMyxYcMbS4_vVu5MTq75Bg@mail.gmail.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: dc0c4f07-e59e-479b-5272-08d9a3d29436
x-ms-traffictypediagnostic: HE1PR0702MB3690:
x-microsoft-antispam-prvs: <HE1PR0702MB369003232B1FFC3D6B2268328D929@HE1PR0702MB3690.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:1002;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: EJFqTqcTenzG7P2ErRbWEgJchJwE9Cr+lkJgh/Z9Kt0eQUu1Ix089qTKq5vYlEHRhSq86zywHCAmHNKQyBBbXDZQPqH+ZYw0/VgFlPB4igVFNSMV2lELxsBCxPVEVAwtbTBkBHSBlvNgNk59idbrESyq21hbCheqTx99D0spmXH62SBTIhg/ZJZBWJwfWI805cGQlM4qdA65lp/LtQJs1XSyzZ3z7PRMtGOqygBkO659wRDwOym0dibc6jxG30enpGDMqdZ/UuLd6AR9oqTyJdieyCR/iyb+pUFauXER2kZU1Rsu4i1q52Km/lmJPF03YKCh6wd1fUaS+FlhSwtgYIoiFpcM8tV8PU7oX/vEd30NInO0osNrJtDS6D71+IaTdmBo0tCXuWf/jedBtMHg7tM76SwJO5eb/qAVO90apVooR2R9gPP+bBXjXSDZiGmwymBc3fl5ffeIh0ffR09DIFVbQo3H4pt5df9iV52bq2UEMvec+M9GhgNF2LUjauvgAO/a9hKjOokyYqPlwkcPV4isjKsIDvzWxKPwvlyOm1WMQ+2+c/sTniQ84Edp7X1U1nC75ZWE8l0KoIvIsD9UBK070CledpPSnAsVIxVQYNkhuutXA6tRg7qdk+ARKXVzpftXEUDRjD/+eQhxeQPueN8yrQ4C7JghtlRqDEzqVnOL/IepLzd7mUWgERHtqYv1sUC7KPjKCh3TGKKMwJGmW4Ls7KLDmkebz9bgbhcTuXs9NDopfn02R55KPrPZhiJIsQ8lD3aUt5Qyfy+ve141D+snEBcIusRdYljtYIUHsM9lVrfjHj9DVZKpeaA1TWetymPDdoRIOnACmChKRHpeMQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3403.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(38070700005)(166002)(5660300002)(4326008)(83380400001)(64756008)(38100700002)(66946007)(44832011)(33656002)(99936003)(186003)(55016002)(9686003)(66446008)(82960400001)(508600001)(122000001)(110136005)(52536014)(26005)(966005)(6506007)(8676002)(316002)(7696005)(86362001)(53546011)(8936002)(66476007)(66556008)(76116006)(71200400001)(2906002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: uT5qZxQRaVvlI3/1iSgi+kUw1nJJAQWw/zE7MBQ5bgWEOsDgozQwK7mMoAvdsvcbjIAUA4Yp9GCGHIGtABRrLbsDfdrMs68L2ucIsDwuS6/VgomPwe3DjXkkxiW2cduHnLOTHh7NQlQXRUycQLMMLWthI3fZGIWU1eCf6yLnUkyM/q+mKdjFVyNRlnJx7ORkNJaSJ/uKuBdIyzOGwUmkpbWwMG3s/X3EgPSwvFxk7sbYgejhE0MzicSZr4JC/A5E3Y8+xBLDvjXWLvf8ee2FQpHetwT9KXZwClDgdDFAQbIfU3pFGrxpe0DSKKMhFiJmN02jyeGKlWwMOer0epWN/sY81vQYU+9Q46UtEVM5PYohD5/TZxaQL2v4ID7HrvpGynSV9lA4EXH4XytcdwLofChAji8FkKZ3HS/G5aAWu0Xx61cEDY2IwPb6QQyXfybh7jVayE7oSlZPwltWabuuTnH5WA7al7vt6zaGtaOxZF87IZOwAAseMukMz3nO04oljenXKzsaQM6Vo4Qz1pfjvoBr3mkY2Jv6ZW2SvEs6rZhXNoTlAQTk5k/N5k4Jj7R3Ew9Z7ptjbupCfndsS57vfnzo2WNX6xaBXOjC1SuaiX3TAx2wk6jLTN0zR8QQiWe5j7Q59SkI6L7cdZ4vLIMz+963B3D6q3XwUAVeee31i6Z/d/rogDhEHHep3AP8k6yGxdmho6G1G//mByy/l1yiX31KhTXijR18/eVsxPhhFaju3WWXcboi43TyW7ulBD7WGBugeyqlV5SB1S3PD1h1L+HUXaRkj0zwQNw+n2ONCpHJBeJr0E3DOh8jKcpbSexJnpua6T0KfE1VzJe9dW9KXgwDSYbvwh3/HbkJd8Tn+68CsjuLF8/b4Bxs9w+fq0Cl8GlC6onM2An4Ta/bNusj692ezUxqyjSvi1e6rmdJK821X0jPJDESj1iPbnqLhNuG1RC+f3ayMO7S0sEQ+UEQ+zRE60ArJ+ruw2Y7IozPgLA2E1dju49s4Pjvj93FLl1fe0JvC/XLRY/hmbk1jb8aDBOdNabtFiAqFtoy/9LR3TBue9pv1/SsZrVPkIYHYs6yQljj0ip/3zXJAmOto2t2ZzU1irkLdSc1TL9CPkNL9aHvGhi+isNAoThAPqm8HbifVKypvjIYtPiV8ZGzxl07xo34dB+WXTOBiXBuAnwRr+Vj+7AvJreSGnO4GaWgzHijWY1+csD7INLRRgvbvWctZI931OFAJU+pyG/aVBZB6se5FPUWvObpwLo5YohJwA5AJ4jvbR0pb+mEzQk8DXcL+mfG/cmo8m5Tk4W/OBAArvaRgbqJdbu5AS3c8d35eb10nHc48tv6Oq5kVIRxv5HQ8SEBakKV+cP6x7LwYnwaml7yEoAqKGVe764ZnG0kEmAZ+4x6Ij/ALjqtcZFdx7YaFfe+18WcMeYoPj4bZmqyPpGJPfD320JSxI7JdCTLRYZna8vEPMRdIZ1V19CrV7USmuLIC9JYeF7F0fdFLFAvr45Xcrbzzttv2UBFdd0exgeriWrk8K4C25bc66M5ZSdwqJVIh3fgLxgAfq1XdgNUCC+l+vpjKrgyihASsKFkXFdZiCGWaU11Tte5twLyrv6z6PvHHnZH+75Apr8uvK72V9k=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_01DA_01D7D5C3.D290E850"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3403.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dc0c4f07-e59e-479b-5272-08d9a3d29436
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2021 22:45:07.3474 (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: 7JnqJQCDkBzeVk4WuZ3pbQtVTouGUxAnX9wvkGPq8btTuoOKoKCQ+Q1twTRxtYk6DmUbbOGju00Uytc/TnFguA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3690
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/DX324HbOrb5P_F3ifI0A5kRnl7Q>
Subject: Re: [rtcweb] 5G standards advocating WebRTC protocol violations?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Nov 2021 22:45:22 -0000

Hi Ted, Harald,

 

I have some insight into that GSMA work that might help the discussion.

The intent was never to create or even suggest incompatible changes to WebRTC protocols. Quite the opposite, the intent was to reuse WebRTC protocols, which I believe is clear from other parts of that White Paper. The suggested reuse of WebRTC data channel protocol stack is for 3GPP IMS-native multimedia telephony, not intended to change the core of WebRTC. It should be OK to use a data channel outside of WebRTC context – for example, like CLUE telepresence makes use of it. Also, 3GPP previously defined WebRTC access to IMS through the use of a gateway where ICE is used on the WebRTC side, but that is separate from the GSMA case.

 

The GSMA White Paper is mainly educational for that community, in this case exploring possibilities with using WebRTC data channel media as part of 5G phone calls. If GSMA members find this interesting enough, normative work and specifications will follow but nothing is started yet.

 

I believe the sentence Harald highlights below should be interpreted from the perspective that ICE/STUN/TURN functionality is strictly not needed in a telco operator’s network, since connectivity is solved by other means in that context. That particular sentence is likely not considering what requirements, e.g. use of ICE, that may come from reuse of existing WebRTC protocol stacks. This aspect must however be kept in mind as the work continues.

 

I hope that helps.

 

Cheers,

Bo

 

From: rtcweb <rtcweb-bounces@ietf.org> On Behalf Of Ted Hardie
Sent: den 3 november 2021 14:10
To: Harald Alvestrand <harald@alvestrand.no>
Cc: RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] 5G standards advocating WebRTC protocol violations?

 

Hi Harald,

 

It is definitely possible for us to send liaison statements via the appropriate channel, but I am missing some context.  Can you provide a citation to the document from which the excerpt comes?  (It appears to be labeled a white paper, so the first step may be to confirm that its description and the underlying specs say the same thing.)

 

regards,

 

Ted Hardie

 

On Wed, Nov 3, 2021 at 11:37 AM Harald Alvestrand <harald@alvestrand.no <mailto:harald@alvestrand.no> > wrote:

It's come to my attention that there's apparently some 5G spec that says 
"Use WebRTC datachannel, but don't bother with this ICE stuff".

The exact quote is below.

Now I don't mind saying "don't use TURN/STUN servers" - that's a 
configuration option on the WEBRTC API, and anyone can choose to not do 
that - but I do mind leaving out ICE. An ICE-supporting implementation 
won't interwork properly with an implementation that doesn't support ICE.

Is it possible for the IETF to say "please don't make incompatible 
changes to our protocols without asking us"? (that's the version where I 
try not to use expletives).

Or is it possible that this is all a misunderstanding, and the 5G folks 
actually meant to require peer-to-peer ICE, but just wrote it wrongly?

Or did I misunderstand what the WG's intent was, and should just suck it 
up and interoperate with non-ICE-supporting endpoints?

Harald

--------- Spec reference quote ----------

1. Spec
NG.129 - 5G Data Channel White Paper  (CR1001)

8.2.1Data channel APIs
The data channel application consists of the device side logic and the 
server side logic.
Both should use standardized APIs that need to be agreed by the industry.
W3C WebRTC1.0 data channel API specification is suggested as the 
preferred IMS data channel API. RTCPeerConnection ,
RTCDataChannel object, the  callbacks need to be supported .
Only data channel API related definitions  are used and IMS data channel 
API is not allowed to use WebRTC media.
ICE/STUN/TURN are also not required.

# Reference
3GPP TS 26.114 IMS_Multimedia Telephony Media handling and interaction
GSMA NG.114 IMS Profile for Voice, Video and Messaging over 5GS
GSMA NG.129_5G DATA CHANNEL

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org <mailto:rtcweb@ietf.org> 
https://www.ietf.org/mailman/listinfo/rtcweb