IETF Logo Mail Archive

[rtcweb] Transports: RFC 6062 support

Justin Uberti <juberti@google.com> Wed, 05 March 2014 15:02 UTC

Return-Path: <juberti@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776F41A01B3 for <rtcweb@ietfa.amsl.com>; Wed, 5 Mar 2014 07:02:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.925
X-Spam-Level:
X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlsDs12jue2s for <rtcweb@ietfa.amsl.com>; Wed, 5 Mar 2014 07:02:52 -0800 (PST)
Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id D0A741A0072 for <rtcweb@ietf.org>; Wed, 5 Mar 2014 07:02:52 -0800 (PST)
Received: by mail-oa0-f41.google.com with SMTP id j17so1137892oag.28 for <rtcweb@ietf.org>; Wed, 05 Mar 2014 07:02:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=40NwcZZt0LtUBiZyFhqqbNEwg1KD5ki0xsNpYYRGBTQ=; b=FsUluCKoU5yHg0yremFKZTS/YN8I6XuzKQ5+LC7JFn+aq63wBB0uqan++H+hVNltyM zlIzF4oWG96dWEg5EZ872ohH4XqQU9T0Js7jGLt1pF4Ctz8jBtQBFe3+s9z3yaii1jFK CJhZo9eAfTNir8dIUdiLIx9ViyTVWVArw1DBOcNpoBX5+rvharoeu/7oH0bKAPfTWczr peZgDbHserOftO4TuyKYbzZ21X3pEWzusW1k3c65WfQNjZVlA92RyBkmXbIlkfRThI/n D7j2kGtzlvXqBXV3oGogoy9A3LWbvki/MdYZuUA5hok6oiIPUVsPXriUCyFVvDyaTmXZ 1EBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=40NwcZZt0LtUBiZyFhqqbNEwg1KD5ki0xsNpYYRGBTQ=; b=bx8GVWAByRIrzlwUK8S44uF2p8CToMWtSml87rB5uYKHaCCYqaaULEkEzeoPf/7Dcj WzE4YuMhZuGE9fv936bY05LB0ppvlIbHKi5dnBeDvOKygD4KOKxTzWFxqWG4qmkyoKY5 4wf+N28FgTiupByQQNMe7ZwkuXqoE7A05y9cBUgNJgelTGcgC8qsXIo1acmvPAJ+7lhq bqF2BOUrjdaEEcNf+tu3by++CaAbNaFIEIjKYtXGxclQ5DFrpa7WbfJjXkj5eCIhnZJU RFo0esVCO4bKxAUWAe7bg1G9IXsifOyDZdwe2TQhbFpIIDFaIUzeP2bWAkWzpBk+EXJD V8ww==
X-Gm-Message-State: ALoCoQn0WrXup7NlXpZbg2ciFxqEGFVA7d6Rel0THqaBwZ+vmFiyMWN3mV25g3og+5cl4hXHZktbXu+BqIYKlOsqE3MWy5CSZERr75pkNy7n6ALjoEoCAP/5kOpKW22bieZsRKTwUdseOZEF7tjxTJoBb0PiYtKWoZHll/W5KeeQZoZUI9Y8kAlak9cS/BddVsjRKOfXMK4w
X-Received: by 10.60.102.37 with SMTP id fl5mr736057oeb.65.1394031769157; Wed, 05 Mar 2014 07:02:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.96.230 with HTTP; Wed, 5 Mar 2014 07:02:29 -0800 (PST)
From: Justin Uberti <juberti@google.com>
Date: Wed, 05 Mar 2014 15:02:29 +0000
Message-ID: <CAOJ7v-0-U8ycUYcOwRGxgZVDQmdPMXC4Qt7F+uAn29AGOepX7w@mail.gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="089e0111bce0681e4e04f3dd50fd"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ExJp9cCK-684JLgKTesgoShncUc
Subject: [rtcweb] Transports: RFC 6062 support
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 05 Mar 2014 15:02:54 -0000

>From the transports draft, Section 3.4:

   TURN TCP candidates [RFC6062 <http://tools.ietf.org/html/rfc6062>]
SHOULD be supported; this allows
   applications to achieve peer-to-peer communication when both parties
   are behind UDP-blocking firewalls using a single TURN server.  (In
   this case, one can also achieve communication using two TURN servers
   that use TCP between the server and the client, and UDP between the
   TURN servers.)


I don't think we want to do this. The optimization of having a single
vs two TURN servers in the .09% case is not worth the implementation
or runtime cost of allocating TURN TCP candidates. It requires a TCP
connection to the TURN server, which we would otherwise not do except
in fallback cases.

v2.23.0 | Report a Bug | By Email