IETF Logo Mail Archive

Re: [rtcweb] Non-media data service consensus and requirements

Bernard Aboba <bernard_aboba@hotmail.com> Mon, 27 June 2011 23:14 UTC

Return-Path: <bernard_aboba@hotmail.com>
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 DF70221F850F for <rtcweb@ietfa.amsl.com>; Mon, 27 Jun 2011 16:14:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level:
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-qrHeLNdhiL for <rtcweb@ietfa.amsl.com>; Mon, 27 Jun 2011 16:14:27 -0700 (PDT)
Received: from blu0-omc3-s9.blu0.hotmail.com (blu0-omc3-s9.blu0.hotmail.com [65.55.116.84]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBFC21F8525 for <rtcweb@ietf.org>; Mon, 27 Jun 2011 16:14:27 -0700 (PDT)
Received: from BLU152-W40 ([65.55.116.73]) by blu0-omc3-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Jun 2011 16:14:27 -0700
Message-ID: <BLU152-w406463965676BD0CAD7AA993570@phx.gbl>
Content-Type: multipart/alternative; boundary="_f00dabe5-1ecf-4a55-a0e0-a6e93dce161f_"
X-Originating-IP: [131.107.0.111]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: emcho@jitsi.org
Date: Mon, 27 Jun 2011 16:14:26 -0700
Importance: Normal
In-Reply-To: <4E090781.20308@jitsi.org>
References: <blu152-w313AC2093422E0C005708093570@phx.gbl>, <4E090781.20308@jitsi.org>
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Jun 2011 23:14:27.0055 (UTC) FILETIME=[F5C5EFF0:01CC351F]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Non-media data service consensus and requirements
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: Mon, 27 Jun 2011 23:14:28 -0000

 
> Well, if ICE is part of the browser we could condition sending such data
> on the successful termination of ICE processing with the intended
> destination. Same as with RTP. Wouldn't this work?

It depends on the exact requirements. 

There has already been discussion of relaxing the ICE requirement so as to better enable backward compatibility with legacy implementations (e.g. using RTCP instead).  
There is also a potential backward compatibility requirement for non-media data, which will be even more difficult, since ICE (or Jingle or SDP) is not routinely used today (think online gaming), and the volume is potentially quite heavy so that gateways may represent a significant burden.

So before saying that ICE would "solve the problem", it's important to understand what exactly the problem is. 

Are we talking about sending arbitrary data-grams in transactional exchanges?   Or perhaps text encoded in RTP?  Or maybe data in a specified encoding (e.g. not RTP or arbitrary datagrams) so as to prevent spoofing?

Are there multiple use cases here, each with slightly different requirements?

v2.23.0 | Report a Bug | By Email