IETF Logo Mail Archive

Re: [rtcweb] Strawman for how to prevent voice-hammer without ICE

"Elwell, John" <john.elwell@siemens-enterprise.com> Thu, 28 July 2011 15:14 UTC

Return-Path: <john.elwell@siemens-enterprise.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 93EAD21F8C0B for <rtcweb@ietfa.amsl.com>; Thu, 28 Jul 2011 08:14:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.541
X-Spam-Level:
X-Spam-Status: No, score=-103.541 tagged_above=-999 required=5 tests=[AWL=-0.942, BAYES_00=-2.599, 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 7ub+W88mNKWD for <rtcweb@ietfa.amsl.com>; Thu, 28 Jul 2011 08:14:46 -0700 (PDT)
Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id D37FF21F873D for <rtcweb@ietf.org>; Thu, 28 Jul 2011 08:14:45 -0700 (PDT)
Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id DBFB423F059A; Thu, 28 Jul 2011 17:14:44 +0200 (CEST)
Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 28 Jul 2011 17:14:44 +0200
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
Date: Thu, 28 Jul 2011 17:14:42 +0200
Thread-Topic: Strawman for how to prevent voice-hammer without ICE
Thread-Index: AcxNNV1zFnPAe+pkSveuLg9KTGFoZQAAbApQ
Message-ID: <A444A0F8084434499206E78C106220CA08F1D75E24@MCHP058A.global-ad.net>
References: <B6527F21-4DE2-46B1-AE2E-891D56461313@acmepacket.com> <A444A0F8084434499206E78C106220CA08F1D75CF6@MCHP058A.global-ad.net> <464DADBD-EEBE-43C8-8552-EAA40FBB610D@acmepacket.com>
In-Reply-To: <464DADBD-EEBE-43C8-8552-EAA40FBB610D@acmepacket.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Strawman for how to prevent voice-hammer without ICE
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, 28 Jul 2011 15:14:46 -0000

 

> -----Original Message-----
> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] 
> Sent: 28 July 2011 15:48
> To: Elwell, John
> Cc: rtcweb@ietf.org
> Subject: Re: Strawman for how to prevent voice-hammer without ICE
> 
> 
> On Jul 28, 2011, at 8:10 AM, Elwell, John wrote:
> 
> > [JRE] The problem with requiring continued RTP receipt (or 
> even ANY RTP receipt) is sessions where RTP is one-way, e.g., 
> when mic muted, camera off. With many asymmetric 
> possibilities coming out of the CLUE work, this could be a 
> problem, although it perhaps goes away if everything is 
> multiplexed onto the same port. It depends whether we can 
> expect all legacy devices to behave in a way that would make 
> this work.
> 
> Yes, but they don't turn off RTCP (assuming they do RTCP).  
> I'm not suggesting that it's a 1:1 mechanism of receipt/send, 
> nor that it even be very dynamic/real-time.  But sure there 
> will be some cases that it won't work.  But that's no worse 
> than the current state of things, since it won't work to 
> begin with for such devices if ICE is mandated.  We can't 
> achieve 100% interop regardless - I'm just trying for as much 
> as possible.
[JRE] This assumes RTP-RTCP multiplexing, which not many current devices support. There are so many things that RTC-Web is proposing to use that are not widely supported on existing devices that some sort of gateway looks inevitable. Eliminating one particular instance of incompatibility might reduce the amount of adaptation the gateway needs to perform, but it looks increasingly unlikely that all adaptation can be eliminated. So is there any real value in trying to eliminate one aspect if others can't be eliminated? Probably yes, but not if it introduces other compromises, e.g., security. I think it is worth exploring this further.

John

> 
> With regards to CLUE, I don't consider their devices 
> "legacy".  They'll be upgrading to handle CLUE's final spec, 
> so they can be "redeemed".
> 
> -hadriel
> 
>

v2.23.0 | Report a Bug | By Email