Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)])

"Ravindran Parthasarathi" <pravindran@sonusnet.com> Mon, 26 September 2011 19:50 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 8BB3B1F0CCF for <rtcweb@ietfa.amsl.com>; Mon, 26 Sep 2011 12:50:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.347
X-Spam-Level:
X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 ZZbdy6d5G0DU for <rtcweb@ietfa.amsl.com>; Mon, 26 Sep 2011 12:49:59 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 782D41F0CCD for <rtcweb@ietf.org>; Mon, 26 Sep 2011 12:49:59 -0700 (PDT)
Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p8QJr5nF022001; Mon, 26 Sep 2011 15:53:05 -0400
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 15:52:33 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Tue, 27 Sep 2011 01:22:30 +0530
Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F1089@sonusinmail02.sonusnet.com>
In-Reply-To: <CALiegf=nyXUJrMxTB=u8qTPMkEicCjqG2yi97t2Ri0pa6FgcVQ@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)])
Thread-Index: Acx8gxdFWYT6x7fVTD6GagRPu5DTGAAAf52Q
References: <CALiegfnOCxyTo9ffQ272+ncdu5UdgrtDT-dn10BWGTZMEjZoCg@mail.gmail.com><2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com><05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com><2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com><16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com><8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com><CA+9kkMAwnnKKO5+q6ey4Z0QNxax1QF21vVtw8FNsHy_rmfenjQ@mail.gmail.com><4E76E078.5020708@jesup.org><8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com><4E77495E.4000409@jesup.org><CALiegfkTdCAeEdZbXP1Y9L6i4Anjrgf1CG6ZNj35WGoHL3p_Ew@mail.gmail.com><4E774F92.4040405@jesup.org><8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com><4E778F1F.9090105@jesup.org><CEA0AC9E-6387-4066-95DC-0D70302E80A7@ag-projects.com><4E77C3EC.9060801@jesup.org><CAD5OKxtciYxaVpb7b3G9yMg1A97b9dkjkOpppZcSRzS5SAO3+A@mail.gmail.com><DB86C19C-781C-4FD2-ADE2-D6E1C0EE1D61@ag-projects.com><2E239D6FCD033C4BAF15F386A979BF510F1086@sonus inmail02 .sonusnet.co m><CALiegfmWrNEN03VN0=C6q_ptf=oHCxAMqPoeHis6eNdzreHm9A@mail.gmail.com><2E239D6FCD033C4BAF15F386A979BF510F1088@sonusinmail02.sonusnet.com> <CALiegf=nyXUJrMxTB=u8qTPMkEicCjqG2yi97t2Ri0pa6FgcVQ@mail.gmail.com>
From: Ravindran Parthasarathi <pravindran@sonusnet.com>
To: Iñaki Baz Castillo <ibc@aliax.net>
X-OriginalArrivalTime: 26 Sep 2011 19:52:33.0827 (UTC) FILETIME=[D5514730:01CC7C85]
Cc: rtcweb@ietf.org, Jozsef Vass <jovass@adobe.com>
Subject: Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)])
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, 26 Sep 2011 19:50:00 -0000

Hi Inaki,

<snip> 
Ok, but such protocol should be carried within HTTP or WebSocket, rather than being a native SIP/XMPP/whatever-custom-protocol built-in the web browsers. Do we agree on this? I think the answer is "not", so please continue reading. </snip>

Your assumption is wrong here. When I ask for standard signaling protocol, websocket will be one of the alternative to considered for further discussion in case there is an agreement for having standard signaling protocol.

Thanks
Partha

