Return-Path: 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 ; 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 ; 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 ; 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 ; 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: To: 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: References: In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 kin= d >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 messa= ging, keeping the NAT state up by a keepalive every ~30s. would drain the b= attery on a mobile device. To solve that case some kind of TCP-based varian= t would be needed, at least between the mobile endpoint and a relay. TURN-T= CP, I guess. If the other end was still using UDP and doing frequent keepal= ives, I suppose the relay would unfortunately forward them as well causing = the same ill effect.=20 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 (HT= TP, websockets) for that type of purposes.=20 Markus=20