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

Iñaki Baz Castillo <ibc@aliax.net> Thu, 15 September 2011 10:47 UTC

Return-Path: <ibc@aliax.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 28EE121F84DC for <rtcweb@ietfa.amsl.com>; Thu, 15 Sep 2011 03:47:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.65
X-Spam-Level:
X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 4qPrZC-vhDwk for <rtcweb@ietfa.amsl.com>; Thu, 15 Sep 2011 03:47:17 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEA821F84D9 for <rtcweb@ietf.org>; Thu, 15 Sep 2011 03:47:17 -0700 (PDT)
Received: by qyk32 with SMTP id 32so4862896qyk.10 for <rtcweb@ietf.org>; Thu, 15 Sep 2011 03:49:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.67.148 with SMTP id r20mr791209qci.64.1316083768677; Thu, 15 Sep 2011 03:49:28 -0700 (PDT)
Received: by 10.229.79.207 with HTTP; Thu, 15 Sep 2011 03:49:28 -0700 (PDT)
In-Reply-To: <4E71927C.1090606@skype.net>
References: <CALiegfnOCxyTo9ffQ272+ncdu5UdgrtDT-dn10BWGTZMEjZoCg@mail.gmail.com> <4E71927C.1090606@skype.net>
Date: Thu, 15 Sep 2011 12:49:28 +0200
Message-ID: <CALiegfnEaYVsZpKQOoVtT=2gGCzssX79pxLGo7H2Ez0GcMTG-A@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Matthew Kaufman <matthew.kaufman@skype.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 10:47:18 -0000

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.


-- 
Iñaki Baz Castillo
<ibc@aliax.net>;