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

Tim Panton <tim@phonefromhere.com> Thu, 15 September 2011 11:47 UTC

Return-Path: <tim@phonefromhere.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 43BDC21F8A66 for <rtcweb@ietfa.amsl.com>; Thu, 15 Sep 2011 04:47:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.417
X-Spam-Level:
X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 rI6r8e5Fnxe8 for <rtcweb@ietfa.amsl.com>; Thu, 15 Sep 2011 04:47:42 -0700 (PDT)
Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 95BD821F8A35 for <rtcweb@ietf.org>; Thu, 15 Sep 2011 04:47:42 -0700 (PDT)
Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 481A837A902; Thu, 15 Sep 2011 13:02:44 +0100 (BST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: Tim Panton <tim@phonefromhere.com>
In-Reply-To: <CALiegfnEaYVsZpKQOoVtT=2gGCzssX79pxLGo7H2Ez0GcMTG-A@mail.gmail.com>
Date: Thu, 15 Sep 2011 12:49:48 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <0BF9ED5E-5B73-4316-AE95-0D85B73CBD19@phonefromhere.com>
References: <CALiegfnOCxyTo9ffQ272+ncdu5UdgrtDT-dn10BWGTZMEjZoCg@mail.gmail.com> <4E71927C.1090606@skype.net> <CALiegfnEaYVsZpKQOoVtT=2gGCzssX79pxLGo7H2Ez0GcMTG-A@mail.gmail.com>
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= <ibc@aliax.net>
X-Mailer: Apple Mail (2.1084)
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: Thu, 15 Sep 2011 11:47:43 -0000

On 15 Sep 2011, at 11:49, Iñaki Baz Castillo wrote:

> 2011/9/15 Matthew Kaufman <matthew.kaufman@skype.net>;:
>> On 9/14/11 4:56 PM, Iñaki Baz Castillo wrote:
>>> 
>>> So my proposal is that WebRTC should not mandate a signaling protocol
>>> in the web-browser, but just define a requeriment for managing
>>> multimedia sessions from the JavaScript code given a well defined API.
>> 
>> I think this is exactly what I've been advocating, so I agree as well.
>> 
>> I'd go one step further to say that the "well defined API" shouldn't be "SDP
>> offer/answer via events" for negotiating codec parameters, but should
>> instead be a way to manage the codec settings, with offer/answer or capneg
>> or whatever you want implemented in the Javascript (or up at the server,
>> your choice).
> 
> Hi Matthew,
> 
> You mean a way to simplify the "SDP management" from the JavaScript
> code, am I right?
> 
> The web-browser JavaScript stack could include a native library to
> parse a SDP body (maybe plain SDP as defined in RFC 4566 and also the
> XML version used in XMPP/Jingle) so it returns some kind of JS
> struct/object describing the peer-requested streams (something easier
> than full understanding of SDP).
> 
> An also another native JS function to generate a SDP (plain or XML)
> given some arguments (enable-audio, enable-video, and so on) to be
> included in a custom signaling message (which could also be SIP or
> XMPP).
> 
> Also functions for adding/modifying/deleting a stream, and callbacks
> for the case in which the remote puts on hold a specific stream,
> adds/modifies/deletes a stream...
> 
> This is: make an API that exposes SDP capabilities without requiring
> understanding of the complex RFC 4566 (SDP).
> 
> Regards.
> 

Are we saying that SDP is so impossible to parse that the only way to do it 
is with a pre-existing native library ?!? If not I think we can do that transformation 
(when needed) in JavaScript.

Tim.