Re: [Rum] Codec requirements in draft-rosen-rue-01

Brian Rosen <br@brianrosen.net> Wed, 28 August 2019 14:38 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 81C29120043 for <rum@ietfa.amsl.com>; Wed, 28 Aug 2019 07:38:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham 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 XwopoZkhhGXa for <rum@ietfa.amsl.com>; Wed, 28 Aug 2019 07:38:11 -0700 (PDT)
Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 A254F1200E3 for <rum@ietf.org>; Wed, 28 Aug 2019 07:38:11 -0700 (PDT)
Received: by mail-qt1-x830.google.com with SMTP id y26so3265912qto.4 for <rum@ietf.org>; Wed, 28 Aug 2019 07:38:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=f/N6OiPUc/Ia94Wx9WQRsX+vLHHju3cPBwxIdDyxSJg=; b=MKMv6C+aUES0Y58QJR4oRPK7M+jGG7aMeHAWodIYgdNIF486WuZKB3TEj4Mtp72vXD YvpE1l+cxToy547Tx5i0f0Dd+611Pg6QWU3BqMdy7nTWma2JykiOgTFI1puWEck4GTIW E0WyVnwE1MBhBC+WqX7DSoVPdKHZA1xV1+qyuDNWeC3n+WZGDGMj1nTPDTMh0ZXrMpZe 5NxMbRP+ttGtHdFeAI6MgF3MD3+LSj0IGy40nA2fxKduvfqppJPE281JibFBgEEFQ+Bw RglKl8AnGs7iCzm9hIG8GFgVdHVsn4/iqEOoaEmcQeotzc54L3EblzFks2huVN0crZ+V reJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=f/N6OiPUc/Ia94Wx9WQRsX+vLHHju3cPBwxIdDyxSJg=; b=DoC3QhRKCWxeAFa9Mf5vaEfz0AI6zyoeCNWYNexmJgMJVFqT7dkNNUJ7dhnmPtHVoN en4lNS7Rwn3/9lKnxglprJ8SOp2NMtbcfC5cKRPikjsqbuF7FiScoSHxGWn0fyiR2Iit U72mXHjmQQWZjIagVTDm/MBXmel168bsH+6s6l73wlGdUZBGGzL0alfRVf+NDd5Orxq1 HZBV9AzY1IpDxaPhD/2QgaBb7ohAwmOrzmQO5m+kQLENkyGC40TXKeIEctf+IBL0CDSy HanaLj8qgdp47ZYBwkAakm8Q3YRc6QXaZj4l4kk3eGnniMk2aAMALQz8BjEgnKOxK7fI 9swA==
X-Gm-Message-State: APjAAAUcHihkCHhuIbvbrKsdxrinKp6hKUW4BYdPfeEbFA5Mb4eORXUm eY5WWPEQs63NXQ+GgZcVdYydJULWEgE=
X-Google-Smtp-Source: APXvYqxIcMhYlb4niF534mq8E95LWVBZQb8gDuiUYhbc55o6n8LtUOanGz6zcyHvTpyizpWGEScnkA==
X-Received: by 2002:ac8:6bca:: with SMTP id b10mr4401663qtt.254.1567003090666; Wed, 28 Aug 2019 07:38:10 -0700 (PDT)
Received: from brians-mbp-2369.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id x5sm1517963qka.7.2019.08.28.07.38.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Aug 2019 07:38:09 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Brian Rosen <br@brianrosen.net>
In-Reply-To: <3fdefa0c-3a64-3445-8ceb-d293fe4b4831@alum.mit.edu>
Date: Wed, 28 Aug 2019 10:38:08 -0400
Cc: Adam Roach <adam@nostrum.com>, rum@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <60DFA478-5042-41FD-87CD-DD2154D6B1E6@brianrosen.net>
References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <a3d82911-8d07-16a3-780b-0592e48e37bd@alum.mit.edu> <69F15B2A-0158-4D23-B090-642497E3BDC7@brianrosen.net> <fa8e7a65-d818-58eb-a432-f8a57ed6af95@nostrum.com> <3fdefa0c-3a64-3445-8ceb-d293fe4b4831@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/hcz4hARnyu2OWuw6p3zLvvb3tzI>
Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01
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, 28 Aug 2019 14:38:14 -0000

If we require OPUS and G.711 as MTI and we require both H.264 and VP8 as MTI, then we get backwards compatibility without transcoding and forwards compatibility with WebRTC.  Isn’t that what we want?

Brian

> On Aug 28, 2019, at 10:15 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> 
> Inline...
> 
> On 8/27/19 5:57 PM, Adam Roach wrote:
>> I certainly have thoughts. The executive summary is that I personally believe RUM should specify Opus as the one audio codec MTI, and match RFC 7742's "Non-Browser" requirements for the video codec MTI. Rationale below.
>> From an interop perspective, the important thing is that any given profile has (at least) one MTI video codec and (at least) one MTI audio codec. I know there is a strong desire -- one that I share -- that these endpoints can talk to/be implemented in web browsers without the need for media transcoding.
>> For audio: WebRTC selected G.711 and Opus as both MTI; the former because it works without transcoding to landline PSTN destinations, and the latter because it sounds much, much better. RUM could make the same decision; or it could decide to move away from a codec that is as old as I am and opt to designate Opus as the only MTI. Given that RUM inherently needs to deploy into audio/video environments, backwards compatibility with the PSTN seems to be unnecessary baggage.
> 
> Please keep in mind where we are coming from. The RUM will be a new interface to the *existing* VRS infrastructure. That infrastructure currently has proprietary devices that serve the RUE function, deployed to VRS users and to Communications Assistants (CAs, Interpreters). These have G.711 MTI, and also *recommend* G.722.2.
> 
> Making OPUS the only MTI audio codec would be problematic.
> 
>> For video: While specifying either VP8 or H.264 would be sufficient for system interop, and for interop with compliant WebRTC endpoints, I'd really prefer not to re-live the WebRTC video codec wars. Concretely, what I would propose is that RUM indicate that the video codec requirements are defined to be identical to those defined for "WebRTC Non-Browsers" in Section 5 of RFC 7742. It should be made clear that RUM endpoints *are* *not* WebRTC Non-Browsers per se; merely that they comply with the same video codec requirements as WebRTC Non-Browsers.
> 
> Continuing my comment above, existing devices have H.264 Constrained Baseline Profile, Level 1.3, packetization mode 1 as the MTI codec. Odds are many of these devices aren't capable of VP8.
> 
> We can't realistically require a wholesale swap out of existing devices before the RUE defined by RUM can work. We can *discuss* whether forcing the providers to transcode is a practical way forward. I'm dubious.
> 
> 	Thanks,
> 	Paul
> 
>> /a
>> On 8/27/19 2:34 PM, Brian Rosen wrote:
>>> Well, we certainly want interoperability, and I think we can only get that with MTI codecs.
>>> 
>>> I think we really are talking about a WebRTC-compatible endpoint, but we want interoperability with a WebRTC browser endpoint.
>>> 
>>> Not sure how to say this.  Maybe Adam can help.
>>> 
>>> Brian
>>> 
>>>> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>>>> 
>>>> 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
>>>> 
>>>> 
>