Re: [rtcweb] Use Case draft

Marshall Eubanks <marshall.eubanks@gmail.com> Tue, 01 May 2012 03:41 UTC

Return-Path: <marshall.eubanks@gmail.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 9B84121F87D0 for <rtcweb@ietfa.amsl.com>; Mon, 30 Apr 2012 20:41:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.628
X-Spam-Level:
X-Spam-Status: No, score=-103.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 NJqjbVskyIxh for <rtcweb@ietfa.amsl.com>; Mon, 30 Apr 2012 20:41:39 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 72DFE21F87CF for <rtcweb@ietf.org>; Mon, 30 Apr 2012 20:41:38 -0700 (PDT)
Received: by lbbgm13 with SMTP id gm13so2544300lbb.31 for <rtcweb@ietf.org>; Mon, 30 Apr 2012 20:41:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=D3QR85ehSVY7YS8nXnEQiGZrHiFQE1jbQpZOAccsyKU=; b=CouTdoLiWDnWuzVuNdWztUXXwmigARRDGMkVAQEhnsOlqU9eSiZ3s46qn5TBi9nuNT huhQDX8jecjEM87243QrKVBHEWWKWi8vxcif8YyZCxyU8AqVqVWWhOLPvn/w0u/wxMn5 uOT0H5UsTX0ZiW3MACU0YHakJbTfWG11uICHbRDXKecvgdhM7/zMZ7KVQOP1pwsMg4TR Qly2IAvAkYhTftn5Kf7uC6EFQkukTw358DBVV91lcnfYlqLjQS5SbTlKPyFi07u3TS1D H9R1Tsf9mSRb9QR9auH6WVxvv56uQVZVrHua8pIVZ3jVZ9tIRcBlQP4tEI/DEPK8fY1q 792g==
MIME-Version: 1.0
Received: by 10.112.104.99 with SMTP id gd3mr8990892lbb.70.1335843697386; Mon, 30 Apr 2012 20:41:37 -0700 (PDT)
Received: by 10.112.56.13 with HTTP; Mon, 30 Apr 2012 20:41:37 -0700 (PDT)
In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31299282765@MCHP058A.global-ad.net>
References: <CA+9kkMCYArLPRP3c00UdOja64WRT6ghN0PSy7XvM_wbxBBB+vA@mail.gmail.com> <E17CAD772E76C742B645BD4DC602CD810616F066@NAHALD.us.int.genesyslab.com> <BLU169-W7C59E1EDB4CB06B648577932B0@phx.gbl> <387F9047F55E8C42850AD6B3A7A03C6C0E23AFFF@inba-mail01.sonusnet.com> <2E496AC9-63A0-464A-A628-7407ED8DD9C4@phonefromhere.com> <387F9047F55E8C42850AD6B3A7A03C6C0E23B16B@inba-mail01.sonusnet.com> <E2714FBC-D06B-4A12-9E07-C49EBF55084C@phonefromhere.com> <4F9EC0B2.10903@alcatel-lucent.com> <101C6067BEC68246B0C3F6843BCCC1E31299282765@MCHP058A.global-ad.net>
Date: Mon, 30 Apr 2012 23:41:37 -0400
Message-ID: <CAJNg7VKENERKAFA-n5KeoeBNmGgHrnzDOU0BzC9+fSdsuGwdEw@mail.gmail.com>
From: Marshall Eubanks <marshall.eubanks@gmail.com>
To: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Use Case draft
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: Tue, 01 May 2012 03:41:39 -0000

On Mon, Apr 30, 2012 at 2:31 PM, Hutton, Andrew
<andrew.hutton@siemens-enterprise.com> wrote:
> Whether anybody has been successful in the past with this type of use case
> is I think irrelevant.
>
>
>
> The enterprise call centre use case is I think a vital use case because it
> is a scenario in which one user is only concerned that they can securely
> reach an organization/domain and is not concerned about the individual
> within that domain  that they communicate with.  A suspect quite a large
> percentage of RTCWEB applications will be like this and it is not covered in
> the current use case draft.

I agree that this is a very useful use case and one I think is going
to get a lot of traction. There is a very solid
business case for this.  However, I have a fair amount of experience
with a video call center for a client, and it is not as simple as it
might seem.

The essence of course is that you get the next available person, i.e.,
it is anycast. Determining who the next available person is is not
trivial, nor is error recovery. (If I call you, and you don't answer
or the call drops or whatever,  I can leave a message or try later. If
I call a help desk, and this happens, I want a new agent, ideally
automatically.) Call forwarding (e.g., first tier to second tier
technical support) is essential, and it may be anycast or directed.
There are also some security oddities  - if I am connecting from home,
I may need to authenticate, use a credit card, etc. If I am connecting
from inside a store, and providing in store video technical support is
big part of the market, then the store authenticates me off line and
the call really should just be a button push, which implies that the
store has previously authenticated some sort of master session. In
addition, unlike most video calls, in the enterprise call center a
supervisor may need to be able to monitor (i.e., watch) a call, and in
some circumstances (financial or medical calls, for example) there
will need to be third party recording. I believe that  these details
would be different from the typical RTCWEB scenario.

Also, there will be a temptation to do the anycasting by the
techniques used to load balance servers in a data center, but I think
that may not be sufficient. The call "center" may in fact be spread
completely across the planet (daytime support in the US, nighttime
support in India, for example) and be on multiple autonomous systems
(and even from people's homes), which gives rise to some of the
transport issues NVO3 may face, but without any opportunity for packet
tagging. Plus, there will complicated rules about who can be selected
next. RTCWEB shouldn't worry about the intricacies of bathroom break
policies; these complexities should be dealt with by an
enterprise-side database, which to me (together with some of the other
issues above) suggests that this would probably benefit from  API
support.

Regards
Marshall


>
>
>
> So I think we need it.
>
>
>
> Regards
>
> Andy
>
>
>
>
>
>
>
>
>
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
> Igor Faynberg
> Sent: 30 April 2012 17:41
> To: rtcweb@ietf.org
>
>
> Subject: Re: [rtcweb] Use Case draft
>
>
>
> Without numbers it is impossible to argue, but, if we talk about the
> perceived need, I disagree.  Think of the people who travel abroad and
> cannot call the 800 number. (I routinely use Web interface for calls when
> traveling.)
>
>
>
> I am all for  the use case, as described by Jim.
>
> Igor
>
> On 4/30/2012 9:54 AM, Tim Panton wrote:
>
> ...
>
> I can't tell you the actual numbers, but when presented with the choice of
> calling a toll free number
>
> or clicking a button marked "free internet call" - almost no-one on a real,
> busy site clicked the button.
>
> ( for every button click there were several orders of magnitude more 0800
> calls from that page).
>
>
>
>
>
> So from my perspective this is a legacy interop use case with almost zero
> user acceptance.
>
>
>
> (as far as I can see no-one has made this use-case desirable in practice
> yet.)
>
> Tim.
>
>
>
>
>
>
>
> _______________________________________________
>
> 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
>