Re: [rtcweb] RTT (was :No Plan )

<BeckW@telekom.de> Tue, 04 June 2013 17:13 UTC

Return-Path: <BeckW@telekom.de>
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 022BD21F9BC3 for <rtcweb@ietfa.amsl.com>; Tue, 4 Jun 2013 10:13:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 Z1OAgckN3CMj for <rtcweb@ietfa.amsl.com>; Tue, 4 Jun 2013 10:13:28 -0700 (PDT)
Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id B957F21F9BA1 for <rtcweb@ietf.org>; Tue, 4 Jun 2013 08:09:44 -0700 (PDT)
Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 04 Jun 2013 17:09:41 +0200
Received: from HE111644.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.13]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 4 Jun 2013 17:09:41 +0200
From: <BeckW@telekom.de>
To: <rtcweb@ietf.org>
Date: Tue, 4 Jun 2013 17:09:39 +0200
Thread-Topic: [rtcweb] RTT (was :No Plan )
Thread-Index: Ac5gns3nuEOTYX32SV2woTuYtAV3GQAj9ibw
Message-ID: <AAE428925197FE46A5F94ED6643478FEAC70553746@HE111644.EMEA1.CDS.T-INTERNAL.COM>
References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <CALiegfk6XchF4U1Orpd6oJsydz-VGtBQ=CwaWrPa_KjsaQynYQ@mail.gmail.com> <51A7CD81.2060805@gmail.com> <51A835D7.9060603@omnitor.se> <CALiegfm4R=3mGqTOxBfvCfnsRg=fe=XapA6s-QQNjrsAkg5HEA@mail.gmail.com> <51A8F3EF.9080702@alum.mit.edu> <CALiegfkfz=qVM_wB21BBOypMTwTjkyG97zAmzHVpA6WHK2DA6w@mail.gmail.com> <51AC7D4F.6090708@omnitor.se> <CALiegfkxfb4qk+bS_EWbcxkNv-BSOwDw6eR-b86Z-hyMY60z3Q@mail.gmail.com> <51AC8547.1060400@omnitor.se> <CALiegfmeQtzAD_=6bPt77zNYC79iKjneycFS5RGssckNwSqptg@mail.gmail.com> <51AD04A4.9010607@alum.mit.edu>
In-Reply-To: <51AD04A4.9010607@alum.mit.edu>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] RTT (was :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: Tue, 04 Jun 2013 17:13:33 -0000

On 6/3/13 8:14 AM, Iñaki Baz Castillo wrote:
> 2013/6/3 Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>se>:
>> The use cases draft includes a case titled:
>>
>> 4.2.10.  Simple video communication service with inter-operator calling
>>
>> See:
>> http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-10#page-9
>
> That will just work if both websites want to offer such a
> inter-website-communication. And that's already feasible. But we don't
> need a new standard (RTT-over-RTP) for allowing two users in different
> websites to intercommunicate via RTT.

In my experience many people have real difficulties to understand that
http://rtc.example.com/user/homer is as universal as is the E.164 number +1 555 3223

In the latter case, I need classical, PSTN-style interconnection between my telephony provider
and the telephony provider owning +1 555 3223.

With proper WebRTC, I simply open a link. Maybe I have to identify myself using
OpenID or a similar 3rd party auth. mechanism. This is up to rtc.example.com.
There's no need to agree on a RTT format, as both parties use the same client.
Works today.

The alternative is:
1. discuss whether RTT should be included into the browsers
   or agree on a standardized format for data channel messages which a gateway transcodes into RTP
2. discuss how to put this in SDP

Works in 2014 (2015?)

We will go through similar cycles for MSRP and every other datachannel content. And of course, for all options, like preference for 'is typing' over sending characters directly.


Regards,
Wolfgang Beck


--
Deutsche Telekom Netzproduktion GmbH
Aufsichtsrat: Timotheus Höttges (Vorsitzender)
Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr.: DE 814645262