[rtcweb] [mmusic] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
"Karl Stahl" <karl.stahl@intertex.se> Sat, 21 September 2013 22:29 UTC
Return-Path: <karl.stahl@intertex.se>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6647711E81A0 for <rtcweb@ietfa.amsl.com>; Sat, 21 Sep 2013 15:29:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.814
X-Spam-Level:
X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1]
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 Mi-GuwUPhPaz for <rtcweb@ietfa.amsl.com>; Sat, 21 Sep 2013 15:29:30 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id C436421F9477 for <rtcweb@ietf.org>; Sat, 21 Sep 2013 15:29:28 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201309220029277261; Sun, 22 Sep 2013 00:29:27 +0200
From: Karl Stahl <karl.stahl@intertex.se>
To: rtcweb@ietf.org, draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org
References: <C5E08FE080ACFD4DAE31E4BDBF944EB11667BBA0@xmb-aln-x02.cisco.com> <079001ceb618$2f551ae0$8dff50a0$@stahl@intertex.se>
In-Reply-To: <079001ceb618$2f551ae0$8dff50a0$@stahl@intertex.se>
Date: Sun, 22 Sep 2013 00:29:26 +0200
Message-ID: <07e501ceb71a$07f766d0$17e63470$@stahl>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHOqYsejEiO9JuZoEu3yxpSVyhr2JnO1vuQgAH+JAA=
Content-Language: sv
Subject: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Sat, 21 Sep 2013 22:29:35 -0000
This is an ICE network infrastructure request (rather than WebRTC specific) so I am copying MMUSIC. Harald Alvestrand said: > I'm very hesitant to add more requirements that translate to "new protocol needs to be developed, implemented and deployed across the network before the requirement is useful". --- Who isn't? Still the need is there, especially for network providers to offer TURN servers with their accesses (see below). And worse, it is not > "only" a DHCP option --- it is: "DHCP or a similar mechanism (maybe RA - Router Advertisement - for IPv6, an addition to the IPCP protocol like RFC1877 for PPPoE, or whatever method the mobile OTT channels use)" --- But for the browser it is a trivial thing to implement - Just use the DHCP provided TURN server address suggested. The burden to get the standards done fall on others... There were some comments seeing the need for local TURN-servers (where there are other possibilities than the "automatic DHCP", see below), but I want to stress the importance of allowing network providers to offer TURN servers with their accesses. That is why I call it a "WebRTC-ready" broadband access. I've heard several carries expressing that they want to provide their own TURN servers with their accesses. The reason has both been to avoid that media unnecessarily is sent outside their own network to some remote TURN server and for quality reasons. The quality reason is especially important e.g. in cable operator networks, using bandwidth reservation (RSVP) type of QoS. They need to get hold of the RTP media streams and reserve bandwidth for them and can do that by enforcing a TURN server at the access to be used, and that TURN server can classify and reserve the bandwidth. (They do these things for POTS 3.5kHz voice - They certainly need it for telepresence capable WebRTC.) I think we should be happy and encourage carrier's interest to supply a high quality path for RTC traffic, here WebRTC. (That is a different attitude than e.g. trying to block Skype.) /Karl -----Ursprungligt meddelande----- Från: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] För Karl Stahl Skickat: den 20 september 2013 17:44 Till: 'Cullen Jennings (fluffy)'; rtcweb@ietf.org Ämne: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 For NAT/Firewall traversal WebRTC uses ICE, where the browser today gets the TURN server address from the web application, or gets it configured by a LAN admin via an admin policy template. However, there is a need (motivations below) for the TURN server address to be provided via DHCP (and maybe RA - Router Advertisement - for IPv6, and the OTT channel in mobiles have their own method Ive been told). Simply put, just as you often get your IP-address, DNS address, etc. automatically from the network access, you should also get the TURN server address. I suggest the following is added to the end of use case (which today is about multiple TURN servers) 3.2.4. Simple Video Communication Service, global service provider 3.2.4.1. Description ... "A network service provider must be able to automatically supply a TURN server addresses to the browser when accessing a network. The address may come via DHCP or a similar mechanism (maybe RA - Router Advertisement - for IPv6, an addition to the IPCP protocol like RFC1877 for PPPoE, or whatever method the mobile OTT channels use). The mechanism should be similar to automatically getting the IP-address, DNS address, etc.. and need extensions to current recommendations/standards. There are several reasons for a network service provider to supply a TURN server as part of his offered access: - to keep media paths short, specifically not sending media outside its own network to some distant application provided TURN server - to support mobility, i.e. you may want to move from a LAN with a configured TURN server to accessing via WiFi or 3G/4G OTT channels - to offer a media path with better quality (than best effort data traffic). Getting WebRTC-ready access and we look forward to telepresence for everyone. An enterprise network that want to keep a restrictive firewall not allowing UDP traffic, could provide a real-time path using a TURN server paralleling the firewall, instead of tunneling RTP through always open http or https ports resulting in RTP media over TCP with severe quality problems from TCP retransmissions of dropped packets. The TURN server address is most easily provided in the same way as the IP address and DNS address. (That would also put the right party in control The network provider decides what is allowed on his network.) This browser should select which available TURN server address to use in the following priority order, where ICE could be used to try several: 1) TURN server address configured in the browser by the user (special cases, normally not used) 2) TURN server address configured by the network administrator via an admin policy template 3) TURN server address supplied by DHCP or similar automatic network method 4) TURN server address being supplied by the web application" Two new requirements can be extracted: " ---------------------------------------------------------------- F40 The browser must support retrieving TURN server addresses via DHCP or a similar mechanism (maybe RA - Router Advertisement - for IPv6, an addition to the IPCP protocol like RFC1877 for PPPoE, or whatever method the mobile OTT channels use). The mechanism should be similar to automatically getting the IP-address, DNS address, etc.. ---------------------------------------------------------------- F42 This browser should select which available TURN server address to use in the following priority order, where ICE could be used to try several: 1) TURN server address configured in the browser by the user (special cases, normally not used) 2) TURN server address configured by the network administrator via an admin policy template 3) TURN server address supplied by DHCP or similar automatic network method 4) TURN server address being supplied by the web application ----------------------------------------------------------------" I suppose this also will add to: 5. IANA Considerations TBD /Karl -----Ursprungligt meddelande----- Från: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] För Cullen Jennings (fluffy) Skickat: den 4 september 2013 18:24 Till: rtcweb@ietf.org Ämne: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 We would like to start a working group last call of draft-ietf-rtcweb-use-cases-and-requirements-11. Please send comments by the end of the day on September 21. Thank you, The chairs . _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
- [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-… Cullen Jennings (fluffy)
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Stefan Håkansson LK
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Magnus Westerlund
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Bernard Aboba
- [rtcweb] TURN server address via DHCP, WGLC of dr… Karl Stahl
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Hutton, Andrew
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Harald Alvestrand
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Karl Stahl
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Bernard Aboba
- [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-… Karl Stahl
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Marc Abrams
- [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-use-c… Karl Stahl
- [rtcweb] [mmusic] TURN server address via DHCP, W… Karl Stahl
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Hutton, Andrew
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Marc Abrams
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Hutton, Andrew
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Hutton, Andrew
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Sergio Garcia Murillo
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] TURN server address via DHCP, WGLC o… cb.list6
- Re: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-u… Dan Wing
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Karl Stahl
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Chenxin (Xin)
- Re: [rtcweb] additional ICE info Bernard Aboba
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Karl Stahl
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Chenxin (Xin)
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Karl Stahl
- Re: [rtcweb] additional ICE info Dan Wing
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Cullen Jennings (fluffy)
- Re: [rtcweb] additional ICE info Harald Alvestrand
- Re: [rtcweb] additional ICE info Dan Wing
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Karl Stahl
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Harald Alvestrand
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Markus.Isomaki
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Chenxin (Xin)
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Karl Stahl
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Karl Stahl
- Re: [rtcweb] TURN server address via DHCP, WGLC o… cb.list6
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Cullen Jennings (fluffy)
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Justin Uberti
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Karl Stahl
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Jeremy Laurenson (jlaurens)
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Justin Uberti
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Martin Thomson
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Bernard Aboba
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Jeremy Laurenson (jlaurens)
- [rtcweb] [mmusic] TURN server address via DHCP, W… Karl Stahl
- Re: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-u… Magnus Westerlund
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Saverio Vardaro
- Re: [rtcweb] additional ICE info Martin Thomson
- Re: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-u… Karl Stahl
- Re: [rtcweb] [mmusic] TURN server address via DHC… Cullen Jennings (fluffy)
- Re: [rtcweb] [mmusic] TURN server address via DHC… Karl Stahl
- Re: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-u… Christer Holmberg
- Re: [rtcweb] [mmusic] TURN server address via DHC… Justin Uberti
- Re: [rtcweb] [mmusic] TURN server address via DHC… cb.list6
- [rtcweb] Payload Types assignments was Re: SV: [m… Magnus Westerlund
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Karl Stahl
- Re: [rtcweb] [mmusic] TURN server address via DHC… Karl Stahl
- Re: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-u… Karl Stahl
- Re: [rtcweb] [mmusic] TURN server address via DHC… Justin Uberti
- Re: [rtcweb] Payload Types assignments was Re: SV… Karl Stahl
- Re: [rtcweb] Payload Types assignments was Re: SV… Harald Alvestrand
- Re: [rtcweb] Payload Types assignments was Re: SV… BeckW
- Re: [rtcweb] Payload Types assignments was Re: SV… Ted Hardie
- Re: [rtcweb] Payload Types assignments was Re: SV… BeckW
- Re: [rtcweb] Payload Types assignments was Re: SV… Harald Alvestrand
- Re: [rtcweb] Payload Types assignments was Re: SV… Martin Thomson
- Re: [rtcweb] Payload Types assignments was Re: SV… Harald Alvestrand
- Re: [rtcweb] Payload Types assignments was Re: SV… BeckW
- Re: [rtcweb] Payload Types assignments was Re: SV… Martin Thomson
- Re: [rtcweb] Payload Types assignments was Re: SV… Ted Hardie
- Re: [rtcweb] Payload Types assignments was Re: SV… Lee, Richard FTC
- Re: [rtcweb] Payload Types assignments was Re: SV… Dan Wing
- Re: [rtcweb] Payload Types assignments was Re: SV… BeckW
- Re: [rtcweb] Payload Types assignments was Re: SV… Karl Stahl
- [rtcweb] [mmusic] Anycast discovery, Was TURN ser… Karl Stahl
- [rtcweb] [avtext] Payload Types assignments was R… Karl Stahl
- [rtcweb] [tram] Payload Types assignments Karl Stahl
- Re: [rtcweb] [tram] Payload Types assignments Colin Perkins
- Re: [rtcweb] [tram] Payload Types assignments Karl Stahl
- Re: [rtcweb] [tram] Payload Types assignments Magnus Westerlund
- Re: [rtcweb] [tram] Payload Types assignments Charles Eckel (eckelcu)
- Re: [rtcweb] [tram] Payload Types assignments Colin Perkins
- Re: [rtcweb] [tram] Payload Types assignments Harald Alvestrand
- Re: [rtcweb] [tram] Payload Types assignments Karl Stahl
- Re: [rtcweb] [tram] Payload Types assignments Karl Stahl
- Re: [rtcweb] [tram] Payload Types assignments Karl Stahl
- Re: [rtcweb] [tram] Payload Types assignments Harald Alvestrand
- Re: [rtcweb] [tram] Payload Types assignments Karl Stahl