Re: [rtcweb] STUN for keep-alive - RTCP-less applications

Hadriel Kaplan <HKaplan@acmepacket.com> Thu, 22 September 2011 13:32 UTC

Return-Path: <HKaplan@acmepacket.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 938F621F8C89 for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 06:32:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.525
X-Spam-Level:
X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599]
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 3XQPITrumh7d for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 06:32:31 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id F3ED421F8C77 for <rtcweb@ietf.org>; Thu, 22 Sep 2011 06:32:30 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 22 Sep 2011 09:34:58 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 22 Sep 2011 09:34:58 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Thread-Topic: [rtcweb] STUN for keep-alive - RTCP-less applications
Thread-Index: AQHMeSxrIKUT9mUbYkyr0iQzRJ1k0w==
Date: Thu, 22 Sep 2011 13:34:58 +0000
Message-ID: <4D8061B7-16C5-439C-8911-E4F2046999B7@acmepacket.com>
References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <CABcZeBO9hUSYZhLrcfbaK9HLGXq-q1EvqWOy6-gAN5xom6Z2-A@mail.gmail.com> <092401cc749b$8fd64940$af82dbc0$@com> <CABcZeBPgRD6kb2gg=m9NckSa1wrzwzJS6527nYqFG34b0cjfgQ@mail.gmail.com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <2B265ADC-44C3-48CC-95A6-B90ED6E42FA7@acme packet.com> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com> <4E7AE83E.9090508@ericsson.com> <0C42CC63-CA1A-4F64-B522-BC1DAB477471@acmepacket.com> <4E7B2A65.6090106@ericsson.com>
In-Reply-To: <4E7B2A65.6090106@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <3F294D36C0A43245A9F1FE9C27BA8C96@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>, Colin Perkins <csp@csperkins.org>
Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications
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, 22 Sep 2011 13:32:31 -0000

On Sep 22, 2011, at 8:30 AM, Magnus Westerlund wrote:

>> If the
>> concern is just that the far-end is dead or terminated the call but
>> the local side didn't get the memo, we can solve that other ways.
> 
> On the last issue, do you have a suggestion for how to achieve this that
> isn't RTCP?

If we assume that a gateway to legacy has to handle ICE termination anyway, then it can send STUN indications during the call.
The rtcweb browser can use those to see the far end is alive and expecting media on the 5-tuple.
If we're worried about those being faked/spoofed by malicious server/JS, we can modify the indication mechanism (which could also allay ekr's concerns about consent refresh).


>> Yup.  I don't doubt we'll need some form of media-plane gateway
>> either in the web server or separate to interop with legacy - I'm
>> just trying to keep it from becoming so expensive and complicated
>> that it would be cheaper/easier/better to use SIP softclients or
>> plugins instead.
>> 
> 
> I understand and support that we shouldn't have unnecessary
> complications for legacy interop. However, but I don't see it being done
> by compromising security to the level where RTCWEB can't be deployed
> even for browser to browser usage.

Welllll... could we just require specific user consent for calls to/from legacy?

-hadriel