Re: [Rum] I-D Action: draft-ietf-rum-rue-01.txt

Eric Burger <eburger@standardstrack.com> Tue, 05 November 2019 21:41 UTC

Return-Path: <eburger@standardstrack.com>
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 564A9120B7E for <rum@ietfa.amsl.com>; Tue, 5 Nov 2019 13:41:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.687
X-Spam-Level:
X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=standardstrack.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 ZMI_g_0onlCv for <rum@ietfa.amsl.com>; Tue, 5 Nov 2019 13:41:18 -0800 (PST)
Received: from se4d-iad1.servconfig.com (se4d-iad1.servconfig.com [173.231.241.34]) (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 4956812095B for <rum@ietf.org>; Tue, 5 Nov 2019 13:41:18 -0800 (PST)
Received: from biz221.inmotionhosting.com ([192.145.239.201]) by se4-iad1.servconfig.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <eburger@standardstrack.com>) id 1iS6Za-000wB5-Lt for rum@ietf.org; Tue, 05 Nov 2019 16:41:17 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=Message-Id:In-Reply-To:To:References:Date: Subject:Mime-Version:Content-Type:From:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=3KyUXr5L7nQbfZdPxVm8n+Z2GdrRhvE2jp5pT9YnUo0=; b=GJGIvSNwy4915VZW6b6cyQ0da xUCorhCbS//HuIJSjQxQNWe2vygVwcv6w5cFXD6jojeOgf0ImNAe4a0FcPPUA5gY0J0GD6+q1LlRj RhnMPCiwUc1txevMglBwJ10U44yUf/L+KO8VuYxQU2i9/qAhPScjp4mZ2HbZ8TnuxNrsw=;
Received: from [68.100.101.142] (port=64637 helo=[192.168.10.23]) by biz221.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <eburger@standardstrack.com>) id 1iS6ZQ-00AC0c-GK for rum@ietf.org; Tue, 05 Nov 2019 13:41:09 -0800
From: Eric Burger <eburger@standardstrack.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_8CE83E34-CA02-4378-AC4E-CDE16FCBAD84"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 5 Nov 2019 16:40:59 -0500
References: <157290244575.13960.5728950433793071735@ietfa.amsl.com> <57728288-27e6-4598-09a4-3bcc9b0bff04@alum.mit.edu> <A9BF6EBB-317D-4AA0-B205-6455760F9746@standardstrack.com> <49DAABAB-09DC-40CF-81EE-61D08DA3E9CF@sorenson.com>
To: "rum@ietf.org" <rum@ietf.org>
In-Reply-To: <49DAABAB-09DC-40CF-81EE-61D08DA3E9CF@sorenson.com>
Message-Id: <184551B7-25BD-40FA-A0B8-957489CB8F89@standardstrack.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-OutGoing-Spam-Status: No, score=-1.0
X-Get-Message-Sender-Via: biz221.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Authenticated-Sender: biz221.inmotionhosting.com: eburger@standardstrack.com
X-Originating-IP: 192.145.239.201
X-SpamExperts-Domain: biz221.inmotionhosting.com
X-SpamExperts-Username: 192.145.239.201
Authentication-Results: servconfig.com; auth=pass smtp.auth=192.145.239.201@biz221.inmotionhosting.com
X-SpamExperts-Outgoing-Class: ham
X-SpamExperts-Outgoing-Evidence: Combined (0.07)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0T9zDZOvA8ND4p2eQxdfzLSpSDasLI4SayDByyq9LIhVip8EsWulxPGo 8v0QY5ZGl0TNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDwzmmD1lPZONmDbVrCI7lkOfH zJ6mVE7ewsipSVIfs4Z9snTJFlkGJZhuv7l2nb6FgyWFxOA5dILPypvKxNVhWW9iu9q1oNVH8nhC o/XpZxc/iXnuUw31frArk475PTzt0p8T4Nd45j4kJRgJ8MJ6+AqIEnMVLiz2WOd6skFkFmMRxK5O dUqDGvgvOW0ZV5+aaHwJ2eESrUp0Iw/gSJ3HqMuR600P9eQ3vodupN36MrkzGQZS068e3EYTgNAB jZkD8TzPF4eG61o+cxFZrUIXowfXJosMX5ZQSlYSVlCDu2lHfay0qiZGlWA7cME1MR87KvWTUIuw AP+Be6QqMx/OK6S8tu2KVBI79Uufvsp4JVtkiXe41lqpq2ZOFKLzbBWXp6KrPCklAmnloYenuVMJ ithDlN3ZFexZfYgAG9qTPTrzvgwP9cMw+lye/qXkeuruM49zcQbne4vePgcv4iEyyps9zSZic0xN U+sMoNUh1wv7xZFuOdBgdh27Veexr4YSoBpdWj8QLYr5sN4Ugz0teyfQvwms17M1AobeHxE/Nxju +Aijzwf2F7b2ogOZj0s1kc2kxhV1Ed4/qYD49S0gAQE9FrvLEUPXJbB4TOB4dAFErSs0X3oyoTc8 j/o7qulx2QRit+RXm0fuXHzjsVnOat1+QGQSQZkAHEqhDdBqlX2mJh/fLz4XHiApMjTR5Z6slYgE 2PQGE2ArmZIfyREhoGbjO41FyBEqIaDudcVplPFvazNmMXL5syZKQsYN5bZurEoFnnsI10GDqWQ7 UJpN3Li4XU8u8rbwXG85FVszUam2s+fuuJc8r2wsIoeqrkwThVs3PAzkvrh8xhewUGkETLZe7fg+ F5wclc6uaq+HIxxQHTHnHCfQlWiHz6cyiF60Jh1tDfjT4hz4J/ncsYb09dL18Ey1eb/DE0CbLMGl b4O0rIpjO6/1LqHA1UlOUbsqed3ByBR2r0KaNxVA6y2CEA==
X-Report-Abuse-To: spam@se1-lax1.servconfig.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/GA-8yEsUpy21NXDKBhzEp9WurtY>
Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-01.txt
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: Tue, 05 Nov 2019 21:41:21 -0000

