Re: [rtcweb] About defining a signaling protocol for WebRTC (or not)

"Timothy B. Terriberry" <tterriberry@mozilla.com> Sun, 18 September 2011 11:24 UTC

Return-Path: <prvs=235fd4aa8=tterriberry@mozilla.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7FB21F857D for <rtcweb@ietfa.amsl.com>; Sun, 18 Sep 2011 04:24:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.228
X-Spam-Level:
X-Spam-Status: No, score=-1.228 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, MISSING_HEADERS=1.292]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TV2AM4iVCnJa for <rtcweb@ietfa.amsl.com>; Sun, 18 Sep 2011 04:24:16 -0700 (PDT)
Received: from mxip1i.isis.unc.edu (mxip1i.isis.unc.edu [152.2.0.74]) by ietfa.amsl.com (Postfix) with ESMTP id AF5F521F856B for <rtcweb@ietf.org>; Sun, 18 Sep 2011 04:24:16 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap4EAKbUdU6sGgRa/2dsb2JhbABBpkWBeYFTAQEEAThAAQULCyEWDwkDAgECAUUTAQcCh3MEtRmGeASHb5BlEoww
X-IronPort-AV: E=Sophos;i="4.67,546,1309752000"; d="scan'208";a="237741975"
Received: from mr2a.isis.unc.edu (HELO smtp.unc.edu) ([172.26.4.90]) by mxip1o.isis.unc.edu with ESMTP; 18 Sep 2011 07:26:36 -0400
X-UNC-Auth-As: tterribe
X-UNC-Auth-IP: 69.181.137.38
Received: from [172.17.0.5] (c-69-181-137-38.hsd1.ca.comcast.net [69.181.137.38]) (authenticated bits=0) by smtp.unc.edu (8.14.4/8.14.3) with ESMTP id p8IBQWos029814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rtcweb@ietf.org>; Sun, 18 Sep 2011 07:26:35 -0400 (EDT)
Message-ID: <4E75D566.7090302@mozilla.com>
Date: Sun, 18 Sep 2011 04:26:30 -0700
From: "Timothy B. Terriberry" <tterriberry@mozilla.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101120 Gentoo/2.0.10 SeaMonkey/2.0.10
MIME-Version: 1.0
CC: rtcweb@ietf.org
References: <CALiegfnOCxyTo9ffQ272+ncdu5UdgrtDT-dn10BWGTZMEjZoCg@mail.gmail.com> <4E71927C.1090606@skype.net> <CALiegfnEaYVsZpKQOoVtT=2gGCzssX79pxLGo7H2Ez0GcMTG-A@mail.gmail.com> <0BF9ED5E-5B73-4316-AE95-0D85B73CBD19@phonefromhere.com> <CALiegfnE9G_vxXDha7pb57pmd=rovLOz=-uWTOirSPDV-pLyMg@mail.gmail.com> <20110915140248.4cc17977@lminiero-acer> <4E71F90D.8030302@alvestrand.no> <4E73BBC8.7070507@skype.net> <4E75A730.8030405@alvestrand.no>
In-Reply-To: <4E75A730.8030405@alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or not)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Sep 2011 11:24:17 -0000

> I haven't seen the definitions for signalling Opus in SDP, so don't know
> if such a capability is described there (which may or may not illustrate
> your point).

It's described in Section 7 of the current payload draft: 
https://datatracker.ietf.org/doc/draft-spittka-payload-rtp-opus/

There's no facility for forcing a "music" mode in the SDP because this 
can be done unilaterally by the encoder, as Opus currently requires 
decoder support for all modes to avoid negotiation failure. Also, as 
I've said before, this is about more than just the encoding format. It 
has (arguably more important) ramifications for the front-end filtering 
done on the input audio signal (i.e., whether or not you're sending 
input from a low-quality mic vs. the direct output of a synth or even 
pre-recorded/generated content).

What we proposed before was a simple means of passing in a "hints" 
object (whether a JS object of some undetermined form or a string or 
something else) which could be used to control optional parameters like 
these. That's sufficient for the "music mode" case, where support on the 
encoder side is optional and you don't really need to know if it 
succeeded (i.e., it's not something that will show up in the SDP, 
whether it's generated by the browser or by script). I don't think it's 
sufficient for Matthew.