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

Matthew Kaufman <matthew.kaufman@skype.net> Sat, 17 September 2011 03:45 UTC

Return-Path: <matthew.kaufman@skype.net>
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 C1AD221F8B94 for <rtcweb@ietfa.amsl.com>; Fri, 16 Sep 2011 20:45:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.792
X-Spam-Level:
X-Spam-Status: No, score=-4.792 tagged_above=-999 required=5 tests=[AWL=0.738, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_MED=-4]
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 E+xQSaSlR41G for <rtcweb@ietfa.amsl.com>; Fri, 16 Sep 2011 20:45:58 -0700 (PDT)
Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 13E9121F8B44 for <rtcweb@ietf.org>; Fri, 16 Sep 2011 20:45:58 -0700 (PDT)
Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 047917FE; Sat, 17 Sep 2011 05:48:14 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mx; bh=beWWcilJDy4OSv mcafwZUrvBopQ=; b=xRKXMb2QH9JZsKxqEH8JbQIqXI4QeGCdS/6QD+aiakOsxn 8M7kuy3HKnIO1ESFvmrO0zhi+bimcUOAEs2Wzi2Kl86frGv7yAGP/gew3OzR+IMK FunkJSXoTDO7/kW/6x6pA72o3F9kVqhWnRcvL62ZsOPdFrVA2/So6Oio6uVPA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type: content-transfer-encoding; q=dns; s=mx; b=YdR1AjcvF8bWc+8q+tx33Q iW/PZjJq+KloztH3SXVUAdD9xO6ldsLHvfIxJ9VL0cb0CSIpzZcuBx1N4nfQR8yK i6lGo6F0MqmJH9FuI44X9A1DXsB32Xy83EpVjiIQXNrWqvRl3CiLGDBsMI7zdFjJ TC0OGq47DGjt6zvFvEomM=
Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 02DBD7FC; Sat, 17 Sep 2011 05:48:14 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id D67863506E9B; Sat, 17 Sep 2011 05:48:13 +0200 (CEST)
X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net
Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSaO0isX3fex; Sat, 17 Sep 2011 05:48:13 +0200 (CEST)
Received: from dhcp-209.braemoor.net (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 181903506E99; Sat, 17 Sep 2011 05:48:11 +0200 (CEST)
Message-ID: <4E73BBC8.7070507@skype.net>
Date: Fri, 16 Sep 2011 23:12:40 +0200
From: Matthew Kaufman <matthew.kaufman@skype.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Harald Alvestrand <harald@alvestrand.no>
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>
In-Reply-To: <4E71F90D.8030302@alvestrand.no>
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: Sat, 17 Sep 2011 03:45:58 -0000

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.

For example: forcing the Opus codec to "music" mode no matter what the 
input.

Matthew Kaufman