From the Charter at https://datatracker.ietf.org/wg/rum/about/: <https://datatracker.ietf.org/wg/rum/about/:>

RUM will not assume hearing users are on the PSTN.

and (emphasis added):

Devices used in VRS can be used to place point-to-point calls where both communicating parties use sign language. When used for point-to-point calling where the participants are not served by the same VRS provider, or when one provider provides the originating multimedia transport environment, but another provides the interpreter (“dial-around call”), the call traverses two providers. Both of these uses impose additional requirements on a RUM device and are in scope for this work.

Thus Opus is a sensible Mandatory to Implement.

> On Nov 5, 2019, at 2:22 PM, Isaac Roach <IRoach@sorenson.com>; wrote:
> 
> Sorenson has a concern about making OPUS mandatory to implement as part of the RUM.  We don’t necessarily object to improvements that might have benefits for users in the long-run, but making OPUS mandatory specifically at this time in the RUM seems to be beyond what is necessary to implement the FCC’s interoperability requirements.  There’s nothing inherent in establishing a standard interface between devices and providers that requires implementation of OPUS.  This would instead appear to create a new minimum standard for VRS that goes beyond the FCC’s requirements.  In addition, Sorenson is concerned that mandatory implementation of OPUS would be expensive as it would require implementation of the CODEC on endpoints and backend systems when it would likely not be used in the near future for Relay PSTN G.711 calls. It would more likely be used for P2P calls but that is out of scope per the RUM charter.
> 
> We’re happy to discuss the merits of these and other long-term goals and improvements for VRS, but this is not the right place to create new minimum requirements that are not necessary for interoperability.
> 
> Thanks,
> 
> Isaac
> 
> 
> From: Rum <rum-bounces@ietf.org>; on behalf of Eric Burger <eburger@standardstrack.com>;
> Date: Tuesday, November 5, 2019 at 12:09 PM
> To: "rum@ietf.org"; <rum@ietf.org>;
> Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-01.txt
> 
> The Pulakka paper I referenced for Keith might be why one would transcode from G.711 to Opus. However, I would not mandate it.
> https://www.isca-speech.org/archive/archive_papers/interspeech_2006/i06_1245.pdf <https://www.isca-speech.org/archive/archive_papers/interspeech_2006/i06_1245.pdf>
> 
> 
> 
>> On Nov 5, 2019, at 1:44 PM, Paul Kyzivat <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>> wrote:
>> 
>> The new text in section 6 on Mandatory to Implement is confusing. A G.711 call originating in the PSTN is never going to be *originated* by a RUE.
>> 
>> Calls *originated* by a RUE should *offer* all MTI codecs including OPUS. If the call terminates in the PSTN then OPUS won't be selected in the answer.
>> 
>> OTOH, a VRS provider when relaying a call to a RUE that originated in the PSTN may offer G.711 and not OPUS. In normal use cases such a call will be a VRS call with an interpreter. I *think* in that case audio gets relayed to the RUE, in which case continuing G.711 makes sense. But does audio from interpreter also go to the RUE? If so, transcoding up to OPUS and then mixing in the interpreter might make sense.
>> 
>> So this is heavily entangled in the need for different requirements for the RUE and the VRS Provider.
>> 
>> Thanks,
>> Paul
[snip]