Subject: Re: [rtcweb] Use Case draft -- Enterprise Policies

From: Roman Shpount <[email-masked]>
Date: Wed, 2 May 2012 12:50:54 -0400

Couple more use cases that I've mentioned on this least before had to do
with enforcing enterprise policies on  Web RTC clients at the enterprise
location. Keep in mind that I am not looking for a way to disable WebRTC in
the location completely, but to restrict its use of functionality. I see
the following scenarios:

1. Enterprise would like to limit the amount of bandwidth available for
WebRTC communications per location and per user.

This can be addressed by setting up enterprise network not to route to a
public internet, setting up an HTTP proxy and TURN server on the enterprise
network, and allowing to overwrite TURN server settings for enterprise
users. This way no unauthorized WebRTC communications would be allowed and
bandwidth restrictions can be enforced by the TURN server. TURN user
credentials can be used to restrict bandwidth per user or to assign user
bandwidth quotas. This provides an additional requirements that TURN server
configuration provided in the browser overwrites TURN/STUN configuration
provided by WebRTC API.

2. Enterprise would like to limit WebRTC communications (but not the other
communications such as HTTP)  to particular networks.

This can be addressed using the premise based TURN server, as in 1.

3. Enterprise would like to limit certain types of communications, ie
enable audio, but disable video and data for all the WebRTC applications on
its premises.

This currently has no solution, since there is no consistent way to know
which remote IP/port/SSRC is used for what type of communication. To enable
this, some sort of centralized SDP monitoring/modification service needs to
be deployed. Proposed solution of using HTTP proxy to modify WebRTC
application does not seem to be very stable and can be easily circumvented.

4. Enterprise would like to limit external communications only to
destinations signed by a specified list of identity providers, ie users are
allowed to communicate with anybody with identity at acme.com, but not with
user with identity at socialnetwork.com

This currently has no solution, since there is no consistent way to know
which remote IP/port is used by what remote identity. To enable this, some
sort of centralized SDP monitoring/modification service needs to be
deployed as in 3.

5. Enterprise would like to enable only communications that are recorded to
leave its premises.

This currently has no solution, since there is no consistent way to know if
communication with particular remote IP/port is recorded. This does not
fall under RAVEN since it is consensual by the user. Using solutions such
as SIP recording or installing some sort of desktop based recording
solutions does not solve this scenario since it provides no way to enforce
that only recorded communications are allowed to leave the premises. Also
note that on premise communications do not have to be recorded. Once again,
some sort for SDP monitoring/modification service needs to be implemented
to support this.
_____________
Roman Shpount

---

From: Ted Hardie <[email-masked]>
Date: Wed, 2 May 2012 09:57:34 -0700

On Wed, May 2, 2012 at 9:50 AM, Roman Shpount <[email-masked]> wrote:
> the location completely, but to restrict its use of functionality. I see the
> following scenarios:
>

It's a bit hard to tease this apart from general per-user fairness methods
and methods that would generally provide (or limit) capabilities for types of
flows.  Why would an enterprise apply different limits because they were
signalled with WebRTC?

regards,

Ted

---

From: Roman Shpount <[email-masked]>
Date: Wed, 2 May 2012 13:37:04 -0400

> flows.  Why would an enterprise apply different limits because they were
I was trying to follow enterprise policies that are used in conjunction
with IP-PBX deployments in enterprises. Typically you would see the
location level limit. Once this location limit is reached, new real time
communications are not allowed, unless they are from high priority caller.
In this case, one of the flows from the low priority caller is disconnected
and high priority call is connected.

With WebRTC and variable rate codecs you can actually implement much better
bandwidth control schemes, but having an enterprise controlled TURN server
that manages bandwidth and QOS parameters and can attribute which
enterprise user this bandwidth is being used by can be very useful.
_____________
Roman Shpount