Re: [rtcweb] Use Case draft
Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com> Wed, 02 May 2012 13:57 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 0173921F85E5 for <rtcweb@ietfa.amsl.com>; Wed, 2 May 2012 06:57:34 -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 gLphNAJmuFTQ for <rtcweb@ietfa.amsl.com>; Wed, 2 May 2012 06:57:33 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9830121F85F0 for <rtcweb@ietf.org>; Wed, 2 May 2012 06:57:32 -0700 (PDT)
X-AuditID: c1b4fb30-b7b07ae000006839-50-4fa13d4bd4b4
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B9.68.26681.B4D31AF4; Wed, 2 May 2012 15:57:31 +0200 (CEST)
Received: from [150.132.142.229] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 May 2012 15:57:30 +0200
Message-ID: <4FA13D49.3030303@ericsson.com>
Date: Wed, 02 May 2012 15:57:29 +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: "Ravindran, Parthasarathi" <pravindran@sonusnet.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> <387F9047F55E8C42850AD6B3A7A03C6C148913C5@inba-mail02.sonusnet.com>
In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C148913C5@inba-mail02.sonusnet.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 13:57:34 -0000
On 05/02/2012 11:05 AM, Ravindran, Parthasarathi wrote: > Stefan, > > This usecase add its own requirements from identity perspective as > I mentioned earlier. > > WebRTC MUST allow "Anonymous" users secure session for call center > usecase. "Anonymous" User may be agent in the call center side or > customer who does not require Identity to start the session. There is currently no requirement on "identity" in the document at all. It was deemed beyond the scope of it when the first version was created (and I think this what we tried say with the initial section on that the "document focuses on requirements related to real-time media streams."). This was also inspired by that web applications usually deal with identity in the app itself. Identity has since been discussed at length. I think it is up to the group and the chairs to decide if the document should be updated to cover identity, and how that (in that case) should be phrased. Br, Stefan > > Thanks > Partha > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >> Of Stefan Hakansson LK >> Sent: Wednesday, May 02, 2012 2:16 PM >> 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
- Re: [rtcweb] Use Case draft Timothy B. Terriberry
- [rtcweb] Use Case draft Ted Hardie
- Re: [rtcweb] Use Case draft Jim Barnett
- Re: [rtcweb] Use Case draft Bernard Aboba
- Re: [rtcweb] Use Case draft Ravindran, Parthasarathi
- Re: [rtcweb] Use Case draft Tim Panton
- Re: [rtcweb] Use Case draft Ravindran, Parthasarathi
- Re: [rtcweb] Use Case draft (privacy) Fabio Pietrosanti (naif)
- Re: [rtcweb] Use Case draft (privacy) Ravindran, Parthasarathi
- Re: [rtcweb] Use Case draft (privacy) Hutton, Andrew
- Re: [rtcweb] Use Case draft Stefan Hakansson LK
- Re: [rtcweb] Use Case draft Jim Barnett
- Re: [rtcweb] Use Case draft Tim Panton
- Re: [rtcweb] Use Case draft Igor Faynberg
- Re: [rtcweb] Use Case draft Hutton, Andrew
- Re: [rtcweb] Use Case draft Randell Jesup
- Re: [rtcweb] Use Case draft Randell Jesup
- Re: [rtcweb] Use Case draft Stephan Wenger
- Re: [rtcweb] Use Case draft Randell Jesup
- Re: [rtcweb] Use Case draft Marshall Eubanks
- Re: [rtcweb] Use Case draft Stefan Hakansson LK
- Re: [rtcweb] Use Case draft Tim Panton
- Re: [rtcweb] Use Case draft Jim Barnett
- Re: [rtcweb] Use Case draft Jim Barnett
- Re: [rtcweb] Use Case draft - Eavesdropping. Stefan Hakansson LK
- Re: [rtcweb] Use Case draft Marshall Eubanks
- Re: [rtcweb] Use Case draft - Eavesdropping. Hutton, Andrew
- Re: [rtcweb] Use Case draft - Eavesdropping. Fabio Pietrosanti (naif)
- Re: [rtcweb] Use Case draft - Eavesdropping. Eric Rescorla
- Re: [rtcweb] Use Case draft - Eavesdropping. Cavigioli, Chris
- Re: [rtcweb] Use Case draft - Eavesdropping. Marshall Eubanks
- Re: [rtcweb] Use Case draft Randell Jesup
- Re: [rtcweb] Use Case draft - Eavesdropping. Randell Jesup
- Re: [rtcweb] Use Case draft Stefan Hakansson LK
- Re: [rtcweb] Use Case draft Ravindran, Parthasarathi
- Re: [rtcweb] Use Case draft - Eavesdropping. Harald Alvestrand
- Re: [rtcweb] Use Case draft Stefan Hakansson LK
- Re: [rtcweb] Use Case draft Jim Barnett
- Re: [rtcweb] Use Case draft Stefan Hakansson LK
- Re: [rtcweb] Use Case draft Igor Faynberg
- [rtcweb] interworking with non-WEBRTC endpoints [… Dan Wing
- Re: [rtcweb] interworking with non-WEBRTC endpoin… Iñaki Baz Castillo
- Re: [rtcweb] interworking with non-WEBRTC endpoin… Marshall Eubanks
- Re: [rtcweb] interworking with non-WEBRTC endpoin… Lorenzo Miniero
- Re: [rtcweb] interworking with non-WEBRTC endpoin… Mary Barnes
- Re: [rtcweb] interworking with non-WEBRTC endpoin… Marshall Eubanks
- Re: [rtcweb] interworking with non-WEBRTC endpoin… Fabio Pietrosanti (naif)
- Re: [rtcweb] interworking with non-WEBRTC endpoin… Dan Wing
- Re: [rtcweb] Use Case draft Ravindran, Parthasarathi
- Re: [rtcweb] interworking with non-WEBRTC endpoin… Ravindran, Parthasarathi
- Re: [rtcweb] interworking with non-WEBRTC endpoin… Harald Alvestrand
- Re: [rtcweb] Use Case draft Harald Alvestrand
- Re: [rtcweb] interworking with non-WEBRTC endpoin… Fabio Pietrosanti (naif)
- Re: [rtcweb] Use Case draft Ravindran, Parthasarathi
- Re: [rtcweb] Use Case draft Harald Alvestrand
- Re: [rtcweb] interworking with non-WEBRTC endpoin… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] Use Case draft Jim Barnett
- Re: [rtcweb] Use Case draft Stefan Hakansson LK
- Re: [rtcweb] interworking with non-WEBRTC endpoin… Bernard Aboba
- Re: [rtcweb] Use Case draft Jim Barnett
- Re: [rtcweb] Use Case draft - legacy interop Harald Alvestrand
- Re: [rtcweb] interworking with non-WEBRTC endpoin… Neil Stratford
- Re: [rtcweb] interworking with non-WEBRTC endpoin… Iñaki Baz Castillo
- Re: [rtcweb] interworking with non-WEBRTC endpoin… Christer Holmberg
- Re: [rtcweb] interworking with non-WEBRTC endpoin… Iñaki Baz Castillo
- Re: [rtcweb] interworking with non-WEBRTC endpoin… Richard Shockey
- Re: [rtcweb] interworking with non-WEBRTC endpoin… Xavier Marjou
- Re: [rtcweb] Use Case draft - legacy interop Bernard Aboba
- Re: [rtcweb] Use Case draft - legacy interop Iñaki Baz Castillo
- Re: [rtcweb] Use Case draft - legacy interop Dan Wing
- Re: [rtcweb] Use Case draft - legacy interop Iñaki Baz Castillo
- Re: [rtcweb] Use Case draft - legacy interop Bernard Aboba
- Re: [rtcweb] Use Case draft - legacy interop Dan Wing
- Re: [rtcweb] Use Case draft - legacy interop Harald Alvestrand
- [rtcweb] Consent freshness and message-integrity … Harald Alvestrand
- Re: [rtcweb] Consent freshness and message-integr… Dan Wing
- Re: [rtcweb] Consent freshness and message-integr… Harald Alvestrand