Re: [rtcweb] Data transfer

Magnus Westerlund <> Fri, 16 September 2011 13:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 63CDE21F8C1D for <>; Fri, 16 Sep 2011 06:43:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.355
X-Spam-Status: No, score=-106.355 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MbJspsK3pCuR for <>; Fri, 16 Sep 2011 06:43:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8349121F8C1C for <>; Fri, 16 Sep 2011 06:43:25 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-a8-4e73530343d8
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 23.63.20773.303537E4; Fri, 16 Sep 2011 15:45:39 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Fri, 16 Sep 2011 15:45:39 +0200
Message-ID: <>
Date: Fri, 16 Sep 2011 15:45:38 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.3.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "" <>
Subject: Re: [rtcweb] Data transfer
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: Fri, 16 Sep 2011 13:43:26 -0000


When it comes to the data transfer the discussion we have had back in
the beginning of the summer made it clear that there was clear interest
for an unreliable peer to peer datagram based channel.

Use cases include game data, meta information in conferencing. But it is
for whatever the the JS application have use for it.

When it comes to reliable data the result of the discussion was a bit
more unclear. Some interest existed, but no one was willing to be a
driving proponent to both propose technology and use cases.

When it comes to the unreliable data channel we are awaiting that
draft-cbran-rtcweb-data-00 is updated to try to provide something at
least worth discussing. As the WG has no consensus yet on the details
for solving this channel, any contribution is most welcome.

I agree that when it comes to T.140 it can easily be included as media
format that shall be supported. We have had several suggesting that and
no real objections. One can note that there goes 13 proposals for text
transfer to the dozen.

Maybe the simplest is to make a consensus call on this.



On 2011-09-16 09:02, Saúl Ibarra Corretgé wrote:
> Hi Olle,
> On Sep 16, 2011, at 8:32 AM, Olle E. Johansson wrote:
>> A comment on the list made me go back and re-read the charter. One
>> thing I had missed is the data transfer part of rtcweb.
>> "The goal is to enable innovation on top of a set of basic
>> components.  One core component is to enable real-time media like
>> audio and video, a second is to enable data transfer directly
>> between clients."
>> Most of the discussions on the list has been about the media. What
>> are the ideas for data transfer? Applications?
> Maybe I arrived a bit late to the party ;-) but so far I've seen
> discussions mainly around RTP (and related) media.
>> To me, this seems like an interesting feature. If it's a plain data
>> transfer session, a bidirectional session, it's a way to open a
>> session from Javascript to any server, acting as an rtcweb client,
>> which is different from the current sandbox model. I could have
>> missed this discussion, but if not, I think this is an interesting
>> topic to bring up.
>> Another note, which I think is purely a mistake, is to forget
>> realtime text - T.140 and just state audio and video. The T.140
>> users are natural early adoptor users of rtcweb.
> I can think of another use case for "data transfer": MSRP. A browser
> looks looks like a good place for having IM sessions over MSRP.
> Supporting file transfers would also be awesome, and MSRP is just a
> TCP pipe where data flows, so maybe this "data transfer" layer is the
> right place to do this?
> Regards,
> -- Saúl Ibarra Corretgé AG Projects
> _______________________________________________ rtcweb mailing list 


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: