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

Matthew Kaufman <matthew.kaufman@skype.net> Sat, 17 September 2011 03:54 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 50DD121F8B74 for <rtcweb@ietfa.amsl.com>; Fri, 16 Sep 2011 20:54:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.822
X-Spam-Level:
X-Spam-Status: No, score=-4.822 tagged_above=-999 required=5 tests=[AWL=0.708, 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 a3IwthdCIrRH for <rtcweb@ietfa.amsl.com>; Fri, 16 Sep 2011 20:54:19 -0700 (PDT)
Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id BDAD521F8B73 for <rtcweb@ietf.org>; Fri, 16 Sep 2011 20:54:18 -0700 (PDT)
Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 2F6467FE; Sat, 17 Sep 2011 05:48:17 +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=KUKHFMy4vibz29 5yYMqFFYJs970=; b=FXot+LVVRmI8PXViEl4Rw83w9Qdlc7mTGQGnqO0eLNUSha CdQc+JY9HkgUUhED/uP5TgdI0OwERCyxRyvHdDyKyRrqBJH10lA0CMZivr5I+8bE 7JlUd+ZkG08v3jRRDuvGghrQII7Ty6ICBxgmL9vzHbROV1YYGh7s/eb05rBAg=
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=vDxUMShsfK3oYzRu00YeWS Mh7tYvvGf7PlIpFjavjcQUe9eTb6iGzHsxE19jy2fC8Jddp+3AezKx34PtBtNX/j R+2rFfS5gRalI4+1a9Tvgb4WKKxCSJ1aWg8bwsK3X+6Q4RlqcuQeuTZGZBoaOA5x MTNCcSRVF+BnU4QDxe3Qs=
Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 24F347FC; Sat, 17 Sep 2011 05:48:17 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id E528D3506E9B; Sat, 17 Sep 2011 05:48:16 +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 HR9AJo90J5Qv; Sat, 17 Sep 2011 05:48:16 +0200 (CEST)
Received: from dhcp-209.braemoor.net (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 553523506E99; Sat, 17 Sep 2011 05:48:15 +0200 (CEST)
Message-ID: <4E73C056.2090003@skype.net>
Date: Fri, 16 Sep 2011 23:32:06 +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: Ravindran Parthasarathi <pravindran@sonusnet.com>
References: <CALiegfnOCxyTo9ffQ272+ncdu5UdgrtDT-dn10BWGTZMEjZoCg@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com>
In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: 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:54:22 -0000

On 9/16/11 1:56 AM, Ravindran Parthasarathi wrote:
> Hi Saul,
>
> I really didn't get your argument fully because in case there is no default signaling protocol, it is unavoidable to have island of devices without gateways but you argue other way around.
Browsers cannot talk to each other without at least a web server to 
serve up the application (HTML and Javascript) and a server over which 
to exchange the ICE signaling information, so they won't be talking to 
each other "on their own" anyway.

Once you have that, RTCWEB calling is no more or less an island than 
web-based messaging services. Some of them let users compose messages 
that stay within the "walled garden" of the service (and that is their 
choice), others let users compose email which is exchanged with other 
services over standard protocols like SMTP.

>
> I specifically asked for the scope of your opinion on RTCWeb work is between browser-to-browser

RTCWEB needs to specify the browser-to-browser media and the APIs by 
which that media channel is created and controlled. That is all.

>   or browser-to-other end-point to know whether parallel universe has to be build or not.

For the media channel, it would be helpful if the "browser-to-browser" 
media uses a standard such as RTP so that "browser-to-other" can be done 
directly, without media gateways.

For signaling, this is not nearly so important a requirement, and in 
fact conflicts with the goals of providing flexible APIs that allow 
developers to use web browsers as a development platform... an operating 
system and runtime, rather than a pre-built "phone" as I've said before.

>   In case there is no default signaling protocol, it is impossible to communicate between browser-to-endpoint without gateways.

Signaling? True.

Media? Hopefully not.

>   Let us assume that the intention of RTCWeb is to create island of browser devices

The intention of RTCWeb is to bring real-time communication capabilities 
to the browser environment so that developers may create applications 
that leverage these features. Whether or not that results in an "island" 
will be up to the developers of these applications.

Does "the Linux operating system" create an "island of computer devices" 
because someone else needs to supply the software that lets them play 
real-time games with each other?

>   even then the native signaling protocol for RTCWeb has advantage over Jquery library and plugin is not the solution.

There is no need for a "native signaling protocol for RTCWeb", just a 
standard way of delivering applications (HTTP) and running them in the 
browser (HTML + Javascript)

>
> Having said that, I agree that it is possible to implement RTP or STUN or SIP stack or codec using Javascript or plugins but interop and better performance is not guaranteed.
>
Why is that even necessary for interop? Hotmail didn't write IMAP and 
SMTP in Javascript to make Hotmail work and yet it seems to interoperate 
with the world of SMTP email services just fine.

Matthew Kaufman