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

Eric Burger <eburger@standardstrack.com> Tue, 05 November 2019 19:09 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 E2D511209D3 for <rum@ietfa.amsl.com>; Tue, 5 Nov 2019 11:09:36 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 BcbbGKcXuqm1 for <rum@ietfa.amsl.com>; Tue, 5 Nov 2019 11:09:35 -0800 (PST)
Received: from se3-lax1.servconfig.com (se3-lax1.servconfig.com [104.244.124.87]) (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 7D4B712098D for <rum@ietf.org>; Tue, 5 Nov 2019 11:09:35 -0800 (PST)
Received: from biz221.inmotionhosting.com ([192.145.239.201]) by se3-lax1.servconfig.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <eburger@standardstrack.com>) id 1iS4CN-0003dz-7C for rum@ietf.org; Tue, 05 Nov 2019 14:09:35 -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=Rugt245+twcg9LvG/pU1iLBdYK/eB1aaaIKrLFERWWs=; b=DSfUH7osgjE6M4Psx3M8ap9Nc 2v2O3ftCdQV2ipwhKD0x5lyP0Qrf5keKdgYb+FlUVw7Pem23WrQc8ucIcGrguGTm62BTdUG4EL4VC o7/BHTySTTPI5kC8HH5fetYqPV/78YQsD3SF6iJKKYKg7bH4tprVYiFHtBD6NNgrDJZdo=;
Received: from [174.200.16.60] (port=1712 helo=[192.168.43.104]) by biz221.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <eburger@standardstrack.com>) id 1iS4CB-004uk6-PQ for rum@ietf.org; Tue, 05 Nov 2019 11:08:59 -0800
From: Eric Burger <eburger@standardstrack.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_F3350EEC-3071-41D0-98F1-5B7AC3575461"; 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 14:08:49 -0500
References: <157290244575.13960.5728950433793071735@ietfa.amsl.com> <57728288-27e6-4598-09a4-3bcc9b0bff04@alum.mit.edu>
To: rum@ietf.org
In-Reply-To: <57728288-27e6-4598-09a4-3bcc9b0bff04@alum.mit.edu>
Message-Id: <A9BF6EBB-317D-4AA0-B205-6455760F9746@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.06)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0T9zDZOvA8ND4p2eQxdfzLSpSDasLI4SayDByyq9LIhVydNbGJnYAVEf E4Th4ih8VkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDwzmmD1lPZONmDbVrCI7lkOfH zJ6mVE7ewsipSVIfs4bnyuy/SgEv3r/3sCfRI7gGgyWFxOA5dILPypvKxNVhWW9iu9q1oNVH8nhC o/XpZxc/iXnuUw31frArk475PTzt0p8T4Nd45j4kJRgJ8MJ6+D+G8xlBbX8yqaxc3Ca/JhYRxK5O dUqDGvgvOW0ZV5+aaHwJ2eESrUp0Iw/gSJ3HqMuR600P9eQ3vodupN36MrkzGQZS068e3EYTgNAB jZkD8TzPF4eG61o+cxFZrUIXowfXJosMX5ZQSlYSVlCDu2lHfay0qiZGlWA7cME1MR87KvWTUIuw AP+Be6QqMx/OK6S8tu2KVBI79Uufvsp4JVtkiXe41lqpq2ZOFKLzbBWXp6KrPCklAmnloYenuVMJ ithDlN3ZFexZfYgAG9qTPTrzvgwP9cMw+lye/qXkeuruM49zcQbne4vePgcv4iEyyps9zSZic0xN U+sMoNUh1wvbY7cuSA8rr1IX2jbfhdHpRq3q/k4yrX91iMjuAOA3NPPCdgw6C9Y1gxqM5dl4339l 5VsNmjFRP8Tn5HNzDUKU/H6jD7pq5ElFy3fFf2s/xjf9bG4oCE8tXKfGDzsW4pDsxBoFbdIyTZwD 0tTyhMSsSJ3IubBWGgd3tCW2+j49qPy8TH7WSc4+zHum9T07LFof09gwlrydv34qOWri+3anW38R u5wJ40NmkTTJOljVAHLYM3A6BXfvel8OEFDbU50IgR7PRT5/DHVWO8a2mKDk6wbUwIyEC/K8KEtW w07pi33IciEhgmtMw3nNgNoOL9aocX5jTqOPXegHd4QqN1stFdDzDETtPsIzc13Og30NySaguH3F iNx1MYrEHZWAQSGSTwMUHD8nvT6qjZo9eXrf6YZflXKvK4TN7SfIl4AyWsJcTQxjOb16oNH/dgmH 4dCci8JLiiOdckUewCJrmQRccHsd8qMjV5g1hoDi6vb8iw==
X-Report-Abuse-To: spam@se1-lax1.servconfig.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/q3O20e_Pn3aWHxVl4CiwKF3DwPQ>
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 19:09:37 -0000

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> 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
> 
> On 11/4/19 4:20 PM, internet-drafts@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Relay User Machine WG of the IETF.
>>         Title           : Interoperability Profile for Relay User Equipment
>>         Author          : Brian Rosen
>> 	Filename        : draft-ietf-rum-rue-01.txt
>> 	Pages           : 28
>> 	Date            : 2019-11-04
>> Abstract:
>>    Video Relay Service (VRS) is a term used to describe a method by
>>    which a hearing persons can communicate with deaf/Hard of Hearing
>>    user using an interpreter ("Communications Assistant") connected via
>>    a videophone to the deaf/HoH user and an audio telephone call to the
>>    hearing user.  The CA interprets using sign language on the
>>    videophone link and voice on the telephone link.  Often the
>>    interpreters may be supplied by a company or agency termed a
>>    "provider" in this document.  The provider also provides a video
>>    service that allows users to connect video devices to their service,
>>    and subsequently to CAs and other dead/HoH users.  It is desirable
>>    that the videophones used by the deaf/HoH/H-I user conform to a
>>    standard so that any device may be used with any provider and that
>>    video calls direct between deaf/HoH users work.  This document
>>    describes the interface between a videophone and a provider.
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-rum-rue/
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-rum-rue-01
>> https://datatracker.ietf.org/doc/html/draft-ietf-rum-rue-01
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-01
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
> 
> --
> Rum mailing list
> Rum@ietf.org
> https://www.ietf.org/mailman/listinfo/rum