Re: [rtcweb] Same location media

Matthew Kaufman <matthew.kaufman@skype.net> Thu, 20 October 2011 16:51 UTC

Return-Path: <matthew.kaufman@skype.net>
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 F07A321F8B86 for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 09:51:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, 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 ocPIKTcuOd+K for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 09:51:16 -0700 (PDT)
Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 2183421F8B76 for <rtcweb@ietf.org>; Thu, 20 Oct 2011 09:51:14 -0700 (PDT)
Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 6CC841710; Thu, 20 Oct 2011 18:51:13 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mx; bh=P0mGayBXg8kHP0 5rYVTc6mau8So=; b=p8clLVlyseQkjb7gIgnzL4DsQ6l7+RwbLsgRUN4W7A38L8 ++sNX/NZ7LPVqIxTmnmp/L02HHftOYITOw9V9r/a2IQ/ifRjM4DVLIwM7XMtdbfJ +MlavaGvJK/wqgJCd6Bgern1BJH3vEzjc4e6cvnKPb5t/TK/OdnwuC5r1+/Ts=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type: content-transfer-encoding; q=dns; s=mx; b=hJt9CJ4BOBfTXDj1/OK4s9 ma/IcTQoJKQfPKstneXm1kPNR+B9spnfrOabpzqs8p/Am7/+BzpYGPU2jc0rg2xS Fd6Xkm0KicezhpTXj0Wr0UNFLz0qGu2jejGq+BsS2LCatw2w/F2KH+J+uWxYwe02 CmteGOn+cLANxBaX2hJco=
Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 6B6F87F6; Thu, 20 Oct 2011 18:51:13 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 2202F3507A01; Thu, 20 Oct 2011 18:51:12 +0200 (CEST)
X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net
Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gkne6e023ChU; Thu, 20 Oct 2011 18:51:12 +0200 (CEST)
Received: from Matthew-Kaufman-Air.local (unknown [131.107.200.34]) by zimbra.skype.net (Postfix) with ESMTPSA id AC79E3506F9C; Thu, 20 Oct 2011 18:51:11 +0200 (CEST)
Message-ID: <4EA05180.2010405@skype.net>
Date: Thu, 20 Oct 2011 09:51:12 -0700
From: Matthew Kaufman <matthew.kaufman@skype.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Bernard Aboba <bernard_aboba@hotmail.com>
References: <CAD5OKxuJi_VS9fRc4P6GN-StWzMhMHAQ2MyO8zJVsMfEeQRftg@mail.gmail.com> <BLU152-W274DC7DC92EF49307BC57D93EB0@phx.gbl>
In-Reply-To: <BLU152-W274DC7DC92EF49307BC57D93EB0@phx.gbl>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Same location media
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, 20 Oct 2011 16:51:19 -0000

On 10/20/11 9:41 AM, Bernard Aboba wrote:
>
> One of the requirements in the use case document is the ability to 
> work across firewalls that do not permit UDP.  In practice, this 
> constraint is encountered surprisingly often (as much as 15-25% of the 
> time, in enterprise scenarios).   The implication is that ICE will 
> require a fallback, such as sending media over HTTP.

The fallback that has been proposed in every document I've ever seen is 
TURN over TCP/TLS. (Not arguing that this is sufficient... the fact is 
that sending media over port 80 may be advantageous, and being able to 
send it through web proxies might be even better.)

>   In a fallback situation, requiring ICE would be silly, since it has 
> typically failed in order for fallback to be considered.

STUN connectivity checks can proceed with the far end of a 
TURN-forwarded connection.

Matthew Kaufman