Re: [rtcweb] Use Case draft

["Ravindran, Parthasarathi" <[e-mail]>]

Igor,

When you call Company X, you need to assure that you are talking with Company X agent and not required to distinguish the agent.

The identity could be just X (no userpart) or anonymous. There is no difference between anonymous and agent007@X as there is no means to route directly agent007@x in the call centre scenario.

Thanks
Partha



>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf
>Of Igor Faynberg
>Sent: Wednesday, May 02, 2012 9:39 PM
>To: [e-mail]
>Subject: Re: [rtcweb] Use Case draft
>
>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
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb