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

Harald Alvestrand <harald@alvestrand.no> Sun, 18 September 2011 08:07 UTC

Return-Path: <harald@alvestrand.no>
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 153D621F8512 for <rtcweb@ietfa.amsl.com>; Sun, 18 Sep 2011 01:07:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.799
X-Spam-Level:
X-Spam-Status: No, score=-107.799 tagged_above=-999 required=5 tests=[AWL=2.800, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 q0onPF4l3-1c for <rtcweb@ietfa.amsl.com>; Sun, 18 Sep 2011 01:07:04 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6F73321F84D8 for <rtcweb@ietf.org>; Sun, 18 Sep 2011 01:07:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 107B339E0CD; Sun, 18 Sep 2011 10:09:22 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYuuowgGQ-OO; Sun, 18 Sep 2011 10:09:21 +0200 (CEST)
Received: from [192.168.1.51] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 959C939E048; Sun, 18 Sep 2011 10:09:21 +0200 (CEST)
Message-ID: <4E75A730.8030405@alvestrand.no>
Date: Sun, 18 Sep 2011 10:09:20 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13
MIME-Version: 1.0
To: Matthew Kaufman <matthew.kaufman@skype.net>
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>
In-Reply-To: <4E73BBC8.7070507@skype.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
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 08:07:05 -0000

On 09/16/2011 11:12 PM, Matthew Kaufman wrote:
> On 9/15/11 3:09 PM, Harald Alvestrand wrote:
>> The disadvantage of parsing to another structure (I am fond of JSON 
>> myself) is that one has to maintain a data definition for the format 
>> being parsed to, a defined transform between that and the "canonical 
>> SDP structure" has to be implemented in user space when one does SDP 
>> interoperability, both of those have to be updated for every SDP 
>> extension that someone defines somewhere, and one is still not free 
>> to define extensions on the non-SDP side if one still requires the 
>> ability to map them into SDP.
>>
>> If one uses the "native" SDP format, which is the format in which 
>> every extension to the format gets documented, the browsers are the 
>> ones who *have* to parse it (although others are likely to).
>
> Of course what you're also saying here is that it takes a trip to the 
> IETF to make every extension. So if the *only* Javascript API for 
> controlling the codec (or getting its capabilities by triggering an 
> offer) is a pile of SDP in string form, then nothing that hasn't been 
> standardized can be described.
1) No reason that this should be the only interface. I've just argued 
that I think this interface needs to be supported
2) SDP has a relatively clean "ignore what you don't understand" 
extension model. It's not my impression that people who want to deploy 
stuff wait until the standards are done.
>
> For example: forcing the Opus codec to "music" mode no matter what the 
> input.
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).
>
> Matthew Kaufman
>
>