[rtcweb] Use of STUN 300 Alternate Server in Transport
Harald Alvestrand <harald@alvestrand.no> Wed, 22 January 2014 10:31 UTC
Return-Path: <harald@alvestrand.no>
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 113801A02C0 for <rtcweb@ietfa.amsl.com>; Wed, 22 Jan 2014 02:31:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.434
X-Spam-Level:
X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] 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 VUY2-eC7g_Rb for <rtcweb@ietfa.amsl.com>; Wed, 22 Jan 2014 02:31:54 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [IPv6:2001:700:1:2:213:72ff:fe0b:80d8]) by ietfa.amsl.com (Postfix) with ESMTP id 227671A01EB for <rtcweb@ietf.org>; Wed, 22 Jan 2014 02:31:54 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4023039E962 for <rtcweb@ietf.org>; Wed, 22 Jan 2014 11:32:01 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6r+91eHWHzWH for <rtcweb@ietf.org>; Wed, 22 Jan 2014 11:31:59 +0100 (CET)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id A0BFC39E04C for <rtcweb@ietf.org>; Wed, 22 Jan 2014 11:31:59 +0100 (CET)
Message-ID: <52DF9E17.9030600@alvestrand.no>
Date: Wed, 22 Jan 2014 11:31:51 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
References: <CALDtMr+_jUti7BNVRubuncCU9rAZx4NqM3Ru1jtEbRF+uBMMEw@mail.gmail.com>
In-Reply-To: <CALDtMr+_jUti7BNVRubuncCU9rAZx4NqM3Ru1jtEbRF+uBMMEw@mail.gmail.com>
X-Forwarded-Message-Id: <CALDtMr+_jUti7BNVRubuncCU9rAZx4NqM3Ru1jtEbRF+uBMMEw@mail.gmail.com>
Content-Type: multipart/mixed; boundary="------------030308050208090608060503"
Subject: [rtcweb] Use of STUN 300 Alternate Server in Transport
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, 22 Jan 2014 10:31:58 -0000
Following a brief discussion on the PNTAW list, I'm inserting into my updated Transports draft the following paragraph: The ALTERNATE-SERVER mechanism specified in RFC 5389 section 11 (300 Try Alternate) MUST be supported. Comments welcome if anyone thinks we should say anything else! -------- Original Message -------- Subject: Re: [pntaw] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-03.txt Date: Tue, 21 Jan 2014 01:37:10 -0800 From: Oleg Moskalenko <mom040267@gmail.com> To: Hutton, Andrew <andrew.hutton@unify.com> CC: pntaw@ietf.org <pntaw@ietf.org> I have a comment on section 5 of the document. One thing that I'd definitely like to see enforced in the browser's implementation of the TURN client protocol is the support of 300 Alternate Server error message. This is becoming an issue because of the possible volume of the WebRTC media traffic. If the browsers are supporting the error 300, then a TURN server administrator can relatively easy set a load balancing scheme. If the browsers do not support it, then it becomes a more complicated issue and an implementation-dependent procedure. As far as I know, no current browser supports 300 response from TURN server. It would be very nice if the TURN server administrator could rely on that feature. Oleg On Mon, Jan 20, 2014 at 4:09 AM, Hutton, Andrew <andrew.hutton@unify.com <mailto:andrew.hutton@unify.com>> wrote: I updated draft-hutton-rtcweb-nat-firewall-consideration. The main change is that the draft now explores the different options that are available for handling such things as HTTP Proxies in a WebRTC environment and no longer recommends a specific solution. Would be good to restart the discussion on these options and determining the best way forward to ensuring we get some defined standardized behavior for WebRTC for these scenarios. So please go ahead and make comments. Regards Andy -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org <mailto:i-d-announce-bounces@ietf.org>] On Behalf Of internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> Sent: 20 January 2014 11:35 To: i-d-announce@ietf.org <mailto:i-d-announce@ietf.org> Subject: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RTCWEB Considerations for NATs, Firewalls and HTTP proxies Authors : Thomas Stach Andrew Hutton Justin Uberti Filename : draft-hutton-rtcweb-nat-firewall-considerations-03.txt Pages : 14 Date : 2014-01-20 Abstract: This document describes mechanism to enable media stream establishment for Real-Time Communication in WEB-browsers (WebRTC) in the presence of network address translators, firewalls and HTTP proxies. HTTP proxy and firewall deployed in many private network domains introduce obstacles to the successful establishment of media stream via WebRTC. This document examines some of these deployment scenarios and specifies requirements on WebRTC enabled web browsers designed to provide the best possible chance of media connectivity between WebRTC peers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-hutton-rtcweb-nat-firewall-considerations/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-hutton-rtcweb-nat-firewall-considerations-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org>. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft <https://www.ietf.org/mailman/listinfo/i-d-announce%0AInternet-Draft> directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ pntaw mailing list pntaw@ietf.org <mailto:pntaw@ietf.org> https://www.ietf.org/mailman/listinfo/pntaw
- [rtcweb] Use of STUN 300 Alternate Server in Tran… Harald Alvestrand