Return-Path: 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 66BA41A923B for ; Mon, 27 Oct 2014 05:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 VYKtMpQuU1X3 for ; Mon, 27 Oct 2014 05:10:47 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EFAF1A9232 for ; Mon, 27 Oct 2014 05:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14992; q=dns/txt; s=iport; t=1414411816; x=1415621416; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CfieLu/xeP6ZI5zt3nD7/VkKQS7QYIqy6Q1CfsiU0l8=; b=L2n0OXN3Y73EgISl7vgyQqHS8q4RKbeEwMqlJ21Z2Keg52BpS0Dai0lT 6OoxVtNViF3P/difkcpSFvzGkbH9rEAWmjq9MmtrU0bQ42Nm0CG3XoweL 7x7PyroL1+Om9mlV9potxcZvqwdyUSkO+GT7V4+8OzGLH6CfV0FexnrB1 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcFAPY0TlStJA2F/2dsb2JhbABcgkhGVFgEzTEBCYZ5VAKBFhYBcguEAgEBAQQBAQEqQQsMBAIBCBEDAQEBCx0HJwsUCQgCBA4FCIg5DclXAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5BXIA0EBgEGgyeBHgWFFQKMcIRIgkOGPJRBg3hsgUiBAwEBAQ X-IronPort-AV: E=Sophos; i="5.04,795,1406592000"; d="scan'208,217"; a="90640612" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-7.cisco.com with ESMTP; 27 Oct 2014 12:10:15 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s9RCAFgp029226 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Oct 2014 12:10:15 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Mon, 27 Oct 2014 07:10:15 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] draft-ietf-rtcweb-transports-07.txt Thread-Index: AQHP8d5ZlbbCz7ldKkqyzNNpC1BdnZxD2P0g Date: Mon, 27 Oct 2014 12:10:14 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2834FE75@xmb-rcd-x10.cisco.com> References: <7594FB04B1934943A5C02806D1A2204B1D4C18C0@ESESSMB209.ericsson.se> <27059BBA-4094-469F-BE8B-156C0692A02F@edvina.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.66.221] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A2834FE75xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IGWaA4I4y-RyhSzCOFBlGz0upSc Subject: Re: [rtcweb] draft-ietf-rtcweb-transports-07.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 27 Oct 2014 12:10:55 -0000 --_000_913383AAA69FF945B8F946018B75898A2834FE75xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In order to avoid the confusion, we recently published http://tools.ietf.or= g/html/draft-patil-tram-turn-serv-selection-00 which describes TURN selecti= on criteria, as guidelines, that can be used by a client to perform an info= rmed TURN server selection decision when a client discovers multiple TURN s= ervers. -Tiru From: Justin Uberti > Date: Friday, October 24, 2014 1:01 AM To: "Olle E. Johansson" > Cc: "rtcweb@ietf.org" > Subject: Re: [rtcweb] draft-ietf-rtcweb-transports-07.txt Generally, I think there is a fair amount of confusion about how these vari= ous types of TURN servers are going to work. The RETURN draft takes a first= stab at defining the interactions here, and ideally it can be adopted as a= WG draft and referred to by -transports. On Thu, Oct 23, 2014 at 5:26 AM, Olle E. Johansson > wrote: On 22 Oct 2014, at 16:57, Benjamin Schwartz > wrote: FYI, the purpose of the RETURN draft (https://tools.ietf.org/html/draft-sch= wartz-rtcweb-return-03) is to try to specify the precise interaction and pr= ecedence when both the browser and the application provide TURN servers. (= It's not as simple as "one or the other".) I haven't considered the issues related to browser-provided STUN servers, t= hough. Cool! I'll take a look at that. Maybe Haralds draft need to refer to that. /O On Wed, Oct 22, 2014 at 10:51 AM, Christer Holmberg > wrote: Hi, The advantage of an application configuration is that it can be dynamically= provided/updated, based on location based etc - assuming the webpage provi= der has knowledge about STUN/TURN servers, of course. Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Olle E. Johansson Sent: 22 October 2014 17:44 To: rtcweb@ietf.org Subject: [rtcweb] draft-ietf-rtcweb-transports-07.txt Section 3.4 " WebRTC browsers MUST support configuration of STUN and TURN servers, both from browser configuration and from an application." Should we mention which takes precedence? If configured in the browser, sta= rt with that server. If not use the one provided by the application. Maybe we should clarify that turn DNS discovery MUST be used to provide fai= lover and load balancing. /O _______________________________________________ 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 mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_913383AAA69FF945B8F946018B75898A2834FE75xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In order to avoid the con= fusion, we recently published http://tools.ietf.org/html/draft-patil-tram-t= urn-serv-selection-00 which describes TURN selection criteria, as guidelines, that can be used by a client to perform an informed TURN se= rver selection decision when a client discovers multiple TURN servers. = ;

 <= /p>

-Tiru

 <= /p>

From: Justin Uberti <juberti@google.com>
Date: Friday, October 24, 2014 1:01 AM
To: "Olle E. Johansson" <oej@edvina.net>
Cc: "rtcweb@ietf.org&quo= t; <rtcweb@ietf.org>
Subject: Re: [rtcweb] draft-ietf-rtcweb-transports-07.txt=

 

Generally, I think there is= a fair amount of confusion about how these various types of TURN servers a= re going to work. The RETURN draft takes a first stab at defining the interactions here, and ideally it can be adopted as a WG draf= t and referred to by -transports.

 

On Thu, Oct 23, 2014 at 5:2= 6 AM, Olle E. Johansson <oej@edvina.net> wrote:

 

On 22 Oct 2014, at 16:57, B= enjamin Schwartz <bemasc@webrtc.org> wrote:



FYI, the purpose of the RET= URN draft (https://tools.ietf.org/html/draft-schwartz-rtcweb= -return-03) is to try to specify the precise interaction and precedence when both the = browser and the application provide TURN servers.  (It's not as simple= as "one or the other".)

 

I haven't considered the is= sues related to browser-provided STUN servers, though.

Cool! I'll take a look at t= hat. Maybe Haralds draft need to refer to that.

 <= /p>

/O=



 

On Wed, Oct 22, 2014 at 10:= 51 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

The advantage of an application configuration is that it can be dynamically= provided/updated, based on location based etc - assuming the webpage provi= der has knowledge about STUN/TURN servers, of course.

Regards,

Christer


-----Original Message-----
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Olle E. Johansson
Sent: 22 October 2014 17:44
To: rtcweb@ietf.org
Subject: [rtcweb] draft-ietf-rtcweb-transports-07.txt

Section 3.4

" WebRTC browsers MUST support configuration of STUN and TURN servers,=
   both from browser configuration and from an application."=


Should we mention which takes precedence? If configured in the browser, sta= rt with that server.
If not use the one provided by the application.

Maybe we should clarify that turn DNS discovery MUST be used to provide fai= lover and load balancing.

/O
_______________________________________________
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 mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

 

--_000_913383AAA69FF945B8F946018B75898A2834FE75xmbrcdx10ciscoc_--