Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]

Roman Shpount <roman@telurix.com> Mon, 12 September 2011 02:43 UTC

Return-Path: <roman@telurix.com>
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 D770121F8A7E for <rtcweb@ietfa.amsl.com>; Sun, 11 Sep 2011 19:43:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.857
X-Spam-Level:
X-Spam-Status: No, score=-2.857 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 NL-jRZWOWJ1l for <rtcweb@ietfa.amsl.com>; Sun, 11 Sep 2011 19:43:04 -0700 (PDT)
Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC8721F8A95 for <rtcweb@ietf.org>; Sun, 11 Sep 2011 19:43:03 -0700 (PDT)
Received: by pzk33 with SMTP id 33so21360685pzk.18 for <rtcweb@ietf.org>; Sun, 11 Sep 2011 19:45:05 -0700 (PDT)
Received: by 10.68.44.130 with SMTP id e2mr3658352pbm.173.1315795505253; Sun, 11 Sep 2011 19:45:05 -0700 (PDT)
Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx.google.com with ESMTPS id i1sm39991213pbe.1.2011.09.11.19.45.03 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Sep 2011 19:45:03 -0700 (PDT)
Received: by pzk33 with SMTP id 33so21360532pzk.18 for <rtcweb@ietf.org>; Sun, 11 Sep 2011 19:45:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.43.8 with SMTP id s8mr3000196pbl.389.1315795502235; Sun, 11 Sep 2011 19:45:02 -0700 (PDT)
Received: by 10.68.43.136 with HTTP; Sun, 11 Sep 2011 19:45:01 -0700 (PDT)
In-Reply-To: <903DEDB7-CA26-4354-90B2-BE97B78B0A34@skype.net>
References: <A444A0F8084434499206E78C106220CA0B00FDB08B@MCHP058A.global-ad.net> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <E4EC1B17-0CC4-4F79-96DD-84E589FCC4F0@edvina.net> <4E67C3F7.7020304@jesup.org> <BE60FA11-8FFF-48E5-9F83-4D84A7FBE2BE@vidyo.com> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <C3759687E4991243A1A0BD44EAC8230339CA68F054@BE235.mail.lan> <CAOJ7v-2u0UuNXh7bzmZFwiSucbsh=Ps=C3ZM5M3cJrXRmZgODA@mail.gmail.com> <CAKhHsXHXCkNdjtpxCSCk+ABbtxY15GEgouE6X6-sn-LqhnidQw@mail.gmail.com> <CABcZeBOdP6cAqBoiSV-Vdv1_EK3DfgnMamT3t3ccjDOMfELfBw@mail.gmail.com> <CAKhHsXFdU1ZaKQF8hbsOxwTS-_RfmFqQhgzGe=K4mRp+wz+_nQ@mail.gmail.com> <CAD5OKxtCMXzWLg40wV3teyh0TdiD1Xv4taW+BSguoDpAE46oJA@mail.gmail.com> <1541FDA8-C3F6-4D24-BEC4-60EDACB6B582@edvina.net> <CAD5OKxsuONT_-ZWS43BX7H8dkGscz2aM62m0uDyJauVTaUMC4g@mail.gmail.com> <CAD5OKxukC23Vabh=0qP_6o3x=oDLUX9t5_dLHk2McRweAxxpEg@mail.gmail.com> <903DEDB7-CA26-4354-90B2-BE97B78B0A34@skype.net>
Date: Sun, 11 Sep 2011 22:45:01 -0400
Message-ID: <CAD5OKxsJ7FM+p0+M43EM7uu7pVyJFzjNuRASbjFSN+-CRkCHBg@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Matthew Kaufman <matthew.kaufman@skype.net>
Content-Type: multipart/alternative; boundary="bcaec5395f2481ff7804acb583c7"
Cc: Randell Jesup <randell-ietf@jesup.org>, Jonathan Lennox <jonathan@vidyo.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]
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: Mon, 12 Sep 2011 02:43:05 -0000

Not sure if you want to configure TURN servers per organization. It is not
guaranteed that the TURN server will be used for the call. Additionally you
do want TURN server on the public internet, out side of the corporate
network. I think what you are trying to accomplish should be implemented via
proxy. SOCKS5 proxy can be used for media and can be used to enforce
corporate policies. When connecting to an external TURN server, a regular
HTTP proxy can be used, but in this case you normally end up with two
different media relay agents (proxy and a TURN server).
_____________
Roman Shpount


On Sat, Sep 10, 2011 at 4:41 PM, Matthew Kaufman
<matthew.kaufman@skype.net>wrote:

>
>
>
> On Sep 10, 2011, at 11:52 AM, Roman Shpount <roman@telurix.com> wrote:
>
> >
> >
> > On the related note, I do think that specifying and providing STUN and
> TURN servers should be responsibility of the RTC application developer and
> not the browser configuration. TURN server can consume quite a bit of
> bandwidth and one can see that they will be provided as a paid service in
> combination with RTC application itself.
> >
>
> I think we need both... In a corporate environment, there might be the
> desire or need to send everything to a a TURN service operated by the
> organization, independently of whether or not the service provider operates
> such services.
>
> Matthew Kaufman
>
> Sent from my iPad
>