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: =?UTF-8?Q?I=C3=B1aki_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>