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

"Ravindran Parthasarathi" <> Mon, 05 September 2011 19:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 81B4B21F8BA6 for <>; Mon, 5 Sep 2011 12:14:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.478
X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oicGBV0mCk3T for <>; Mon, 5 Sep 2011 12:14:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 45CB821F8B80 for <>; Mon, 5 Sep 2011 12:14:29 -0700 (PDT)
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p85JGeJm019674; Mon, 5 Sep 2011 15:16:41 -0400
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Sep 2011 15:16:11 -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_01CC6C00.43F4AACE"
Date: Tue, 06 Sep 2011 00:46:08 +0530
Message-ID: <>
In-Reply-To: <BLU152-W72696F07F16816B1B267593100@phx.gbl>
Thread-Topic: [rtcweb] Usecase & architecture: Browser application with separate webserver & voipserver
Thread-Index: Acxjrn+fkEqucGj3QAyVQKFs0Fq8LwITx5QQ
References: <>, <> <BLU152-W72696F07F16816B1B267593100@phx.gbl>
From: Ravindran Parthasarathi <>
To: Bernard Aboba <>,,
X-OriginalArrivalTime: 05 Sep 2011 19:16:11.0435 (UTC) FILETIME=[45D5EFB0:01CC6C00]
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: Mon, 05 Sep 2011 19:14:30 -0000



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


1)      Browser A supports Jingle (XMPP for real-time data) and
encapsulates the data in HTTP and send it to webserver1

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

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

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.


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.








From: Bernard Aboba [] 
Sent: Friday, August 26, 2011 12:35 AM
To: Ravindran Parthasarathi;;
Subject: RE: [rtcweb] Some misunderstandings about <Usecase &
architecture: Browser application with separate webserver & voipserver>


> The issue in case webserver acts as new RTCWEB & SIP GW for VoIP
> communication, there is a need of protocol mapping between the
> used between browser & RTCWebserver (say RTCweb protocol) to SIP. 
[BA] Not necessarily.  For example, in the case of XMPP, BOSH can be
to encapsulate XMPP over HTTP.  The BOSH Connection Manager/Web server
does not do "mapping", it just encapsulates/decapsulates XMPP stanzas, 
enabling communication between XMPP clients supporting BOSH and 
XMPP servers.   This be handled entirely in Javascript with no native
support for XMPP. 
For detailed examples of how this works (with sample code), please see: