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

Emil Ivov <> Tue, 28 June 2011 06:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C984321F866B for <>; Mon, 27 Jun 2011 23:38:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vHAtd9Nl4TO3 for <>; Mon, 27 Jun 2011 23:38:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A755221F863E for <>; Mon, 27 Jun 2011 23:38:11 -0700 (PDT)
Received: by wyj26 with SMTP id 26so4147955wyj.31 for <>; Mon, 27 Jun 2011 23:38:10 -0700 (PDT)
Received: by with SMTP id q1mr6144828wby.101.1309243089144; Mon, 27 Jun 2011 23:38:09 -0700 (PDT)
Received: from porcinet.local ( []) by with ESMTPS id fi5sm4600633wbb.39.2011. (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Jun 2011 23:38:08 -0700 (PDT)
Message-ID: <>
Date: Tue, 28 Jun 2011 08:38:06 +0200
From: Emil Ivov <>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv: Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Bernard Aboba <>
References: <blu152-w313AC2093422E0C005708093570@phx.gbl>, <> <BLU152-w406463965676BD0CAD7AA993570@phx.gbl>
In-Reply-To: <BLU152-w406463965676BD0CAD7AA993570@phx.gbl>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [rtcweb] Non-media data service consensus and requirements
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, 28 Jun 2011 06:38:13 -0000

На 28.06.11 01:14, Bernard Aboba написа:
>> 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

I supposed I missed the discussion on dropping ICE. However, I don't
quite understand the issue with legacy implementations. If they are not
using ICE then they are most probably relying on server-side relaying
techniques such as latching. If that's the case then rtcweb clients
would establish sessions with a server which would be the one required
to do ICE (or ICE lite) rather than talking directly to the remote party.

This does indeed require the server to support ICE (lite) but is this
really an issue?

> (e.g. using RTCP instead). 

Not sure I understand. Is someone using RTCP for NAT traversal and
connectivity establishment?

> 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.

Same as above. If they weren't using ICE before then they were either
relaying through a server that can now take care of ICE (lite), or they
were using a home-grown ICE variant which wouldn't be compatible anyway.
Am I missing something?

> 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?

Right. Can we then agree that most use cases would be similar to a
regular VoIP session without the limitation of putting RTP inside packets?