Re: [rtcweb] Usecase & architecture: Browser application with separate webserver & voipserver
"Ravindran Parthasarathi" <pravindran@sonusnet.com> Tue, 06 September 2011 19:20 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 C26D921F8DDD for <rtcweb@ietfa.amsl.com>; Tue, 6 Sep 2011 12:20:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Level:
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.107, 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 ujO-nhc25Ejb for <rtcweb@ietfa.amsl.com>; Tue, 6 Sep 2011 12:20:17 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id D63DF21F8D57 for <rtcweb@ietf.org>; Tue, 6 Sep 2011 12:20:16 -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 p86JMVgJ020833; Tue, 6 Sep 2011 15:22:31 -0400
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Sep 2011 15:22:01 -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_01CC6CCA.3F4A5792"
Date: Wed, 07 Sep 2011 00:51:56 +0530
Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F086D@sonusinmail02.sonusnet.com>
In-Reply-To: <4E666785.7040409@skype.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] Usecase & architecture: Browser application with separate webserver & voipserver
Thread-Index: Acxsw4j0QEQjeP+zQauUz1nAwB/5WgABA50w
References: <CAM_kxqci51=BnUFe-67Qs4eCxtGY50HDsRPrLjYULnBZJoH0Ow@mail.gmail.com>, <2E239D6FCD033C4BAF15F386A979BF5106436F@sonusinmail02.sonusnet.com> <BLU152-W72696F07F16816B1B267593100@phx.gbl> <2E239D6FCD033C4BAF15F386A979BF51064707@sonusinmail02.sonusnet.com> <4E659576.1000301@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F0868@sonusinmail02.sonusnet.com> <4E666785.7040409@skype.net>
From: Ravindran Parthasarathi <pravindran@sonusnet.com>
To: Matthew Kaufman <matthew.kaufman@skype.net>
X-OriginalArrivalTime: 06 Sep 2011 19:22:01.0503 (UTC) FILETIME=[40E7D2F0:01CC6CCA]
Cc: rtcweb@ietf.org
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: Tue, 06 Sep 2011 19:20:21 -0000
Matthew, Please read inline. Thanks Partha From: Matthew Kaufman [mailto:matthew.kaufman@skype.net] Sent: Wednesday, September 07, 2011 12:04 AM To: Ravindran Parthasarathi Cc: Bernard Aboba; hoang.su.tk@gmail.com; rtcweb@ietf.org Subject: Re: [rtcweb] Usecase & architecture: Browser application with separate webserver & voipserver On 9/6/11 11:06 AM, Ravindran Parthasarathi wrote: Matthew, Please read inline. Thanks Partha From: Matthew Kaufman [mailto:matthew.kaufman@skype.net] Sent: Tuesday, September 06, 2011 9:07 AM To: Ravindran Parthasarathi Cc: Bernard Aboba; hoang.su.tk@gmail.com; rtcweb@ietf.org Subject: Re: [rtcweb] Usecase & architecture: Browser application with separate webserver & voipserver 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, 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? [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. Sounds like 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. Disagree. It is expected that webserver1 usually *doesn't* convert its proprietary stuff into SIP. That only happens when you want to federate with another service that uses SIP. If it is "tough" to create a mapping between your proprietary stuff and SIP then perhaps you didn't design your proprietary stuff properly... that isn't my problem however. Basic SIP functionality provided in the browser would likely limit the API in ways that block innovation. [Partha] we discussed in another mail thread for providing Javascript API which helps to add SIP proprietary headers. 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. SIP is well accepted in *some* real-time applications. I would note that the most popular real-time applications don't actually use SIP. [Partha] Those mentioned popular real-time applications will never interop with any other popular real-time application and also IETF or other standard is not required for those real-time applications. And yet there is SIP, for when you wish to interop without lengthy contract or discussion. The best of both worlds. 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. Because SIP requires standards activities before adding any useful functionality. I'll point to one of my favorites here: bridged line appearances. Despite lots of effort to fix this, there still isn't a way to do this reliably. And yet, if I created a web application using HTTP signaling and Javascript APIs on a web browser that provides a *platform* and not just a "phone", I could create a system in which bridged line appearances work well if I so desired with just a little bit of programming. [Partha] In case you write some bridged line appearance which will not work my implementation of bridged line appearance. Hope you agree here. My point is that atleast basic scenario is taken as part of IETF bliss WG. Even I have mentioned earlier for the basic call in SIP because I know that supplementary services are not going to work easily. But most of the user uses basic call. If you think this is a bad idea, provide an alternative we might discuss. [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. So you want the browser to be a phone, and not a platform for innovation in the area of real-time applications. It is already a platform for innovation in many other areas, why limit it here? [Partha] My intention is not to make browser as SIP phone. SIP is a real-time communication protocol which helps to innovate application which obsoletes legacy phones using browser. I'm asking why not take advantage of SIP in the browser. Matthew Kaufman
- [rtcweb] Some misunderstandings about <Usecase & … Nguyen Duong Tuan
- Re: [rtcweb] Some misunderstandings about <Usecas… Ravindran Parthasarathi
- Re: [rtcweb] Some misunderstandings about <Usecas… Bernard Aboba
- Re: [rtcweb] Some misunderstandings about <Usecas… Nguyen Duong Tuan
- Re: [rtcweb] Usecase & architecture: Browser appl… Ravindran Parthasarathi
- Re: [rtcweb] Usecase & architecture: Browser appl… Matthew Kaufman
- Re: [rtcweb] Usecase & architecture: Browser appl… Ravindran Parthasarathi
- Re: [rtcweb] Usecase & architecture: Browser appl… Matthew Kaufman
- Re: [rtcweb] Usecase & architecture: Browser appl… Ravindran Parthasarathi
- [rtcweb] Bridged line appearance? (Re: Usecase & … Harald Alvestrand
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Matthew Kaufman
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Matthew Kaufman
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Cullen Jennings
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Cullen Jennings
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Tim Panton
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Paul Kyzivat
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Mary Barnes
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Matthew Kaufman
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Matthew Kaufman
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Matthew Kaufman
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Paul Kyzivat
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Paul Kyzivat
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Asveren, Tolga
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Paul Kyzivat