Re: [rtcweb] Use Case draft

[Igor Faynberg <[e-mail]>]

I am afraid I don't understand this.

For the call center case, when I "call" company X, I would like to make 
sure that I am connected to an agent representing X, and so the identity 
should looke like something "X_Agent_707," not "Anonymous."

Igor

On 5/2/2012 5: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.
>
> Thanks
> Partha
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Stefan Hakansson LK
>> Sent: Wednesday, May 02, 2012 2:16 PM
>> To: [e-mail]
>> 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: [e-mail]
>>> [mailto:[e-mail]] On Behalf Of Marshall Eubanks Sent:
>>> Monday, April 30, 2012 11:42 PM To: Hutton, Andrew Cc:
>>> [e-mail] Subject: Re: [rtcweb] Use Case draft
>>>
>>> On Mon, Apr 30, 2012 at 2:31 PM, Hutton,
>>> Andrew<[e-mail]>   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: [e-mail] [mailto:[e-mail]] On
>>>> Behalf Of Igor Faynberg Sent: 30 April 2012 17:41 To:
>>>> [e-mail]
>>>>
>>>>
>>>> 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
>>>>
>>>> [e-mail]
>>>>
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>
>>>>
>>>> _______________________________________________ rtcweb mailing list
>>>> [e-mail] https://www.ietf.org/mailman/listinfo/rtcweb
>>>>
>>> _______________________________________________ rtcweb mailing list
>>> [e-mail] https://www.ietf.org/mailman/listinfo/rtcweb
>>> _______________________________________________ rtcweb mailing list
>>> [e-mail] https://www.ietf.org/mailman/listinfo/rtcweb
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb