Re: [rtcweb] No Plan
Iñaki Baz Castillo <ibc@aliax.net> Fri, 31 May 2013 12:35 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 6735221F9425 for <rtcweb@ietfa.amsl.com>; Fri, 31 May 2013 05:35:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.378
X-Spam-Level:
X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, MIME_8BIT_HEADER=0.3, NO_RELAYS=-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 eDnBC5Trkzgm for <rtcweb@ietfa.amsl.com>; Fri, 31 May 2013 05:35:56 -0700 (PDT)
Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1F821F9473 for <rtcweb@ietf.org>; Fri, 31 May 2013 05:35:56 -0700 (PDT)
Received: by mail-qa0-f41.google.com with SMTP id bn16so450477qab.14 for <rtcweb@ietf.org>; Fri, 31 May 2013 05:35:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=YpzkFvRjvpu8dv/Bt8/UutPP3MHhDXSa7CDxZBY3fZs=; b=YYGh8sbmYKbSPad93As2clnjjQcIeldknWPbf9gns1o86+WgTdRq5wB9bCS3QNosNU 3GunHAxhDJBumtJHomBIoswzhK/QZy9EU7HFyIpgzmuYw0OGI3gm1CQWOM1idcUemkpo MWlQU61YeT5MxYweA0Wn0WqBNJ8TMfDKoIXNuMYKTljKVxFJUtF1fz+ebwSGnf2vFVa0 tH9dhMlCWq192CR1BnYo5YAEdM/b8NzNfyIzwuDsK+C+8VMpR1DKSXevxX85sEJXqM+p DVtg5qvSAenHR5o++yhkceBUxgD+rWtazPS5OWcEVKOAHzYD6e+4oTXATYiTXxsD6GQz oyQg==
X-Received: by 10.229.124.80 with SMTP id t16mr235034qcr.93.1370003755525; Fri, 31 May 2013 05:35:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.26.103 with HTTP; Fri, 31 May 2013 05:35:35 -0700 (PDT)
In-Reply-To: <51A835D7.9060603@omnitor.se>
References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <CALiegfk6XchF4U1Orpd6oJsydz-VGtBQ=CwaWrPa_KjsaQynYQ@mail.gmail.com> <51A7CD81.2060805@gmail.com> <51A835D7.9060603@omnitor.se>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Fri, 31 May 2013 14:35:35 +0200
Message-ID: <CALiegfm4R=3mGqTOxBfvCfnsRg=fe=XapA6s-QQNjrsAkg5HEA@mail.gmail.com>
To: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlKO/+cmj6lLQG+aidBtFNqnX5nKZeG/8h4bp9kP6wosu88gVmNmXk7LFaGqUxYGNgTuMEu
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] No Plan
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: Fri, 31 May 2013 12:35:57 -0000
> I do not understand why modern communication users accept to see a > chat state indication of "composing" instead of really seeing what text is > composed. With real-time text you get rid of the frustration that > "composing" creates. > Now, this was not meant to be a repetition of the motivations for real-time > text, but a discussion on interoperability requirements and sdp handling. That can be implemented on top of DataChannel anyway, I see no need for mandating it as a new RTP media stream negotiated via SDP. > I also do not share Iñaki's view that rtcweb is all about communication > between a server and a client delivered by that server, so that text > communication is a local thing between that server and client. We have > agreed that rtcweb must not be the continuation of building silos. Users of > different providers and servers will want to have communication with each > other, and that creates a need for explicit standards for session > establishment and media stream establishment. Really? I don't think so. I will share a secret: the famous SIP trapezoid will never take place in WebRTC (it does not exist neither in SIP anyway). Can you open a user session into Facebook and chat or share content with a Google+ or Twitter use? for sure NOT. The same for RTC communication. If you are logged into Facebook, how will you tell your Facebook WebRTC user interface to "open a multimedia session" with a Google+ user? It seems that non-web people still think that Alice will be able to log into her website www.atlanta.com and initiate an audio/video "call" with Bob, logged into www.biloxi.com (two separate and independent websites). That will never occur. This is the WWW, not the PSTN in which the "media channel" is the communication base between users of different "providers" (with the extra cool feature of DTMFs). Not here, not in WWW. Please, take a look to the current WWW scenario. The same will be true when WebRTC is widely deployed. Another secret: Alice and Bob use Skype to communicate one to each other (when at least one of them is at home), and they both connect via SIP to the same PBX at work, and when they work in remote places, there is one or two SBC between them. The SIP trapezoid just exists in RFC's and our imaginations and will never exist in WebRTC. Same for WebRTC. I insist: a Facebook user cannot initiate a chat with a Google+ user, so he won't be able to establish a media session with him when both websites provide WebRTC capabilities. Really. > Real-time text is one of the > basic media together with audio and video which need to be fully defined for > such interoperability. Facebook, Google+, Twitter and any other website use their own custom mechanisms for providing chat capabilities to *their own* users *between them*. I don't expect that they will be interested in a peer-to-peer (user-to-user) realtime text because they want to log the messages, inspect them, offer you advertisements based on the content of your "private" chats, etc. Really, WebRTC is not the new PSTN, and there is no need at all to waste time thinking about "interoperability" between different WebRTC islands. In fact there won't be WebRTC islands but Web islands (as today), and WebRTC will be just a new "feature" provide by those web islands for their users. Probably some website (i.e. www.example-A.com) will let you sending an "invitation URL" to any contact (i.e. via mail) so the receipt of the invitation will open the URL and will get automatically "logged" or "authorized" into www.example-A.com for having a multimedia session with the first user (note that both users will use a WebRTC JavaScript app provided by the same website www.example-A.com). That's all. But Alice logged into www.example-A.com won't be able to make a "call" to Bob logged into www.example-B.com. Saying the opposite goes against the facts provided by the WWW during long years. Best regards. -- Iñaki Baz Castillo <ibc@aliax.net>
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Bernard Aboba
- Re: [rtcweb] No Plan Sergio Garcia Murillo
- [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Richard Barnes
- Re: [rtcweb] No Plan Cullen Jennings
- Re: [rtcweb] No Plan Peter Saint-Andre
- Re: [rtcweb] No Plan Martin Thomson
- [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Mary Barnes
- Re: [rtcweb] No Plan Peter Saint-Andre
- Re: [rtcweb] No Plan Christer Holmberg
- Re: [rtcweb] No Plan Stefan Håkansson LK
- Re: [rtcweb] No Plan Enrico Marocco
- Re: [rtcweb] No Plan Bernard Aboba
- Re: [rtcweb] No Plan Stefan Håkansson LK
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Enrico Marocco
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan - PT based MUX Cullen Jennings
- Re: [rtcweb] No Plan Gunnar Hellstrom
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] No Plan Sergio Garcia Murillo
- Re: [rtcweb] No Plan Gunnar Hellstrom
- Re: [rtcweb] No Plan Sergio Garcia Murillo
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] No Plan Cullen Jennings (fluffy)
- Re: [rtcweb] No Plan Mark Rejhon
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Cullen Jennings (fluffy)
- [rtcweb] RTT (was Re: No Plan) Matthew Kaufman
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Matthew Kaufman
- Re: [rtcweb] RTT (was Re: No Plan) Paul Kyzivat
- Re: [rtcweb] No Plan Stefan Håkansson LK
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] RTT (was Re: No Plan) Gunnar Hellstrom
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Christer Holmberg
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Barry Dingle
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- [rtcweb] Translating Plan A into No Plan (Was: No… Emil Ivov
- Re: [rtcweb] Translating Plan A into No Plan (Was… Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Eric Rescorla
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] Translating Plan A into No Plan (Was… Martin Thomson
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] RTT (was :No Plan ) Paul Kyzivat
- Re: [rtcweb] No Plan - but what's the proposal Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Paul Kyzivat
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Emil Ivov
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] Translating Plan A into No Plan (Was… Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Jonathan Lennox
- Re: [rtcweb] No Plan Jim Barnett
- Re: [rtcweb] Translating Plan A into No Plan (Was… Roni Even
- Re: [rtcweb] No Plan Bernard Aboba
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Christer Holmberg
- [rtcweb] Repair Flows and No Plan (Was: No Plan) Emil Ivov
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] RTT (was :No Plan ) BeckW
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] Repair Flows and No Plan (Was: No Pl… Sergio Garcia Murillo
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Silvia Pfeiffer
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- [rtcweb] Plan xyz discussions; MMUSIC <> RTCweb R… Flemming Andreasen
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Peter Thatcher