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
- 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