[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