Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)])
Iñaki Baz Castillo <ibc@aliax.net> Mon, 26 September 2011 19:30 UTC
Return-Path: <ibc@aliax.net>
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 DE1FA1F0C88 for <rtcweb@ietfa.amsl.com>; Mon, 26 Sep 2011 12:30:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.636
X-Spam-Level:
X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 Pb7KRPrT9qQM for <rtcweb@ietfa.amsl.com>; Mon, 26 Sep 2011 12:30:07 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0307E1F0C7C for <rtcweb@ietf.org>; Mon, 26 Sep 2011 12:30:06 -0700 (PDT)
Received: by vcbfo11 with SMTP id fo11so4325962vcb.31 for <rtcweb@ietf.org>; Mon, 26 Sep 2011 12:32:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.171.208 with SMTP id i16mr1012599vcz.122.1317065569203; Mon, 26 Sep 2011 12:32:49 -0700 (PDT)
Received: by 10.220.94.200 with HTTP; Mon, 26 Sep 2011 12:32:49 -0700 (PDT)
In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F1088@sonusinmail02.sonusnet.com>
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@sonusinmail02.sonusnet.com> <CALiegfmWrNEN03VN0=C6q_ptf=oHCxAMqPoeHis6eNdzreHm9A@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF510F1088@sonusinmail02.sonusnet.com>
Date: Mon, 26 Sep 2011 21:32:49 +0200
Message-ID: <CALiegf=nyXUJrMxTB=u8qTPMkEicCjqG2yi97t2Ri0pa6FgcVQ@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
To: Ravindran Parthasarathi <pravindran@sonusnet.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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:30:08 -0000
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>
- Re: [rtcweb] About defining a signaling protocol … Bernard Aboba
- [rtcweb] About defining a signaling protocol for … Iñaki Baz Castillo
- Re: [rtcweb] About defining a signaling protocol … Henry Sinnreich
- Re: [rtcweb] About defining a signaling protocol … Roman Shpount
- Re: [rtcweb] About defining a signaling protocol … Victor Pascual
- Re: [rtcweb] About defining a signaling protocol … Prakash
- Re: [rtcweb] About defining a signaling protocol … Saúl Ibarra Corretgé
- [rtcweb] About defining a signaling protocol for … gao.yang2
- Re: [rtcweb] About defining a signaling protocol … Avasarala, Ranjit
- Re: [rtcweb] About defining a signaling protocol … Matthew Kaufman
- Re: [rtcweb] About defining a signaling protocol … Ravindran Parthasarathi
- Re: [rtcweb] About defining a signaling protocol … Soo-Hyun Choi
- Re: [rtcweb] About defining a signaling protocol … José Luis Millán
- Re: [rtcweb] About defining a signaling protocol … Saúl Ibarra Corretgé
- Re: [rtcweb] About defining a signaling protocol … Iñaki Baz Castillo
- Re: [rtcweb] About defining a signaling protocol … Tim Panton
- Re: [rtcweb] About defining a signaling protocol … Iñaki Baz Castillo
- Re: [rtcweb] About defining a signaling protocol … Lorenzo Miniero
- Re: [rtcweb] About defining a signaling protocol … Iñaki Baz Castillo
- Re: [rtcweb] About defining a signaling protocol … Harald Alvestrand
- Re: [rtcweb] About defining a signaling protocol … Henry Sinnreich
- [rtcweb] RTCWeb default signaling protocol [was R… Ravindran Parthasarathi
- Re: [rtcweb] RTCWeb default signaling protocol [w… Roman Shpount
- Re: [rtcweb] RTCWeb default signaling protocol [w… Hadriel Kaplan
- Re: [rtcweb] RTCWeb default signaling protocol [w… Jim McEachern
- Re: [rtcweb] RTCWeb default signaling protocol [w… Avasarala, Ranjit
- Re: [rtcweb] RTCWeb default signaling protocol [w… Saúl Ibarra Corretgé
- Re: [rtcweb] RTCWeb default signaling protocol [w… Saúl Ibarra Corretgé
- Re: [rtcweb] RTCWeb default signaling protocol [w… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] RTCWeb default signaling protocol [w… Iñaki Baz Castillo
- Re: [rtcweb] RTCWeb default signaling protocol [w… Iñaki Baz Castillo
- Re: [rtcweb] RTCWeb default signaling protocol [w… Tim Panton
- [rtcweb] SDP offer/answer vs. JSON (was: About de… Hadriel Kaplan
- Re: [rtcweb] RTCWeb default signaling protocol [w… Ted Hardie
- Re: [rtcweb] RTCWeb default signaling protocol [w… cbran
- Re: [rtcweb] RTCWeb default signaling protocol [w… Hadriel Kaplan
- Re: [rtcweb] RTCWeb default signaling protocol [w… Stephan Wenger
- Re: [rtcweb] RTCWeb default signaling protocol [w… Matthew Kaufman
- Re: [rtcweb] About defining a signaling protocol … Matthew Kaufman
- Re: [rtcweb] RTCWeb default signaling protocol [w… Matthew Kaufman
- Re: [rtcweb] ICE and security Olle E. Johansson
- Re: [rtcweb] RTCWeb default signaling protocol [w… Olle E. Johansson
- Re: [rtcweb] ICE and security Dzonatas Sol
- Re: [rtcweb] ICE and security Hadriel Kaplan
- Re: [rtcweb] RTCWeb default signaling protocol [w… Hadriel Kaplan
- Re: [rtcweb] ICE and security Dzonatas Sol
- Re: [rtcweb] ICE and security Eric Rescorla
- Re: [rtcweb] About defining a signaling protocol … Harald Alvestrand
- Re: [rtcweb] ICE and security Harald Alvestrand
- Re: [rtcweb] About defining a signaling protocol … Timothy B. Terriberry
- Re: [rtcweb] ICE and security Dzonatas Sol
- Re: [rtcweb] RTCWeb default signaling protocol [w… Ravindran Parthasarathi
- Re: [rtcweb] RTCWeb default signaling protocol [w… Randell Jesup
- Re: [rtcweb] RTCWeb default signaling protocol [w… Randell Jesup
- Re: [rtcweb] RTCWeb default signaling protocol [w… José Luis Millán
- Re: [rtcweb] RTCWeb default signaling protocol [w… Hadriel Kaplan
- Re: [rtcweb] RTCWeb default signaling protocol [w… Markus.Isomaki
- Re: [rtcweb] RTCWeb default signaling protocol [w… Randell Jesup
- Re: [rtcweb] ICE and security Dan Wing
- Re: [rtcweb] RTCWeb default signaling protocol [w… Olle E. Johansson
- Re: [rtcweb] RTCWeb default signaling protocol [w… Iñaki Baz Castillo
- Re: [rtcweb] RTCWeb default signaling protocol [w… Randell Jesup
- Re: [rtcweb] RTCWeb default signaling protocol [w… Eric Rescorla
- Re: [rtcweb] SDP offer/answer vs. JSON (was: Abou… Henry Sinnreich
- Re: [rtcweb] RTCWeb default signaling protocol [w… Jim McEachern
- Re: [rtcweb] RTCWeb default signaling protocol [w… Randell Jesup
- Re: [rtcweb] RTCWeb default signaling protocol [w… Saúl Ibarra Corretgé
- Re: [rtcweb] SDP offer/answer vs. JSON Magnus Westerlund
- [rtcweb] Data Transport, was: Re: RTCWeb default … Magnus Westerlund
- Re: [rtcweb] RTCWeb default signaling protocol [w… Igor Faynberg
- Re: [rtcweb] Data Transport, was: Re: RTCWeb defa… Olle E. Johansson
- Re: [rtcweb] Data Transport, was: Re: RTCWeb defa… Timothy B. Terriberry
- Re: [rtcweb] RTCWeb default signaling protocol [w… Dzonatas Sol
- Re: [rtcweb] RTCWeb default signaling protocol [w… Randell Jesup
- Re: [rtcweb] RTCWeb default signaling protocol [w… Randell Jesup
- Re: [rtcweb] Data Transport, was: Re: RTCWeb defa… Harald Alvestrand
- Re: [rtcweb] RTCWeb default signaling protocol [w… Saúl Ibarra Corretgé
- Re: [rtcweb] RTCWeb default signaling protocol [w… Randell Jesup
- Re: [rtcweb] RTCWeb default signaling protocol [w… Matthew Kaufman
- Re: [rtcweb] RTCWeb default signaling protocol [w… Roman Shpount
- Re: [rtcweb] RTCWeb default signaling protocol [w… Ravindran Parthasarathi
- Re: [rtcweb] RTCWeb default signaling protocol [w… Hadriel Kaplan
- Re: [rtcweb] RTCWeb default signaling protocol [w… Randell Jesup
- Re: [rtcweb] RTCWeb default signaling protocol [w… Hadriel Kaplan
- Re: [rtcweb] RTCWeb default signaling protocol [w… Saúl Ibarra Corretgé
- Re: [rtcweb] RTCWeb default signaling protocol [w… Randell Jesup
- Re: [rtcweb] RTCWeb default signaling protocol [w… Iñaki Baz Castillo
- Re: [rtcweb] RTCWeb default signaling protocol [w… Hadriel Kaplan
- Re: [rtcweb] RTCWeb default signaling protocol [w… Olle E. Johansson
- Re: [rtcweb] RTCWeb default signaling protocol [w… Ravindran Parthasarathi
- Re: [rtcweb] RTCWeb default signaling protocol [w… Hadriel Kaplan
- Re: [rtcweb] RTCWeb default signaling protocol [w… Olle E. Johansson
- Re: [rtcweb] RTCWeb default signaling protocol [w… Iñaki Baz Castillo
- Re: [rtcweb] RTCWeb default signaling protocol [w… Iñaki Baz Castillo
- Re: [rtcweb] RTCWeb default signaling protocol [w… Ravindran Parthasarathi
- Re: [rtcweb] RTCWeb default signaling protocol [w… José Luis Millán
- Re: [rtcweb] Data Transport, was: Re: RTCWeb defa… Magnus Westerlund
- Re: [rtcweb] RTCWeb default signaling protocol [w… Ted Hardie
- Re: [rtcweb] RTCWeb default signaling protocol [w… Dzonatas Sol
- Re: [rtcweb] SDP offer/answer vs. JSON (was: Abou… Elwell, John
- Re: [rtcweb] SDP offer/answer vs. JSON Dzonatas Sol
- Re: [rtcweb] SDP offer/answer vs. JSON Dzonatas Sol
- Re: [rtcweb] RTCWeb default signaling protocol [w… Henry Sinnreich
- [rtcweb] "20 lines" (Re: RTCWeb default signaling… Harald Alvestrand
- Re: [rtcweb] Data Transport, was: Re: RTCWeb defa… Harald Alvestrand
- Re: [rtcweb] Data Transport, was: Re: RTCWeb defa… Iñaki Baz Castillo
- Re: [rtcweb] Data Transport, was: Re: RTCWeb defa… Iñaki Baz Castillo
- Re: [rtcweb] Data Transport, was: Re: RTCWeb defa… Colin Perkins
- Re: [rtcweb] "20 lines" (Re: RTCWeb default signa… Hadriel Kaplan
- Re: [rtcweb] Data Transport, was: Re: RTCWeb defa… Hadriel Kaplan
- Re: [rtcweb] Data Transport, was: Re: RTCWeb defa… Colin Perkins
- Re: [rtcweb] Data Transport, was: Re: RTCWeb defa… Hadriel Kaplan
- Re: [rtcweb] Data Transport, was: Re: RTCWeb defa… Olle E. Johansson
- Re: [rtcweb] Data Transport, was: Re: RTCWeb defa… Saúl Ibarra Corretgé
- Re: [rtcweb] Data Transport, was: Re: RTCWeb defa… Iñaki Baz Castillo
- Re: [rtcweb] Data Transport, was: Re: RTCWeb defa… Randell Jesup
- [rtcweb] SCTP for data channels in rtcweb Randell Jesup
- Re: [rtcweb] SCTP for data channels in rtcweb Randell Jesup
- Re: [rtcweb] RTCWeb default signaling protocol [w… Ravindran Parthasarathi
- Re: [rtcweb] RTCWeb default signaling protocol [w… Roman Shpount
- Re: [rtcweb] RTCWeb default signaling protocol [w… Iñaki Baz Castillo
- Re: [rtcweb] RTCWeb default signaling protocol [w… Randell Jesup
- Re: [rtcweb] "20 lines" (Re: RTCWeb default signa… Jozsef Vass
- Re: [rtcweb] "20 lines" (Re: RTCWeb default signa… Roman Shpount
- Re: [rtcweb] "20 lines" (Re: RTCWeb default signa… Saúl Ibarra Corretgé
- Re: [rtcweb] "20 lines" (Re: RTCWeb default signa… Iñaki Baz Castillo
- Re: [rtcweb] "20 lines" (Re: RTCWeb default signa… Iñaki Baz Castillo
- Re: [rtcweb] "20 lines" (Re: RTCWeb default signa… Jozsef Vass
- Re: [rtcweb] "20 lines" (Re: RTCWeb default signa… Jozsef Vass
- Re: [rtcweb] "20 lines" (Re: RTCWeb default signa… Iñaki Baz Castillo
- Re: [rtcweb] "20 lines" (Re: RTCWeb default signa… Ravindran Parthasarathi
- Re: [rtcweb] "20 lines" (Re: RTCWeb default signa… Iñaki Baz Castillo
- Re: [rtcweb] "20 lines" (Re: RTCWeb default signa… Ravindran Parthasarathi
- Re: [rtcweb] "20 lines" (Re: RTCWeb default signa… Iñaki Baz Castillo
- Re: [rtcweb] "20 lines" (Re: RTCWeb default signa… Ravindran Parthasarathi
- Re: [rtcweb] "20 lines" (Re: RTCWeb default signa… Saúl Ibarra Corretgé
- Re: [rtcweb] RTCWeb default signaling protocol [w… Ravindran Parthasarathi
- Re: [rtcweb] RTCWeb default signaling protocol [w… Iñaki Baz Castillo
- Re: [rtcweb] RTCWeb default signaling protocol [w… Ravindran Parthasarathi
- Re: [rtcweb] RTCWeb default signaling protocol [w… Saúl Ibarra Corretgé
- Re: [rtcweb] RTCWeb default signaling protocol [w… Tim Panton
- Re: [rtcweb] RTCWeb default signaling protocol [w… Randell Jesup
- Re: [rtcweb] RTCWeb default signaling protocol [w… Eric Rescorla
- Re: [rtcweb] RTCWeb default signaling protocol [w… Jim McEachern
- Re: [rtcweb] RTCWeb default signaling protocol [w… Tim Panton
- Re: [rtcweb] RTCWeb default signaling protocol [w… Bernard Aboba
- Re: [rtcweb] RTCWeb default signaling protocol [w… Cullen Jennings
- Re: [rtcweb] RTCWeb default signaling protocol [w… Matthew Kaufman
- Re: [rtcweb] RTCWeb default signaling protocol [w… Randell Jesup
- Re: [rtcweb] RTCWeb default signaling protocol [w… Matthew Kaufman
- Re: [rtcweb] RTCWeb default signaling protocol [w… Randell Jesup
- Re: [rtcweb] RTCWeb default signaling protocol [w… Cameron Byrne
- Re: [rtcweb] RTCWeb default signaling protocol [w… Ravindran Parthasarathi
- Re: [rtcweb] RTCWeb default signaling protocol [w… Ravindran Parthasarathi
- Re: [rtcweb] RTCWeb default signaling protocol [w… Asveren, Tolga
- Re: [rtcweb] RTCWeb default signaling protocol [w… Saul Ibarra Corretge