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

"Ravindran Parthasarathi" <> Tue, 06 September 2011 18:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 30CCF21F8B5E for <>; Tue, 6 Sep 2011 11:05:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.489
X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id InV1BsuCUsvb for <>; Tue, 6 Sep 2011 11:04:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BF65621F8B28 for <>; Tue, 6 Sep 2011 11:04:58 -0700 (PDT)
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p86I7Brq003928; Tue, 6 Sep 2011 14:07:11 -0400
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Sep 2011 14:06:41 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6CBF.B93E88BC"
Date: Tue, 06 Sep 2011 23:36:35 +0530
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [rtcweb] Usecase & architecture: Browser application with separate webserver & voipserver
Thread-Index: AcxsRmig665lmf8XSfGdZFBIXE6VJAAdCW6Q
References: <>, <> <BLU152-W72696F07F16816B1B267593100@phx.gbl> <> <>
From: Ravindran Parthasarathi <>
To: Matthew Kaufman <>
X-OriginalArrivalTime: 06 Sep 2011 18:06:41.0720 (UTC) FILETIME=[BAE7AB80:01CC6CBF]
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 18:05:02 -0000



Please read inline.





From: Matthew Kaufman [] 
Sent: Tuesday, September 06, 2011 9:07 AM
To: Ravindran Parthasarathi
Cc: Bernard Aboba;;
Subject: Re: [rtcweb] Usecase & architecture: Browser application with
separate webserver & voipserver


On 9/5/2011 12:16 PM, Ravindran Parthasarathi wrote: 



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


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

[Partha]Browser A supports WebRTC Javascript API which is mapped to
Jingle. Browser A is not required to have native support of Jingle. I
guess that we mean the same thing.

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.

[Partha] Here is the problem, it is expected that webserver1 has to
converts its proprietary stuff into SIP or other equivalent. So, RTCweb
to SIP gateway is mandated in your proposed architecture for the basic
dialog between two users in two webservers. It will be tough for each
webserver developer to create the proprietary protocol and mapping.
Instead, the basic SIP functionality provided in browser will make sure
the basic call works between any users across webserver without limiting
the innovative application build by individual webservers.

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.

[Partha] it is bad network design because SIP is well accepted in
real-time applications (telecom or unified communication) and also there
is no need of contract with each site (company) and implement their
protocol to interop with 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.

[Partha] This paradigm will not exactly fit for real-time communication
because there is a need of communication between browser to browser
apart from webserver to webserver communication. Still I could not under
the reason why SIP will stop the innovation whereas HTTP will allow.

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

[Partha] I'm thinking of the solution which is in line of
draft-cbran-rtcweb-protocols-00. Browser is intelligent entity which
makes real-time communication with other browser using SIP. The
configuration data required for browser SIP client is received through
Javascript and/or received metadata from webserver using HTTP
connection. Making SIP as a protocol for real-time communication will
make sure that browser not only communicates with another browser but
also ensure that it works with existing SIP implementation. It was my
original usecase wherein browser directly communicates with VoIP-server.
VoIP server may communicates with browser which does not matter for the
originating browser.

Matthew Kaufman