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

Gunnar Hellstrom <> Tue, 04 June 2013 22:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D15F21F9992 for <>; Tue, 4 Jun 2013 15:12:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Jo8xBtQqt974 for <>; Tue, 4 Jun 2013 15:11:57 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 62AF021F9990 for <>; Tue, 4 Jun 2013 15:11:56 -0700 (PDT)
Received: from (unknown []) by (Halon Mail Gateway) with ESMTP for <>; Wed, 5 Jun 2013 00:11:46 +0200 (CEST)
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPA id 6C71D3A18A for <>; Wed, 5 Jun 2013 00:11:46 +0200 (CEST)
Message-ID: <>
Date: Wed, 05 Jun 2013 00:11:48 +0200
From: Gunnar Hellstrom <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <AAE428925197FE46A5F94ED6643478FEAC70553746@HE111644.EMEA1.CDS.T-INTERNAL.COM>
In-Reply-To: <AAE428925197FE46A5F94ED6643478FEAC70553746@HE111644.EMEA1.CDS.T-INTERNAL.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] RTT (was :No Plan )
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 Jun 2013 22:12:03 -0000

On 2013-06-04 17:09, wrote:
> On 6/3/13 8:14 AM, Iñaki Baz Castillo wrote:
>> 2013/6/3 Gunnar Hellstrom <>se>:
>>> The use cases draft includes a case titled:
>>> 4.2.10.  Simple video communication service with inter-operator calling
>>> See:
>> 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.
The standard exists with sdp and all. Ready to be included.
Since this way is described for audio and video, it is an easy option to 
use the same structure for RTT as well.
> In my experience many people have real difficulties to understand that
> 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
> 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?)
I see benefits and uses of both models.
The model of directly using the client of the destination's web server 
looks natural for customer services, and similar applications initiated 
from a web site with information about the organization.
For this model, it is very good to have standards for all media 
communication ( including RTT), so that the behavior in the text 
communication gadgets perform in a similar way from service to service. 
That makes it possible to link other apps conveniently to the browser 
and do specific actions on the text communication.

The model with inter-operator communication allows users to find out the 
client and service they like the best, that has the user interface 
features the user likes or needs, and look the same for every call.  And 
then use that for regular calling. The operator can have implemented 
good ways to display the text, or have your phone directory linked to 
the client, or have an implementation of a client that works well on you 
small device.  There are other benefits also, e.g. that adaptations for 
accessibility reasons will work best if you have a chance to adjust it 
to the client.

So, if we do it for the inter-operator model, it is easy to also use it 
for the single server model.


> 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
> _______________________________________________
> rtcweb mailing list