IETF Logo Mail Archive

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

"Ravindran Parthasarathi" <pravindran@sonusnet.com> Mon, 05 September 2011 19:14 UTC

Return-Path: <pravindran@sonusnet.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B4B21F8BA6 for <rtcweb@ietfa.amsl.com>; Mon, 5 Sep 2011 12:14:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.478
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oicGBV0mCk3T for <rtcweb@ietfa.amsl.com>; Mon, 5 Sep 2011 12:14:29 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 45CB821F8B80 for <rtcweb@ietf.org>; Mon, 5 Sep 2011 12:14:29 -0700 (PDT)
Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p85JGeJm019674; Mon, 5 Sep 2011 15:16:41 -0400
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com 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: <2E239D6FCD033C4BAF15F386A979BF51064707@sonusinmail02.sonusnet.com>
In-Reply-To: <BLU152-W72696F07F16816B1B267593100@phx.gbl>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] Usecase & architecture: Browser application with separate webserver & voipserver
Thread-Index: Acxjrn+fkEqucGj3QAyVQKFs0Fq8LwITx5QQ
References: <CAM_kxqci51=BnUFe-67Qs4eCxtGY50HDsRPrLjYULnBZJoH0Ow@mail.gmail.com>, <2E239D6FCD033C4BAF15F386A979BF5106436F@sonusinmail02.sonusnet.com> <BLU152-W72696F07F16816B1B267593100@phx.gbl>
From: Ravindran Parthasarathi <pravindran@sonusnet.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>, hoang.su.tk@gmail.com, rtcweb@ietf.org
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-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Sep 2011 19:14:30 -0000

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

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

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.

 

Thanks

Partha

 

 

 

 

From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] 
Sent: Friday, August 26, 2011 12:35 AM
To: Ravindran Parthasarathi; hoang.su.tk@gmail.com; rtcweb@ietf.org
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
protocol
> used between browser & RTCWebserver (say RTCweb protocol) to SIP. 
 
[BA] Not necessarily.  For example, in the case of XMPP, BOSH can be
used
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:
http://professionalxmpp.com/

v2.23.0 | Report a Bug | By Email