Re: [Rum] Distinguishing RUE and Provider requirements

Eric Burger <eburger@standardstrack.com> Mon, 04 November 2019 15:40 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 4711D12011F for <rum@ietfa.amsl.com>; Mon, 4 Nov 2019 07:40:11 -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 rj7wbut4clDf for <rum@ietfa.amsl.com>; Mon, 4 Nov 2019 07:40:09 -0800 (PST)
Received: from se2h-iad1.servconfig.com (se2h-iad1.servconfig.com [173.231.248.14]) (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 A3DD3120059 for <rum@ietf.org>; Mon, 4 Nov 2019 07:40:07 -0800 (PST)
Received: from biz221.inmotionhosting.com ([192.145.239.201]) by se2-iad1.servconfig.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <eburger@standardstrack.com>) id 1iReSZ-000p9N-Th; Mon, 04 Nov 2019 10:40:06 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=References:To:Cc:In-Reply-To:Date:Subject: Mime-Version:Content-Type:Message-Id:From:Sender:Reply-To: 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=DTBM4F4Ib8Rj6cnoNdlyNb2m9oTn1mAPyDwxKpEeFU4=; b=nP+2K1U5H51hXcHjUSyap6BLS NnciLm5szku10CYWg5axXEsx+0BbXVZfvQFW7OP49ndM99zmIPY1iI8oWai+pySgNQvYkMzp2lznQ aCPENdRLo8avgfewv88BvJFaLMMq47L8N2OCzAsIlJls5VZ6kD81ziUUkEwOw5qmxfTmk=;
Received: from [68.100.101.142] (port=55703 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 1iReSN-008cyd-Po; Mon, 04 Nov 2019 07:40:01 -0800
From: Eric Burger <eburger@standardstrack.com>
Message-Id: <47E7BD6C-228D-450F-9ADE-9C0D7B2277DB@standardstrack.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_C0A92CC4-8D3F-43C2-8B20-708084E25046"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 4 Nov 2019 10:39:50 -0500
In-Reply-To: <9717D87D-A48F-47C3-AD75-5908BAF7A649@brianrosen.net>
Cc: "rum@ietf.org" <rum@ietf.org>
To: James Hamlin <james.hamlin@purple.us>
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>
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.20)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0T9zDZOvA8ND4p2eQxdfzLSpSDasLI4SayDByyq9LIhV5A5MuVOp9Z2U EYOZCABgOUTNWdUk1Ol2OGx3IfrIJKyP9eGNFz9TW9u+Jt8z2T3KolohdCareyYbWmFep1exAV9P lAesokVg3jNHgiYgRTdAAkYNWIZc4CEoEQyhkgbIYqCUHa/O2f03ccvc4udUy+oSFEnLJ3qbZezm EhJ0DP+MkoDuFrPitXrzfc3LunNO1NzJstk/+MU4J4Bj4VlpSqMOoXX5fJvY0utudjmIwpWDwIE7 VKe+bqpcdCns72R1i8IkqtBDfnptd+O88Wco3NR+DdnrwvskcoON058HD2zBPeWxfLTyo52lpUOn 40xHoOAmb0xgXrrQKITtclJwwjxIPj1UU4msT2Odp9D6f/Om/kpOWQV1ILff1+qZar/CZdONW7YG NNLfGcEBhKT67in6qlqha0Y0xOrC0oKJayXZ4xpigOktCp6Xcz12tfjFPd0rEuGjFyZoidhtHm+W oc6nupiPjhQgU9sE8qxvsgFPllhwmpUqBNKA1vl3TeEVy4Cn30yIJe57hjvyCVNd+NjlDHh8k6TT dHl8m1/8O/+GvmcnNbFGJXJDA267gIcXUePzKlgT7nf2gslOW/qYlEPaH0KjF7gGlUEJ7nk3oRwh QAIQ5et22ZT5N/xSt/8wfw9Iu3+cTZQWELHXZ53QpOuBao01fuCU3KKy7V29JS+eQU2uLDwK0L5k v1ZIxv247yFM015AwIoiYphoS1Bbkt8Kb64hZj5rDChGG+AZazqX4r4EHP/bH0943j/PXcbeK1Er w36W35MdVm3ym1PL6suK5m+AJX137KLiRi0UNhYjK276cqRj/irry+maIlr5UV8ShebT8U8Xw9HT DfreWRzOCwmhufC0yyDslfsd/0F3IDm/HRygThaWEL2ieGf3tTGCCuNRA7nfehhpFlADuVYFFTdd m9QrX4oe+PynZ9pOP34VGRo5L8M2MA2Zvy07JAE2EFOCe5qsOiWijuxWmKeiqzwpJQJp5aGHp7lT CYo05g8jPjKcxrullDiGL8ca25PCDQ75yqH4NK+K9kSQkQ7ojIz0U1VjckyeztAlrQcxL7hrJSk6 0SF3F6RYOYr2
X-Report-Abuse-To: spam@se1-lax1.servconfig.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/HKRJOMCj6YycX974-JX1w1fK4Pk>
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: Mon, 04 Nov 2019 15:40:11 -0000

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> 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 <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 <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 <https://www.ietf.org/mailman/listinfo/rum>
> --
> Rum mailing list
> Rum@ietf.org
> https://www.ietf.org/mailman/listinfo/rum