Re: [MMUSIC] Comments on ICE-TCP specification RFC 6544
Adam Roach <adam@nostrum.com> Thu, 27 June 2013 05:15 UTC
Return-Path: <adam@nostrum.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47E321F9BDC for <mmusic@ietfa.amsl.com>; Wed, 26 Jun 2013 22:15:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
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 e201hOTXtFWS for <mmusic@ietfa.amsl.com>; Wed, 26 Jun 2013 22:15:05 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2E96E21F9BD4 for <mmusic@ietf.org>; Wed, 26 Jun 2013 22:15:05 -0700 (PDT)
Received: from 99-152-145-110.lightspeed.dllstx.sbcglobal.net (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r5R5F3Q3038927 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 27 Jun 2013 00:15:04 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <51CBCA56.8040709@nostrum.com>
Date: Thu, 27 Jun 2013 00:15:02 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Nigel Pattinson <nigel.pattinson@kaseya.com>
References: <CANE3Kwy-pOcdYfpFnTKKBpvMLHoV1XV3VME6tU7+BtMdCTcNfg@mail.gmail.com> <1372174473646-373839.post@n7.nabble.com> <1372304462652-374094.post@n7.nabble.com>
In-Reply-To: <1372304462652-374094.post@n7.nabble.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Comments on ICE-TCP specification RFC 6544
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2013 05:15:05 -0000
On 6/26/13 22:41, Nigel Pattinson wrote:
> However in
> practice we suspect the outcome will be that host candidates will be used
> within a LAN, and a relayed connection in almost all other cases.
How many techniques from sections 5.3 and 5.4 did you implement? Did
your implementation make use of the following advice?
If the local network or host
does not support IPv6 addressing, clients SHOULD make use of
other techniques, e.g., TURN-IPv6 [RFC6156], Teredo [RFC4380], or
SOCKS IPv4-IPv6 gatewaying [RFC3089], for obtaining IPv6 candidates.
My experience is that Teredo-to-Teredo tunneling has success rates well
above 50% (at least for RFC6081 implementations) -- although this is
admittedly from my own personal use of Teredo, and is far from a
scientific survey.
/a
- [MMUSIC] Comments on ICE-TCP specification RFC 65… Nigel Pattinson
- Re: [MMUSIC] Comments on ICE-TCP specification RF… jakubadamek
- Re: [MMUSIC] Comments on ICE-TCP specification RF… Nigel Pattinson
- Re: [MMUSIC] Comments on ICE-TCP specification RF… Adam Roach
- Re: [MMUSIC] Comments on ICE-TCP specification RF… Nigel Pattinson
- Re: [MMUSIC] Comments on ICE-TCP specification RF… Adam Roach