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

Saúl Ibarra Corretgé <> Fri, 16 September 2011 06:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C982921F8BB1 for <>; Thu, 15 Sep 2011 23:54:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.638
X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id At7z1toAOgQJ for <>; Thu, 15 Sep 2011 23:54:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CC07121F8B45 for <>; Thu, 15 Sep 2011 23:54:29 -0700 (PDT)
Received: by (Postfix, from userid 5001) id 67080B01BB; Fri, 16 Sep 2011 08:56:42 +0200 (CEST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 50204B019A; Fri, 16 Sep 2011 08:56:42 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: Saúl Ibarra Corretgé <>
In-Reply-To: <>
Date: Fri, 16 Sep 2011 08:56:41 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Hadriel Kaplan <>
X-Mailer: Apple Mail (2.1084)
Cc: "<>" <>
Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 16 Sep 2011 06:54:30 -0000


On Sep 16, 2011, at 4:24 AM, Hadriel Kaplan wrote:

> There is no need for a "default signaling protocol", because the "signaling" is between the browser's Javascript and its web server.  And as for the signaling protocol the web server has to support in order to speak to other servers or non-RTCweb endpoints, even if we specified to use SIP we'd just be summarily ignored by those who don't want to, because they actually don't *need* to.  It doesn't hurt interoperability of rtcweb if they don't implement SIP - it just means they can't talk to other SIP devices/servers.  But it's not like we need an RFC to say "if you don't implement X then you can't talk to people who do X".
> Think of this RTCWEB concept as Skinny/SCCP.  The Web Server is Call Manager, and the browser is the Skinny phone, but in this case instead of needing a 7960 phone, the Skinny protocol was written in javascript and uses a browser's user interface for its GUI and the built-in RTP library for media. (in fact one could probably write a javascript to do just that, if Call Manager handled SCCP over websocket)  
> Clearly the IETF does not need to define for Cisco a standardized replacement for the SCCP protocol for this to work, because one isn't needed since the client javascript and server are built by the same developers and they know how their proprietary signaling works.  So how about for the signaling Call Manager would use to other VoIP devices, like gateways or VoIP service providers?  Does the IETF need to tell Cisco what peer-to-peer protocol(s) to implement on Call Manager?  No, and we never have.  Cisco's product managers decide that.  They decide if Call Manager needs to be able to communicate a standard protocol at all, such as SIP or H.323, and which one/any of those.  They decide based on their use-cases/need.
> Some rtcweb developers may not do any standard signaling protocol, ever.  For example many Instant Messaging providers still have closed environments to this day. (e.g., AIM, YIM, MSN, etc.)  Some may choose to only use H.323, or XMPP, or IAX, or even BICC.  Some may choose to only support SIP with 3GPP extensions.  Obviously most of us think/hope people do SIP, but really the market makes those types of decisions, not the IETF.  Just like the IETF standardized MGCP but didn't specify what the MGCP Call Agent had to support to speak to other Call Agents.  SIP was given as an example in MGCP, but not mandated.
> The only thing we need to do for rtcweb is make sure the RTP library built into the browser supports media in such a way that it can communicate with other RTP peers at a media plane, regardless of what signaling protocol those peers might be using, preferably without going through media gateways.  And obviously since SIP is a very common protocol and defined by the IETF we need to make sure it's possible to use SIP on the rtcweb server, but we can't *mandate* that it be used or supported, and if we did it wouldn't change anything. 
> -hadriel
> On Sep 15, 2011, at 7:56 PM, Ravindran Parthasarathi wrote:
>> 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. 
>> I specifically asked for the scope of your opinion on RTCWeb work is between browser-to-browser or browser-to-other end-point to know whether parallel universe has to be build or not. In case there is no default signaling protocol, it is impossible to communicate between browser-to-endpoint without gateways. Let us assume that the intention of RTCWeb is to create island of browser devices even then the native signaling protocol for RTCWeb has advantage over Jquery library and plugin is not the solution.
>> 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.
>> Thanks
>> Partha

Saúl Ibarra Corretgé
AG Projects