Re: [rtcweb] Use Case draft

[Marshall Eubanks <[e-mail]>]

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
>