Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt

Bernard Aboba <> Tue, 20 August 2013 21:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9446921F9F74 for <>; Tue, 20 Aug 2013 14:44:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LqDuzP5GRbwl for <>; Tue, 20 Aug 2013 14:44:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 11EDA11E82E7 for <>; Tue, 20 Aug 2013 14:44:15 -0700 (PDT)
Received: from BLU169-W31 ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Aug 2013 14:44:14 -0700
X-TMN: [wFcU1xKic8wsIP/MZnwegDGe8b+aMVar]
X-Originating-Email: []
Message-ID: <BLU169-W310F3FFA764405F5FEBB2993430@phx.gbl>
Content-Type: multipart/alternative; boundary="_20744e59-5bc3-4934-a723-9de1975a43ea_"
From: Bernard Aboba <>
To: "Hutton, Andrew" <>, "" <>, Harald Alvestrand <>
Date: Tue, 20 Aug 2013 14:44:14 -0700
Importance: Normal
In-Reply-To: <>
References: <>, <>
MIME-Version: 1.0
X-OriginalArrivalTime: 20 Aug 2013 21:44:14.0687 (UTC) FILETIME=[6A05DEF0:01CE9DEE]
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Aug 2013 21:44:33 -0000

The NAT/Firewall considerations document does go into detail on the various traversal scenarios, which helps inform the discussion of what should or should not be supported in terms of transport.  Section 5 summarizes the recommendations as follows: 

5.  Requirements for RTCWEB-enabled browsers

   For the purpose of relaying RTCWEB media streams or data channels a
   browser needs to be able to

   o  connect to a TURN server via UDP, TCP and TLS,

   o  connect to a TURN server via a HTTP proxy using the HTTP connect

   o  connect to a TURN server via the HTTP(s) ports 80/443 instead of
      the default STUN ports 3478/5349,

   o  upgrade the HTTP proxy-relayed connection to the TURN server to
      use TLS,

   o  use the same proxy selection procedure for TURN as currently done
      for HTTP,

   o  switch the usage of the HTTP proxy-relayed connection with the
      TURN server from HTTP to STUN/TURN,

   o  use a preconfigured or standardized port range for UDP-based media
      streams or data channels,

   o  learn from the proxy configuration script about the presence of a
      local TURN server and use it for sending UDP traffic to the

   o  support ICE-TCP for TCP-based direct media connection to the
      RTCWEB peer.

> From:
> To:;
> Date: Tue, 20 Aug 2013 16:31:28 +0000
> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt
> Section 2.2 "Middle Box Related Functions" should also I assume cover the case of using a HTTP Proxy or an enterprise TURN server and reference assuming we can get this adopted.
> Regards
> Andy