Re: [Rum] Distinguishing RUE and Provider requirements

Brian Rosen <br@brianrosen.net> Mon, 04 November 2019 15:33 UTC

Return-Path: <br@brianrosen.net>
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 2A8281209BD for <rum@ietfa.amsl.com>; Mon, 4 Nov 2019 07:33:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.787
X-Spam-Level:
X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 DXfwCQdJGYjv for <rum@ietfa.amsl.com>; Mon, 4 Nov 2019 07:33:26 -0800 (PST)
Received: from mail-yw1-xc32.google.com (mail-yw1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD009120059 for <rum@ietf.org>; Mon, 4 Nov 2019 07:33:25 -0800 (PST)
Received: by mail-yw1-xc32.google.com with SMTP id d5so7073483ywk.9 for <rum@ietf.org>; Mon, 04 Nov 2019 07:33:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=D2AHkmog2LLC/7N82jqqoPSmTzrMld5LqIoikez6X/E=; b=RdQ3NOWwtmmzZkT82x7vfDgxI4o+3KkaLrdFIFr/KF99LWyoK16qxViy37p5Qar7c2 m4S9i2ztCY+knFw6fglZdKoERsT3A2l8nIjbC/sygQpKVSk+FB8L1M7TUpXDN3YTNWT/ 9sM1o0kOA+i8XR+JmlqShsPWiYBtCNjtQy3JjxJj18MKH1A9LLwBphx/dE+xzAq4LmzH c5lbQTaVfz57+1FRouISVRDJBRr/y/uEO6roTBlBLahHd5/+xcBT788ryZaIhLAfgfDi +rqX+KQV6NBZCrrvQMqh324zliZ6Be8rcSX0hbC5AeWD7gm/9dk6kKt5D9CMdHD5PHvr V+QA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=D2AHkmog2LLC/7N82jqqoPSmTzrMld5LqIoikez6X/E=; b=rC8OomlrO8lDxjlAwy6udvd1nvjep8WGBFvaqt9K07spWoAhr6RGpWhJQiIcyoORBw WDkjfHOdtOx7zgp1/fY5SnKzKpGmjGjg6FyHeO5y0Neys/gM8bjQqp7cZnv4q7crA/YQ wTE5Ixk65uAjByRdGGv4i2oXJD1+uAeKheGYZrH90yPucR/4SSQA7yuM1PKzcXBC8BQd W2vHnkg0GL1D4SXp+3DYtaSrvtN0iXR5J5hi31EItFQ/ZaxEm3iqhlc4OAS3St2vffSQ 3GO+HMuQRM/vsWNcy80sbo/unxyRYCS7w+4bOFQTMnib/jZDfVZYqF91zFHQHunu0TYL 0hhg==
X-Gm-Message-State: APjAAAUp7fwPlcBq6AW1URGW/tBToEkUyPHpTbItDga4FOnc2TG1USd0 cVRCEAf4PStsNVUXErbnQ79B4w==
X-Google-Smtp-Source: APXvYqypDMhYm6K7Hf+mrFM+6LdPwXm9xgI/znWvwF9TVNgwSd9YxgaCdRg3U3TDr97WhgZNebtjfg==
X-Received: by 2002:a81:69c6:: with SMTP id e189mr155942ywc.367.1572881603748; Mon, 04 Nov 2019 07:33:23 -0800 (PST)
Received: from brians-mbp-2707.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id q124sm19242511ywq.8.2019.11.04.07.33.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Nov 2019 07:33:22 -0800 (PST)
From: Brian Rosen <br@brianrosen.net>
Message-Id: <9717D87D-A48F-47C3-AD75-5908BAF7A649@brianrosen.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0DF57979-F841-4A72-9B2E-018F05D16965"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 04 Nov 2019 10:33:21 -0500
In-Reply-To: <1572872182151.78082@purple.us>
Cc: "rum@ietf.org" <rum@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
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>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/MkCbjHBEvkkL5ENRmEmBl-AFvuo>
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:33:28 -0000

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> 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
> Date: Mon, 12 Aug 2019 16:20:51 -0400
> From: Paul Kyzivat <pkyzivat@alum.mit.edu>
> To: 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
> 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>