IETF Logo Mail Archive

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

Matthew Kaufman <matthew.kaufman@skype.net> Thu, 15 September 2011 05:49 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 13E2721F856B for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 22:49:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level:
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 Ml34YS1CWQaR for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 22:49:45 -0700 (PDT)
Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 45ECC21F854F for <rtcweb@ietf.org>; Wed, 14 Sep 2011 22:49:45 -0700 (PDT)
Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 492287FD; Thu, 15 Sep 2011 07:51:55 +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=f4YmqJMk0HSnii yCE2tU9TPsTzY=; b=kAuZsRHUhqDlgWdlZJb01jTvrKY9p9Jq0vUaXEKx+0AJ8z QFsswZhGeDCq9BJeFuOnqPpE2W91R8ZuVGFIKpjcv4kQYi13ZiUMrbw0ITsWRAfk BiEVid8qk1YN2UZ3ysWQb7AJOFrGUb+CNpfxY4+fmoHn6oBZTrZMHjXfGJ/yM=
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=cjMp+t2Lf0L5FMWGJyHKDa oOXpr2pdbQZjmhfn0ipQpHud8CqqAVXqRDgidOec33H0478nCMEl4uVKUqAAqwYh qu2uSt1jKWSBo6qgRVyv/+IdfZYpmEr8uFOXgNyx0NXvQBW9Y/nD0+voldYkz3Uv rBsfWRW/Dh6WHlqvDVoiM=
Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 459137F8; Thu, 15 Sep 2011 07:51:55 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 2BE5F3506F77; Thu, 15 Sep 2011 07:51:55 +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 rPThY9v117VQ; Thu, 15 Sep 2011 07:51:54 +0200 (CEST)
Received: from Matthew-Kaufman-Air.local (gw2.rival.se [83.241.158.140]) by zimbra.skype.net (Postfix) with ESMTPSA id 65D5A3506F54; Thu, 15 Sep 2011 07:51:54 +0200 (CEST)
Message-ID: <4E71927C.1090606@skype.net>
Date: Thu, 15 Sep 2011 07:51:56 +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: Iñaki Baz Castillo <ibc@aliax.net>
References: <CALiegfnOCxyTo9ffQ272+ncdu5UdgrtDT-dn10BWGTZMEjZoCg@mail.gmail.com>
In-Reply-To: <CALiegfnOCxyTo9ffQ272+ncdu5UdgrtDT-dn10BWGTZMEjZoCg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
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 05:49:46 -0000

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).

Matthew Kaufman

v2.23.0 | Report a Bug | By Email