Re: [rtcweb] Data channel comments and questions

<Markus.Isomaki@nokia.com> Thu, 29 March 2012 21:04 UTC

Return-Path: <Markus.Isomaki@nokia.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 1334721F85D3 for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2012 14:04:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.456
X-Spam-Level:
X-Spam-Status: No, score=-7.456 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 Y9FU62RlC7p1 for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2012 14:04:46 -0700 (PDT)
Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id BD7CC21F85D1 for <rtcweb@ietf.org>; Thu, 29 Mar 2012 14:04:43 -0700 (PDT)
Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2TL4XUT012616 for <rtcweb@ietf.org>; Fri, 30 Mar 2012 00:04:41 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Mar 2012 00:04:34 +0300
Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.245]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0355.003; Thu, 29 Mar 2012 23:04:34 +0200
From: Markus.Isomaki@nokia.com
To: rtcweb@ietf.org
Thread-Topic: [rtcweb] Data channel comments and questions
Thread-Index: Ac0N59ezjOXJpyb5S8y3N1bZlLMXyP//45QA///dtwD//7aiUA==
Date: Thu, 29 Mar 2012 21:04:34 +0000
Message-ID: <E44893DD4E290745BB608EB23FDDB7621B1387@008-AM1MPN1-042.mgdnok.nokia.com>
References: <E44893DD4E290745BB608EB23FDDB7621B12D4@008-AM1MPN1-042.mgdnok.nokia.com> <CABcZeBNF2UFdinTDWJy1Tet5yh1=CsiMt3YHZYAXWJLDvPgNSg@mail.gmail.com> <E44893DD4E290745BB608EB23FDDB7621B1300@008-AM1MPN1-042.mgdnok.nokia.com>
In-Reply-To: <E44893DD4E290745BB608EB23FDDB7621B1300@008-AM1MPN1-042.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [93.158.46.72]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 29 Mar 2012 21:04:34.0909 (UTC) FILETIME=[8B4DD0D0:01CD0DEF]
X-Nokia-AV: Clean
Subject: Re: [rtcweb] Data channel comments and questions
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: Thu, 29 Mar 2012 21:04:47 -0000

>
>Ah, sorry for not being clear. I mean a situation where we can't setup the UDP
>channel, if one endpoint is for instance in a corporate network from where
>only HTTP or HTTPS is allowed. So presumably we'd have to support some kind
>of HTTP or TLS encapsulation/tunneling for the data channel as well, from the
>endpoint to some kind of relay. But how would the end-to-end data channel
>look like then? I.e. what would be sent over the tunnel?
>

There's by the way at least one other use case where UDP-based data channel sucks. If you want to keep it up for a long time for some infrequent messaging, keeping the NAT state up by a keepalive every ~30s. would drain the battery on a mobile device. To solve that case some kind of TCP-based variant would be needed, at least between the mobile endpoint and a relay. TURN-TCP, I guess. If the other end was still using UDP and doing frequent keepalives, I suppose the relay would unfortunately forward them as well causing the same ill effect. 

I'm not sure if there are apps that would need to keep the data channel up infrequently used, though. Or should they just use the "signaling" path (HTTP, websockets) for that type of purposes. 

Markus