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

Adam Roach <adam@nostrum.com> Tue, 27 August 2019 21:57 UTC

Return-Path: <adam@nostrum.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 78C6012021D for <rum@ietfa.amsl.com>; Tue, 27 Aug 2019 14:57:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.98
X-Spam-Level:
X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 Q1IAvDL2hi_f for <rum@ietfa.amsl.com>; Tue, 27 Aug 2019 14:57:52 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 7D12312004D for <rum@ietf.org>; Tue, 27 Aug 2019 14:57:52 -0700 (PDT)
Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x7RLvfAr080483 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 27 Aug 2019 16:57:43 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1566943063; bh=PzPQ9fmOzqiCtD1M57JXhBhMYFTxj+dM/uFjXNO8lso=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=oaNxxpl+WhsVGYnKBmSNqC05Y/zQ8SKkWRP8mjQgTTAdVYPg5mV6DLxxo/q7Cyd+M t4yqjUIyuVLvfgUCNC7WVWwabUQt/+JCpoOUDBoNLdpC8bLxqIZ8gFlESF/tj72xAs 3WKkvR3FcsYU0AGr84ezbntpeAouhC88B8WdkL3o=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at
To: Brian Rosen <br@brianrosen.net>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Cc: rum@ietf.org
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>
From: Adam Roach <adam@nostrum.com>
Message-ID: <fa8e7a65-d818-58eb-a432-f8a57ed6af95@nostrum.com>
Date: Tue, 27 Aug 2019 16:57:36 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <69F15B2A-0158-4D23-B090-642497E3BDC7@brianrosen.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/gDMJJICEu0s7NQEIiLS48B_HMkA>
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: Tue, 27 Aug 2019 21:57:55 -0000

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.

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.

/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
>>
>>