Re: [pntaw] New version of draft-hutton-rtcweb-nat-firewall-considerations

[Oleg Moskalenko <[e-mail]>]

On Sun, Sep 22, 2013 at 1:57 PM, Hutton, Andrew <
[e-mail]> wrote:

> On: 22 September 2013 01:57 Oleg Moskalenko WroteL
> >
> > HTTP Connect, indeed, may allow a similar functionality. But it will
> > require two things: a proxy configuration in the browsers, and an HTTP
> > Proxy set by enterprise IT department. That may be a challenge for a
> > new WebRTC project in an enterprise environment.
>
> [AndyH] - The case of an enterprise WebRTC project taking place under the
> control of the enterprise IT department although within scope is not the
> prime reason for wanting the HTTP Connect mechanism.  There are various
> options for this use case and the important thing is that the browser
> behavior is standardized and understood by the IT department.
>
> Probably more important at least for early deployments is making sure that
> a WebRTC service external to the enterprise is accessible when there is no
> IT department or when the IT department is not WebRTC aware and just wants
> it to work.  The power of WebRTC is that it brings new type of media to the
> web and it just has to work by default with additional controls possible if
> the network administrator wants to use them. If an enterprise already has a
> Web/HTTP Proxy deployed and a firewall configured to allow web traffic to
> flow via the proxy then this should also work when accessing WebRTC
> services. This has nothing to do with an enterprise deploying WebRTC for
> its own use.
>

An enterprise may have no HTTP proxy configured by default for the users
but still the enterprise may have some strict firewall rules. I know such
enterprises. Those enterprise projects will benefit from the
TURN-over-websockets protocol.

Each large enterprise IT has a complex history and complex web of policies.
If a new standard provides new capabilities and useful possible scenarios,
without imposing strict rules on IT departments, then I guess that would be
a right thing.


>
> [AndyH] As I tried to explain above the use case of prime importance is
> getting WebRTC to work with existing infrastructure and without requiring
> an enterprise to deploy stuff just because an enterprise user wants to use
> a WebRTC service maybe on a single use basis such communicating with a
> suppliers call centre.
>

I personally do not see anything wrong or criminal in a single use basis.

My understanding is that TURN-over-websockets allows WebRTC deployment
with minimal or no changes in the infrastructure. As I said before, not all
large companies are using HTTP proxy for user browsers.