Re: [rtcweb] Use Case draft

Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com> Wed, 02 May 2012 15:48 UTC

Return-Path: <stefan.lk.hakansson@ericsson.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 0E8CC21E802D for <rtcweb@ietfa.amsl.com>; Wed, 2 May 2012 08:48:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
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 1Ck1hYspRENz for <rtcweb@ietfa.amsl.com>; Wed, 2 May 2012 08:48:48 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8B62A21E802A for <rtcweb@ietf.org>; Wed, 2 May 2012 08:48:47 -0700 (PDT)
X-AuditID: c1b4fb25-b7b18ae000000dce-51-4fa1575e815b
Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0191"; auth=fail (cipher=AES128-SHA)
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0191", Issuer "esessmw0191" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id DB.A8.03534.E5751AF4; Wed, 2 May 2012 17:48:46 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 17:48:45 +0200
Message-ID: <4FA1575C.4050508@ericsson.com>
Date: Wed, 02 May 2012 17:48:44 +0200
From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1
MIME-Version: 1.0
To: Jim Barnett <Jim.Barnett@genesyslab.com>
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><CAJNg7VKENERKAFA-n5KeoeBNmGgHrnzDOU0BzC9+fSdsuGwdEw@mail.gmail.com><E17CAD772E76C742B645BD4DC602CD810616F24F@NAHALD.us.int.genesyslab.com> <4FA0F43E.4020308@ericsson.com> <E17CAD772E76C742B645BD4DC602CD810616F336@NAHALD.us.int.genesyslab.com>
In-Reply-To: <E17CAD772E76C742B645BD4DC602CD810616F336@NAHALD.us.int.genesyslab.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
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: Wed, 02 May 2012 15:48:49 -0000

On 05/02/2012 04:39 PM, Jim Barnett wrote:
> When I say that this use case may not add further requirements, I mean
> that it looks like it would be possible to implement it given the
> current definitions of the protocols.  However, the current use cases
> are all written in terms of "the browser", which is not further defined.
> But if "browser" means Mozilla, Chrome, etc., then I think it is
> important to add a use case in which one of the end points is not a
> browser, but an enterprise gateway (which will route the call to an
> employee of its choice, and may record the call, etc.) It is important
> to note that this is not a peer-to-peer use case; the gateway is not the
> caller's peer.  The employee that the caller ends up talking to may be
> considered a peer, but the webRTC call does not extend all the way to
> that employee - it stops at the gateway.

I think all use cases in section 4.3 are browser - GW cases. That said, 
there may be good reasons for adding this one as well.

>
> This is a very different use case from any in the current document.
> That's why it's important to add it, even though (as far as I can tell)
> it doesn't require us to change any of the work we've done.
>
> - Jim
> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
> Of Stefan Hakansson LK
> Sent: Wednesday, May 02, 2012 4:46 AM
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] Use Case draft
>
> On 05/01/2012 02:05 PM, Jim Barnett wrote:
>> One way to describe the use case is to let the contact center's media
>> server/gateway serve as the webRTC endpoint.  Then all the issues of
>> call delivery, call monitoring, etc. disappear.  They are handled by
>> application software that sits behind the webRTC endpoint.  The
>> company I work for makes a good living selling software that deals
>> with all these issues - including bathroom breaks - and that's how we
>> would tend to think of this case.  To us, it's a new kind of
>> call/connection coming into the contact center, which we translate
>> into SIP at the border and then handle normally.
>>
>> It's not clear to me if this use case adds any extra requirements.
>
> I think this is important to sort out. If the use case does not add any
> extra requirements, what's the point of adding it?
>
>> We would just have to be careful not to assume that a webRTC endpoint
>> is always a person/browser-based user agent.  It may seem a bit
>> unsettling that the webRTC endpoint can distribute the call somewhere
>> else and let others listen in, but as far as I can tell that is
>> already the case.  If Bob calls Alice with full authentication and
>> security, he can be sure that he is connected to Alice's user agent
>> and that no one in between can listen in, but there's nothing stopping
>
>> Alice from recording the audio, or forwarding it to a third party.  So
>
>> Bob could in fact be talking to Mary if that's how Alice wants to
>> arrange things (_behind_ her user agent).  In general, Bob is assured
>> only that he is talking to someone Alice wants him to talk to, and
>> that no one can snoop without Alice's permission.  That's very much
>> the way things work with the call center - you are sure that you are
>> 1) connected securely to your bank 2) talking to someone that the bank
>
>> wants you to talk to 3) being recorded or snooped on only when the
>> bank explicitly chooses to do so.
>>
>> - Jim
>>
>> -----Original Message----- From: rtcweb-bounces@ietf.org
>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Marshall Eubanks Sent:
>> Monday, April 30, 2012 11:42 PM To: Hutton, Andrew Cc:
>> rtcweb@ietf.org Subject: Re: [rtcweb] Use Case draft
>>
>> 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
>>>
>> _______________________________________________ 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
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb