Re: [Rum] Codec requirements in draft-rosen-rue-01
Richard Shockey <richard@shockey.us> Tue, 27 August 2019 22:34 UTC
Return-Path: <richard@shockey.us>
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 375E612011F for <rum@ietfa.amsl.com>; Tue, 27 Aug 2019 15:34:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us
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 qElvahv3gUfj for <rum@ietfa.amsl.com>; Tue, 27 Aug 2019 15:34:04 -0700 (PDT)
Received: from gateway24.websitewelcome.com (gateway24.websitewelcome.com [192.185.50.84]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 884EF12004D for <rum@ietf.org>; Tue, 27 Aug 2019 15:34:04 -0700 (PDT)
Received: from cm11.websitewelcome.com (cm11.websitewelcome.com [100.42.49.5]) by gateway24.websitewelcome.com (Postfix) with ESMTP id 026083E24 for <rum@ietf.org>; Tue, 27 Aug 2019 17:34:02 -0500 (CDT)
Received: from box5527.bluehost.com ([162.241.218.19]) by cmsmtp with SMTP id 2k2LiBSYodnCe2k2LiZPEi; Tue, 27 Aug 2019 17:34:01 -0500
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:CC:To:From:Subject:Date:Sender:Reply-To: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=BLKsXuwDDu1eYDDz6bSRmZ/AQejrw3kQ/WjtS3XIp70=; b=WzTh3nbinM2LIxMAKHIbs1ylft 2+wypRjyUPGkq06Qh66nKm3LUEtymVJH8FPWaqd0VlSWalmMeKgi3ActA0LFQCPS60133aihjdU0M 8izP1hkBmWeYf+JVwEExGrM5D;
Received: from pool-100-36-47-17.washdc.fios.verizon.net ([100.36.47.17]:53118 helo=[192.168.1.156]) by box5527.bluehost.com with esmtpa (Exim 4.92) (envelope-from <richard@shockey.us>) id 1i2k2L-000tCp-G7; Tue, 27 Aug 2019 17:34:01 -0500
User-Agent: Microsoft-MacOutlook/10.1c.0.190812
Date: Tue, 27 Aug 2019 18:34:00 -0400
From: Richard Shockey <richard@shockey.us>
To: Adam Roach <adam@nostrum.com>, Brian Rosen <br@brianrosen.net>, Paul Kyzivat <pkyzivat@alum.mit.edu>
CC: rum@ietf.org
Message-ID: <DDDB1F3E-23D7-4DDE-8E10-A41BA768B716@shockey.us>
Thread-Topic: [Rum] Codec requirements in draft-rosen-rue-01
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>
In-Reply-To: <fa8e7a65-d818-58eb-a432-f8a57ed6af95@nostrum.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box5527.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - shockey.us
X-BWhitelist: no
X-Source-IP: 100.36.47.17
X-Source-L: No
X-Exim-ID: 1i2k2L-000tCp-G7
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-36-47-17.washdc.fios.verizon.net ([192.168.1.156]) [100.36.47.17]:53118
X-Source-Auth: richard+shockey.us
X-Email-Count: 1
X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NTUyNy5ibHVlaG9zdC5jb20=
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/Ctc7ekAQIUPwiw9xeT92aNnmYSg>
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 22:34:07 -0000
+1 to Adam's excellent comments. — Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richard<at>shockey.us Skype-Linkedin-Facebook –Twitter rshockey101 PSTN +1 703-593-2683 On 8/27/19, 5:57 PM, "Rum on behalf of Adam Roach" <rum-bounces@ietf.org on behalf of adam@nostrum.com> 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. 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 >> >> -- Rum mailing list Rum@ietf.org https://www.ietf.org/mailman/listinfo/rum
- [Rum] Let's get into it Brian Rosen
- Re: [Rum] Let's get into it Olle E. Johansson
- Re: [Rum] Let's get into it Gunnar Hellström
- Re: [Rum] Let's get into it Brian Rosen
- Re: [Rum] [EXT] Let's get into it Janett, Amy E.
- Re: [Rum] Let's get into it Brian Rosen
- [Rum] RUE NAT Traversal in draft-rosen-rue-01 Paul Kyzivat
- [Rum] RUE client credentials Paul Kyzivat
- [Rum] Codec requirements in draft-rosen-rue-01 Paul Kyzivat
- Re: [Rum] Let's get into it Olle E. Johansson
- Re: [Rum] RUE client credentials Brian Rosen
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Brian Rosen
- Re: [Rum] Let's get into it Brian Rosen
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Adam Roach
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Richard Shockey
- Re: [Rum] RUE client credentials Paul Kyzivat
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Paul Kyzivat
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Brian Rosen
- Re: [Rum] RUE client credentials Brian Rosen
- Re: [Rum] RUE client credentials Paul Kyzivat
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Eric Burger
- Re: [Rum] RUE client credentials Brian Rosen
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Brian Rosen
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Paul Kyzivat
- Re: [Rum] RUE client credentials Paul Kyzivat
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Adam Roach
- Re: [Rum] Codec requirements in draft-rosen-rue-01 James Hamlin
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Paul Kyzivat
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Brian Rosen
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Gunnar Hellström
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Brian Rosen
- Re: [Rum] Codec requirements in draft-rosen-rue-01 James Hamlin
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Brian Rosen
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Eric Burger
- Re: [Rum] Codec requirements in draft-rosen-rue-01 James Hamlin
- [Rum] Media security Paul Kyzivat
- [Rum] Distinguishing RUE and Provider requirements Paul Kyzivat
- Re: [Rum] Media security Paul Kyzivat
- Re: [Rum] Media security DOLLY, MARTIN C
- Re: [Rum] Media security Brian Rosen
- Re: [Rum] Media security Paul Kyzivat
- Re: [Rum] Media security Paul Kyzivat
- Re: [Rum] Media security Chris Wendt
- Re: [Rum] Media security Eric Burger
- Re: [Rum] Media security Paul Kyzivat
- Re: [Rum] Distinguishing RUE and Provider require… James Hamlin
- Re: [Rum] Distinguishing RUE and Provider require… Brian Rosen
- Re: [Rum] Distinguishing RUE and Provider require… Eric Burger
- Re: [Rum] Distinguishing RUE and Provider require… James Hamlin
- Re: [Rum] Distinguishing RUE and Provider require… Brian Rosen
- Re: [Rum] Distinguishing RUE and Provider require… Keith Drage
- Re: [Rum] Distinguishing RUE and Provider require… Eric Burger
- Re: [Rum] Distinguishing RUE and Provider require… Gunnar Hellström