Re: [Rum] Distinguishing RUE and Provider requirements
Gunnar Hellström <gunnar.hellstrom@omnitor.se> Wed, 06 November 2019 06:34 UTC
Return-Path: <gunnar.hellstrom@omnitor.se>
X-Original-To: rum@ietfa.amsl.com
Delivered-To: rum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0FCE120B96 for <rum@ietfa.amsl.com>; Tue, 5 Nov 2019 22:34:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 (1024-bit key) header.d=omnitorab.onmicrosoft.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 yHK4Rgxv4208 for <rum@ietfa.amsl.com>; Tue, 5 Nov 2019 22:34:35 -0800 (PST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140100.outbound.protection.outlook.com [40.107.14.100]) (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 832AD120B81 for <rum@ietf.org>; Tue, 5 Nov 2019 22:34:34 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Qw62R/9W87Ca6IWoD/V5Uxsyic1DXofi0c4fsmwpAUiLdE8hWX8VzJxhFf7YmO4ipckqdVCM3nXFFCFAwLAzeZkvzti+y6wQ4QnyCRuO4m+jKkgELKKXWsUsBwtKu2bap0ab1ionITOTLhmBPTHKobpPKKbEPwLqm18j0U5SVtK6UoL8QM28CUmDuU+e2pmUbhH0iVY301J88zNKgbFWYU+ntsbU4vlWAzjvdUKJ3AQt7SVU6jyFIbZse2I9YSkUdVg35STFAWL0PuTQMV+W9gkPR9HWCIs3LMZ9IeMmhZ9ZwQ9RRDVPg2zLIjlUpaKm2ulqWiZwMSUg01UtFbVjXw==
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-SenderADCheck; bh=w7j+OpDQrQ7qmFPaghzl8ioo/TLzoFAl6fvsWTK7JfM=; b=SZRrIDpDiZgMDxIyMzD+9fWhAcOvbuzvHV4SPzj4Yz0lWWqR8sJgjc5Dp2fyxsYyWcTXZ9+E6vANgDcmUS4Ypk+EbjvyyZT7BJZXkk3ZgaLTuPhCNTJyO4AQVg2Set6eowIhcXHhevClN62ckB6wRRRAHQAFvii4gC/qepdNAUeCugBIR72rtMwbSVFDzLiW03EdbMIcdXo8gEj/JzqUFfDfzifnPvAccA7VtzIB6F9nJRVc2RAfjsm7mnqREmtnprIs0b6V9wCXwj8QVmMr2FoTaRvV66G08eTSRrtzZEfrbw5DelQXThETa2+mile6n7aLLyKpB7IYGMOhYx6LGw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=omnitor.se; dmarc=pass action=none header.from=omnitor.se; dkim=pass header.d=omnitor.se; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=omnitorab.onmicrosoft.com; s=selector2-omnitorab-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w7j+OpDQrQ7qmFPaghzl8ioo/TLzoFAl6fvsWTK7JfM=; b=GxQd9XjNO6n2jCru4UUV1kbrZ0So4zD82cyCrRjTgdRoQMSDwYCP+BlgsyKSJAYykWZK+F6/3B3KFEinJafhNuR6BtU74TSe4zEyOS1bU0RCxYu3gLfuNLDY9QnQEyS940qD4hd/oNyUTUP6r/a/EjVKSXAxzTPzX5G0GL70+9M=
Received: from VI1P193MB0669.EURP193.PROD.OUTLOOK.COM (10.186.178.76) by VI1P193MB0589.EURP193.PROD.OUTLOOK.COM (10.186.179.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.20; Wed, 6 Nov 2019 06:34:31 +0000
Received: from VI1P193MB0669.EURP193.PROD.OUTLOOK.COM ([fe80::1dfd:c8d1:a788:87cd]) by VI1P193MB0669.EURP193.PROD.OUTLOOK.COM ([fe80::1dfd:c8d1:a788:87cd%7]) with mapi id 15.20.2430.020; Wed, 6 Nov 2019 06:34:31 +0000
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
To: Eric Burger <eburger@standardstrack.com>, Keith Drage <drageke=40ntlworld.com@dmarc.ietf.org>
CC: "rum@ietf.org" <rum@ietf.org>
Thread-Topic: [Rum] Distinguishing RUE and Provider requirements
Thread-Index: AQHVeIyT+OS9Xi64G0KyEjlMjNcpzad7IbOagAA3lICAAAHQAIAAMckAgAFV44CAAQScgA==
Date: Wed, 06 Nov 2019 06:34:30 +0000
Message-ID: <7b27793f-9554-f42a-725f-194b2f6e5a84@omnitor.se>
References: <a3d82911-8d07-16a3-780b-0592e48e37bd@alum.mit.edu> <ab68a7fb-7196-4374-7cd4-baf9a03cf6ff@alum.mit.edu> <1572872182151.78082@purple.us> <9717D87D-A48F-47C3-AD75-5908BAF7A649@brianrosen.net> <47E7BD6C-228D-450F-9ADE-9C0D7B2277DB@standardstrack.com> <4d6550eb-e9b4-2ef7-e784-b561c6b5e7e5@ntlworld.com> <4C40ABB4-5B61-4B2F-AC0D-148DCFBFE5C5@standardstrack.com>
In-Reply-To: <4C40ABB4-5B61-4B2F-AC0D-148DCFBFE5C5@standardstrack.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: GV0P278CA0002.CHEP278.PROD.OUTLOOK.COM (2603:10a6:710:26::12) To VI1P193MB0669.EURP193.PROD.OUTLOOK.COM (2603:10a6:800:159::12)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunnar.hellstrom@omnitor.se;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [83.209.227.4]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6ce90698-6062-45d3-3d38-08d762836133
x-ms-traffictypediagnostic: VI1P193MB0589:
x-ms-exchange-purlcount: 6
x-microsoft-antispam-prvs: <VI1P193MB0589A9D8C4402838660E5487FB790@VI1P193MB0589.EURP193.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02135EB356
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39830400003)(396003)(366004)(136003)(346002)(189003)(199004)(5660300002)(4326008)(85182001)(6246003)(236005)(186003)(8936002)(71190400001)(71200400001)(476003)(11346002)(25786009)(81156014)(5024004)(256004)(7736002)(6116002)(486006)(3846002)(561944003)(2616005)(2906002)(66476007)(81166006)(66446008)(64756008)(66556008)(606006)(316002)(110136005)(85202003)(76176011)(14454004)(66946007)(966005)(508600001)(52116002)(66066001)(6512007)(6436002)(86362001)(66574012)(102836004)(36756003)(31686004)(31696002)(8676002)(6306002)(54896002)(446003)(26005)(229853002)(99286004)(6486002)(6506007)(386003)(53546011)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1P193MB0589; H:VI1P193MB0669.EURP193.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: omnitor.se does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: JpvN+J++qj6Y1FdLha62p7TH73qxyUJz9E+hgFhr0TCbNb9d+q9A1VhKVebfl+VDnUxjiuCJm0C0IyjhYM+lr3XpmJRa+ClhSjyg4HXCrdpOLtfQHUWSsn7wUQEOGK1Kayx0Im3+7QVVjCJyvoWmZ2eBIQjvpviM8lgapL7dNJMQ9hWfj2TkFHciVWG5O6Iy3FZMtb3sz1GMGc1TdcxOywb6txnhhr0it/2Jhp/T5cmCymUM+bHqSLBPknnyJ5q2T+gAyjE/vXLI/XlQq0rJFMVPuJXyyTMGDePs1tTMfUxsvFTib+EaPUy8rDIK+egIyaemdTk0jjvGSMt64pgwoo5OnAtFFNqXEP/75kCpQVgMH10WTIQKrMUSW9O5GobF75G+BL2luiNMfm6H0r7Atsv3OGTA6up9hhNabKNZ1+tDpwpIeZ8u4uW8dp6nnuGVxd4I5hepdyM7hlabb91v+jOGrueXOiHOuNzcNsXVzMc=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_7b27793f9554f42a725f194b2f6e5a84omnitorse_"
MIME-Version: 1.0
X-OriginatorOrg: omnitor.se
X-MS-Exchange-CrossTenant-Network-Message-Id: 6ce90698-6062-45d3-3d38-08d762836133
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 06:34:30.9360 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2df8b35f-363f-46b8-a0d1-ee9b1723225b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 3Fx6IV8cB6NSMUxG0DkZCyt4zWOf8PQpBeinnhGVR4AfPcw0T1VgzJJ0paUUUVGiZRHeDg8Os1zchStB3ZGoyeaEQj81RH8ZhcsY3l9wieA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P193MB0589
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/vzPdejWjRvsLcXTf1cDZhRHSjcI>
Subject: Re: [Rum] Distinguishing RUE and Provider requirements
X-BeenThere: rum@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Relay User Machine <rum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rum>, <mailto:rum-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rum/>
List-Post: <mailto:rum@ietf.org>
List-Help: <mailto:rum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rum>, <mailto:rum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Nov 2019 06:34:45 -0000
Here is one more, from AT&T and Gallaudet University 2016. https://tap.gallaudet.edu/IPTransition/Wideband%20Audio/ Regards Gunnar Den 2019-11-05 kl. 16:01, skrev Eric Burger: To name a few: Mantokoudis, Georgios; Kompis, Martin; Dubach, Patrick; Caversaccio, Marco; Senn, Pascal, Speech Perception Benefits of Internet Versus Conventional Telephony for Hearing-Impaired Individuals, https://www.jmir.org/2012/4/e102/ Wältermann, M.; Raake, A.; Möller, S., Quality Dimensions of Narrowband and Wideband Speech Transmission, https://www.ingentaconnect.com/content/dav/aaua/2010/00000096/00000006/art00009 Hannu Pulakka, Laura Laaksonen, Paavo Alku, Quality Improvement of Telephone Speech by Artificial Bandwidth Expansion – Listening Tests in Three Languages, https://www.isca-speech.org/archive/archive_papers/interspeech_2006/i06_1245.pdf Yang, Xiangui, Effects of Digital Audio Quality on Students' Performance in LAN Delivered English Listening Comprehension Tests, https://etd.ohiolink.edu/pg_10?0::NO:10:P10_ACCESSION_NUM:ohiou1236796324 On Nov 4, 2019, at 1:38 PM, Keith Drage <drageke=40ntlworld.com@dmarc.ietf.org<mailto:drageke=40ntlworld.com@dmarc.ietf.org>> wrote: Out of interest, do you have any reference to research papers that have evaluated different codecs for use by the hard of hearing, and in particular that justify the statement "Opus is infinitely better for people with partial hearing loss than G.711". Keith On 04/11/2019 15:39, Eric Burger wrote: The point is that if we say it’s OK not to implement Opus, it means we will still be using G.711 in 2120, long after the last 3,000 Hz toll facility has crumbled into dust. By saying Opus is Mandatory to Implement, it means you can feel free to use G.711 if that’s what is offered, but when you look in the other direction you are able to accept a more modern codec. Also, Opus is infinitely better for people with partial hearing loss than G.711 - it can be the difference between being able to still use audio, being able to use just a CTS service, or if needed a full VRS service. These are the kinds of things we think about in the IETF to support legacy networks while creating useful services that are not simply replicas of legacy services. On Nov 4, 2019, at 10:33 AM, Brian Rosen <br@brianrosen.net<mailto:br@brianrosen.net>> wrote: Mandatory to Implement doesn’t mean mandatory to use. In the example of an incoming call from the PSTN, offering G.711 only is appropriate, and transcoding would not be advisable. The IETF folk understand MTI, but perhaps some explanatory text would be helpful in the document. Brian On Nov 4, 2019, at 7:56 AM, James Hamlin <james.hamlin@purple.us<mailto:james.hamlin@purple.us>> wrote: Paul In the draft-ietf-rum-rue-00, there's an exemption from VP8 support for providers but no exemption from Opus support. The implication is that, in a call from the PSTN using Voice Carry Over, the provider must offer OPUS even though the audio content is constrained to 8bit*8kHz PCM over the PSTN. I don't recall seeing any argument for requiring transcoding in this case; there would be no benefit in audio quality. Best regards James ________________________________________ From: Rum <rum-bounces@ietf.org<mailto:rum-bounces@ietf.org>> on behalf of Paul Kyzivat <pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu>> Sent: 01 October 2019 20:15 To: rum@ietf.org<mailto:rum@ietf.org> Subject: [Rum] Distinguishing RUE and Provider requirements In the discussion thread that followed the attached message it started to become apparent that there is a need to distinguish the requirements, and/or requirement strength, that apply to the RUE itself from those that apply when a RUE connects to a VRS Provider. Now that we have a wg draft to work from, I would like to see people step forward and make proposal(s) for what those differences should be. While the prior discussion focused on codecs, please also consider what else might need to differ. Thanks, Paul -------- Forwarded Message -------- Subject: [Rum] Codec requirements in draft-rosen-rue-01 Resent-From: pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu> Date: Mon, 12 Aug 2019 16:20:51 -0400 From: Paul Kyzivat <pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu>> To: rum@ietf.org<mailto:rum@ietf.org> draft-rosen-rue-01 changes the video codec requirements. It now simply references webrtc RFC7742. RFC7742 distinguishes three types of endpoints: "WebRTC browser", "WebRTC non-browser", and "WebRTC-compatible endpoint". AFAIK it assumes that each end is one of these. Is the expectation here that both the RUE and the provider comply with one of these? In particular, that the provider may simply be a "WebRTC-compatible endpoint? Notably: "WebRTC-compatible endpoints" are free to implement any video codecs they see fit. This follows logically from the definition of "WebRTC- compatible endpoint". It is, of course, advisable to implement at least one of the video codecs that is mandated for WebRTC browsers, and implementors are encouraged to do so. Similarly, the audio requirements have been changed to reference webrtc RFC7874. That one doesn't have the distinction between "WebRTC browser", "WebRTC non-browser", and "WebRTC-compatible endpoint". It applies the same requirements to all. In particular, it requires OPUS support. I don't know why it doesn't make the same endpoint distinctions as for video. I think simply referencing these documents isn't sufficient. Seems like we need a more nuanced specification of what is required, though we may still reference these docs with qualifications. Thanks, Paul -- Rum mailing list Rum@ietf.org<mailto:Rum@ietf.org> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2frum&c=E,1,Fpj3uNl4KHZVkbPWDbLGqfVwMGBdbeBLTsOB6QL2I3YozMnj25zcbabu7vIDBK1XllKKO2g7RstAehUCAqLal9VAcn2JjWNhbLeuauSs&typo=0 -- Rum mailing list Rum@ietf.org<mailto:Rum@ietf.org> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2frum&c=E,1,G7A8JW3tfx9hiDhscPDTeHCoLWUSZAbId59jwHnCzDyqC39OUhM8kWYkfV9kiAEQFFRR9WYYMFy1o70xg8b-0emBXUamnQT4emSupy2-U8Yb5E-WvU4iSpdSVqQ,&typo=0 -- Rum mailing list Rum@ietf.org<mailto:Rum@ietf.org> https://www.ietf.org/mailman/listinfo/rum -- Rum mailing list Rum@ietf.org<mailto:Rum@ietf.org> https://www.ietf.org/mailman/listinfo/rum -- Rum mailing list Rum@ietf.org<mailto:Rum@ietf.org> https://www.ietf.org/mailman/listinfo/rum -- + + + + + + + + + + + + + + Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se<mailto:gunnar.hellstrom@omnitor.se> +46 708 204 288
- [Rum] Let's get into it Brian Rosen
- Re: [Rum] Let's get into it Olle E. Johansson
- Re: [Rum] Let's get into it Gunnar Hellström
- Re: [Rum] Let's get into it Brian Rosen
- Re: [Rum] [EXT] Let's get into it Janett, Amy E.
- Re: [Rum] Let's get into it Brian Rosen
- [Rum] RUE NAT Traversal in draft-rosen-rue-01 Paul Kyzivat
- [Rum] RUE client credentials Paul Kyzivat
- [Rum] Codec requirements in draft-rosen-rue-01 Paul Kyzivat
- Re: [Rum] Let's get into it Olle E. Johansson
- Re: [Rum] RUE client credentials Brian Rosen
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Brian Rosen
- Re: [Rum] Let's get into it Brian Rosen
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Adam Roach
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Richard Shockey
- Re: [Rum] RUE client credentials Paul Kyzivat
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Paul Kyzivat
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Brian Rosen
- Re: [Rum] RUE client credentials Brian Rosen
- Re: [Rum] RUE client credentials Paul Kyzivat
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Eric Burger
- Re: [Rum] RUE client credentials Brian Rosen
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Brian Rosen
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Paul Kyzivat
- Re: [Rum] RUE client credentials Paul Kyzivat
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Adam Roach
- Re: [Rum] Codec requirements in draft-rosen-rue-01 James Hamlin
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Paul Kyzivat
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Brian Rosen
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Gunnar Hellström
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Brian Rosen
- Re: [Rum] Codec requirements in draft-rosen-rue-01 James Hamlin
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Brian Rosen
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Eric Burger
- Re: [Rum] Codec requirements in draft-rosen-rue-01 James Hamlin
- [Rum] Media security Paul Kyzivat
- [Rum] Distinguishing RUE and Provider requirements Paul Kyzivat
- Re: [Rum] Media security Paul Kyzivat
- Re: [Rum] Media security DOLLY, MARTIN C
- Re: [Rum] Media security Brian Rosen
- Re: [Rum] Media security Paul Kyzivat
- Re: [Rum] Media security Paul Kyzivat
- Re: [Rum] Media security Chris Wendt
- Re: [Rum] Media security Eric Burger
- Re: [Rum] Media security Paul Kyzivat
- Re: [Rum] Distinguishing RUE and Provider require… James Hamlin
- Re: [Rum] Distinguishing RUE and Provider require… Brian Rosen
- Re: [Rum] Distinguishing RUE and Provider require… Eric Burger
- Re: [Rum] Distinguishing RUE and Provider require… James Hamlin
- Re: [Rum] Distinguishing RUE and Provider require… Brian Rosen
- Re: [Rum] Distinguishing RUE and Provider require… Keith Drage
- Re: [Rum] Distinguishing RUE and Provider require… Eric Burger
- Re: [Rum] Distinguishing RUE and Provider require… Gunnar Hellström