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

Saúl Ibarra Corretgé <> Thu, 15 September 2011 07:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A0DD21F853E for <>; Thu, 15 Sep 2011 00:51:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[AWL=0.067, 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 9du74x6Q4JgJ for <>; Thu, 15 Sep 2011 00:51:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D169521F8532 for <>; Thu, 15 Sep 2011 00:51:06 -0700 (PDT)
Received: by (Postfix, from userid 5001) id 57095B01BB; Thu, 15 Sep 2011 09:53:14 +0200 (CEST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 94C0FB01A2; Thu, 15 Sep 2011 09:53:14 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= <>
In-Reply-To: <>
Date: Thu, 15 Sep 2011 09:53:14 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Ravindran Parthasarathi <>
X-Mailer: Apple Mail (2.1084)
Subject: Re: [rtcweb] 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: Thu, 15 Sep 2011 07:51:07 -0000



> My point is that the default signaling protocol has to be supported in RTCWeb client which should not be downloaded in runtime to make the dialog between two RTCWeb client. I asked for SIP initially as SIP is the de-facto protocol and mostly deployment. I agree with Peter & others that websocket could be another alternative in the web deployment. In case required, I'll come up the write up to show the needs of default signaling protocol for making dialog between browser to browser.

Do you mean there should be a 'default signaling protocol' on every browser? I'm not sure I'd like that. I (personally) see RTCWeb as a framework on top of which we can build RTC applications. The fact that one would use SIP and someone else uses something else is not crucial, IMHO. Now if some new simplified protocol is chosen for browser-to-browser communication we'd have yet another island of devices (browsers in this case) to which we'd need to gateway somehow.


>> WebRTC defines multimedia capabilities for web-browsers and mandates
>> protocols as RTP, STUN, ICE, and understanding of SDP (RFC 4566). The
>> aim of these protocols is to enable multimedia streams between a
>> web-browser and other endpoint (which could also be a web-browser).
> <partha> I hope that the aim of the protocols is to enable multimedia stream between browser to browser only. In case browser to other end-point is outside the scope of RTCWEb. </partha> 

Well, why build a parallel universe just for the browsers? If RTCWeb would only define the media plane and developers themselves can choose the signaling protocol, the integration with existing communication systems (using SIP or XMPP for example since they are the most used ones) would be pretty straight-forward.

My 2 cents.


Saúl Ibarra Corretgé
AG Projects