Re: [rtcweb] Usecase & architecture: Browser application with separate webserver & voipserver

Matthew Kaufman <> Tue, 06 September 2011 03:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 04E8C21F841A for <>; Mon, 5 Sep 2011 20:36:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.723
X-Spam-Status: No, score=-4.723 tagged_above=-999 required=5 tests=[AWL=1.875, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q-zy4nBpsjBl for <>; Mon, 5 Sep 2011 20:36:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9D59321F8443 for <>; Mon, 5 Sep 2011 20:36:26 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id B16177FC; Tue, 6 Sep 2011 05:38:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to: content-type; s=mx; bh=Zltpt0Yu3SRtnS5eLCtu0KG1vHo=; b=hCu4H0EJH wWpQxnOhrxPW3zO//D63GRZRBdmgOlqRVPziwGKnsIkTHmfUQFu/YNkcmqJwl1uE FQUGzT0c0w3XOGO3vz3roXTnLqrH0zG+IFxfkgj0JSSk1sgdMl+xPf9POzNmUs1Z hnpe0Xv8ZY+BzEx9TQdzlwpDA8rKAtcGsc=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type; q=dns; s=mx; b=EVOPKqneiPmbLvawFS63ukbm+dUU/hdpRR+uUYa+puMR61BX NhzKq0Bnub978j/jZ9XoZCVld6ZWOiUZwBlE+HABDoYIw5QeCpyyR4nKh4zOIZmm Fp2RN32osfFSY/XxnQk0BVHNvDusBq6j8oECOCBb35Zo5yyLdXD76aNmX9A=
Received: from ( []) by (Postfix) with ESMTP id AF61C7F6; Tue, 6 Sep 2011 05:38:08 +0200 (CEST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 888C93507345; Tue, 6 Sep 2011 05:38:08 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gZ2LRSgNnohT; Tue, 6 Sep 2011 05:38:07 +0200 (CEST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 7A0183507061; Tue, 6 Sep 2011 05:38:06 +0200 (CEST)
Message-ID: <>
Date: Mon, 05 Sep 2011 20:37:26 -0700
From: Matthew Kaufman <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: Ravindran Parthasarathi <>
References: <>, <> <BLU152-W72696F07F16816B1B267593100@phx.gbl> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------040105050203060104060003"
Subject: Re: [rtcweb] Usecase & architecture: Browser application with separate webserver & voipserver
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: Tue, 06 Sep 2011 03:36:41 -0000

On 9/5/2011 12:16 PM, Ravindran Parthasarathi wrote:
> Bernard,
> Sorry for the delay reply.
> There is a huge difference between tunneling the protocol and 
> converting the protocol from one format to another. The tunneling 
> works well only in case the destination support the tunneled data 
> without negotiation. It will be bad assumption in case the standard 
> does not defined so.  For example,
> 1)Browser A supports Jingle (XMPP for real-time data) and encapsulates 
> the data in HTTP and send it to webserver1

That isn't how it works. Browser A supports WebRTC. Do you mean browser 
A is running Javascript that implements Jingle or something similar for 
its signaling (over HTTP and/or Websockets) to its associated web server?

> 2)RTCwebserver1 tunnel jingle data in SIP and sends it to RTCwebserver2

Federation between webserver1 and webserver2 is up to the operators of 
those sites. Presumably SIP is a good (but not only) choice for 
federation. Many sites won't have a desire or need to federate.

> 3)RTCwebserver2 does not support Jingle towards browser but it support 
> some other variant of HTTP based metadata to the browser.

Do you mean that webserver2 and its clients are running compatible code 
that exchanges signaling via a mechanism other than Jingle? That's fine, 
and up to the operator of that site.

> My question is how webserver2 do perform the interop correctly in case 
> Jingle is not mandated as metadata standard mechanism. Please let me 
> know your opinion here.

Every site that wishes to federate with others will need to choose a 
signaling protocol that is agreed between them.

> My understanding was that RTCwebserver1 may use some proprietary 
> mechanism (may be jingle) to communicate between browser and webserver 
> which will be converted into RFC 3261 SIP at webserver1 and forwarded 
> to RTCwebserver2. RTCWebserver2 converts back SIP to its own 
> proprietary metadata to communicate with browser. This mechanism works 
> well but still better mechanism exists.

That understanding appears to be correct. This is exactly the same as 
"Hotmail talks some proprietary protocol over HTTP between its 
HTML/Javascript client and its servers which is then converted to SMTP 
for sending to Gmail, where Gmail talks a different proprietary protocol 
over HTTP between its HTML/Javascript client and its servers." It 
appears to have resulted in some significant innovations in the email 
service space, while still allowing federation between domains using a 
standard protocol.

If you think this is a bad idea, provide an alternative we might discuss.

Matthew Kaufman