Re: [rtcweb] Use Case draft

[Stefan Hakansson LK <[e-mail]>]

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