>-----Original Message-----
>From: Iñaki Baz Castillo [mailto:ibc@aliax.net]
>Sent: Tuesday, September 27, 2011 1:03 AM
>To: Ravindran Parthasarathi
>Cc: Jozsef Vass; Saúl Ibarra Corretgé; rtcweb@ietf.org
>Subject: Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol
>[was RE: About defining a signaling protocol for WebRTC (or not)])
>
>Hi Ravindran, comments inline:
>
>
>2011/9/26 Ravindran Parthasarathi <pravindran@sonusnet.com>:
>> The aim of having standard RTCWeb signaling protocol is to make basic
>dialog between two different browsers (For ex: Mozilla & chrome) user.
>
>And me and others already said that the aim of WebRTC is not
>converting web browsers into generic SIP phones capable of
>establishing a call between them without visiting the same page
>(replace "SIP" with whichever protocol).
>
>WebRTC adds value to the WWW world, so it's assumed that first of all,
>browsers visit some website, so they can get something (JavaScript
>code).
>
>
>
>> Having seeing the list discussion on signaling intricacies in this
>alias, it is no point in asking each web developer to create their own
>signaling protocol. It is better for IETF to recommend one protocol
>which best suit RTCWeb signaling requirement and best simple API for
>signaling protocol will be defined by W3C.
>
>Ok, but such protocol should be carried within HTTP or WebSocket,
>rather than being a native SIP/XMPP/whatever-custom-protocol built-in
>the web browsers. Do we agree on this? I think the answer is "not", so
>please continue reading.
>
>
>
>>>Ravindran, you insist of that even when multiple comments tell you the
>>>opposite. If Mozilla, Chrome or IE browsers are visiting the *same*
>>>website then they *already* share the *same* JavaScript (loaded from
>>>the website) so they can signal the media thought the web server (by
>>>using HTTP or WebSocket) as defined in the retrieved JavaScript code.
>>>This is easy to understand IMHO and this is how WWW works for years =>
>>>interoperability between clients visiting the same website. Period.
>>>
>> <partha> WWW works with plugin. If you think otherwise, there is no
>much
>> Work for IETF in this WG </partha>
>
>AFAIK one of the aims of WebRTC is allowing multimedia sessions within
>browsers *without* the need of external plugins (like Flash or Java
>applets).
>
>
>
>
>>>If the browsers speak *native* SIP (as you suggest in many threads)
>> <partha> I asked initially because it is defacto recommended IETF
>> real-time protocol </partha>
>
>I'm sure that fans of XMPP would not like that (even less taking into
>account that XMPP is much more deployed in pure Internet than SIP).
>
>
>
>>>then the web server is unaware of what is happening at media level
>>>between the visitors (because the web server, where the application
>>>logic is, does not see the signaling traffic).
>
>> <partha> IMO, it is your bad assumption. There are "n" number of way
>to
>> Design server even if they speak different protocol which is a common
>> Practice in gateway implementation </partha>
>
>So you want a "built-in protocol" not to bore web developers with
>custom and complex signaling protocols, but at the same time you want
>to force them to build a hyper-complex gateway in server side. ¿?¿?
>
>
>
>>>> Here, there is a need of defining the common underlying protocol
>>>(which is not RTCWeb developer concern).
>>>
>>>No, it's not.
>> <partha> There is a strong need to define signaling protocol which
>helps
>> Browsers to interop and also reduce the complexity for web developers
></partha>
>
>Again: browsers MUST not *directly* interop with other browsers in the
>*signaling* plane. If two browsers visit the same page and download
>the *same* JavaScript, such JS already can say the browsers how to
>signal the media.
>
>Please, don't insist on the same again and again. There is NO need at
>all for web browsers to natively and directly speak
>SIP/XMPP/other-protocol between them. In fact, that is undesirable.
>
>
>
>>  You can repeat 1000 times by ignoring any rationale
>>>already replied to you in multiple threads. But that changes nothing.
>>>WebRTC does not need native SIP or native XMPP/Jingle spoken by web
>>>browsers. In fact, that would stop innovation, would mandate website
>>
>> <partha> I have clarified multiple time that your innovation is not
>going
>> to stop by defining standard signaling protocol. Let say X protocol
>become
>> standard signaling protocol which does not mean that you should not
>> implement your SIP over websocket using Javascript. So, this is false
>> propaganda by few folks that it would stop innovation. </partha>
>
>Ok. But in other mails you propose that WebRTC should be an island for
>web browsers. Wouldn't that stop innovation?
>
>
>
>>>admins to provide a SIP/XMPP server within their infrastructure (how!)
>>>and would make WebRTC unfeasible in shared web hostings.
>
>> <partha> In case you talking about manageability of the servers, lot
>of more
>> Stuff involved than simple protocol decision </partha>
>
>No. What I meant is very clear: if the signaling (or the "default
>signaling" as you propose) is not carried via HTTP or WebSocket, then
>it would require another kind of centralized server (as a SIP proxy in
>the provider side). So all those websites hosted in shared hosting
>datacenters (i.e. using a shared Apache with different virtual
>domains) would have no chance to use WebRTC. Just it.
>
>
>
>Regards.
>
>
>--
>Iñaki Baz Castillo
><ibc@aliax.net>