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

Roman Shpount <roman@telurix.com> Wed, 02 May 2012 17:37 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 E905721F8559 for <rtcweb@ietfa.amsl.com>; Wed, 2 May 2012 10:37:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.836
X-Spam-Level:
X-Spam-Status: No, score=-2.836 tagged_above=-999 required=5 tests=[AWL=0.140, 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 82EPGyw1U3DW for <rtcweb@ietfa.amsl.com>; Wed, 2 May 2012 10:37:08 -0700 (PDT)
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 29AA421F8557 for <rtcweb@ietf.org>; Wed, 2 May 2012 10:37:08 -0700 (PDT)
Received: by wibhr17 with SMTP id hr17so4283659wib.1 for <rtcweb@ietf.org>; Wed, 02 May 2012 10:37:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=/k+Nd7bL8otdnxMLnFH0oXugYK6wgXKzmoowPCzDQw8=; b=XgpRnz0r7eeuXpILmH29CHlDnEsUGOhshQSar45zqRxl+kngH8sgTGzkJPXgCg1OiG BPz2oOPnxlTV2k0HmbpdugK+HU/9wbsAPkIXAIIanjD8OwUQfykG0t9mXdHRQy74K8AD lG1OrYoQgi2dDEH+amBF3/n4n/GFeqQSeyRZPJE36+Dy1pMh1mptTdEPyZfiWM+93lIc /rNgx2ojpZShuuLp0/kBP/3ePEc5WZH9kz7+1wJ7eVpxpLBa5BmP5eTOm8ubguzI/GcI oxtcKBT3fVwn5RBU4KW3Tdnqsi2JF5p098cNjhwpDYg/1IpeIZPp35M+4fFTM/Lwb0xM Z+sw==
Received: by 10.180.76.240 with SMTP id n16mr3949884wiw.10.1335980227225; Wed, 02 May 2012 10:37:07 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by mx.google.com with ESMTPS id ff9sm45416694wib.2.2012.05.02.10.37.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 May 2012 10:37:06 -0700 (PDT)
Received: by bkty8 with SMTP id y8so833605bkt.31 for <rtcweb@ietf.org>; Wed, 02 May 2012 10:37:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.148.83 with SMTP id o19mr6386052bkv.96.1335980224731; Wed, 02 May 2012 10:37:04 -0700 (PDT)
Received: by 10.205.117.146 with HTTP; Wed, 2 May 2012 10:37:04 -0700 (PDT)
In-Reply-To: <CA+9kkMBDK5KM2S1SEiNx56aSb8UtvivEnL-3JoOriACaegNp0w@mail.gmail.com>
References: <CAD5OKxu5fdcfSyBNS8d0uGY-AT1syyAxBh1E3v8ihGsboHWveg@mail.gmail.com> <CA+9kkMBDK5KM2S1SEiNx56aSb8UtvivEnL-3JoOriACaegNp0w@mail.gmail.com>
Date: Wed, 2 May 2012 13:37:04 -0400
Message-ID: <CAD5OKxuJEEzjgAhBFV9zL=yhJYJbo+F71SF_0YSAk2dPXAZ-oA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Ted Hardie <ted.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=0015175cdc56b8d9ec04bf112213
X-Gm-Message-State: ALoCoQnFLJTBWz3qR3HcjMjRSLX0lx18zUDl/syPDkxCax2jJfpvydkXrLGccDiUhqRK1uOKrddD
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Use Case draft -- Enterprise Policies
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: Wed, 02 May 2012 17:37:09 -0000

On Wed, May 2, 2012 at 12:57 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

> On Wed, May 2, 2012 at 9:50 AM, Roman Shpount <roman@telurix.com> wrote:
> > 1. Enterprise would like to limit the amount of bandwidth available for
> > WebRTC communications per location and per user.
> >
>
> 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?
>
>
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