Re: [rtcweb] Use Case draft

["Jim Barnett" <[e-mail]>]

Yes, I think that you're right that specifying the exact set of legacy
devices would be a painful task.  It may be that the current
requirements are sufficient for the call center use case, as long as we
understand that in that use case it is the call center gateway, and not
the agent workstation/browser, that is the webRTC endpoint.  The call
center's requirements for routing, recording/monitoring, etc. are
awfully hard to combine with webRTC if we think of the webRTC call as
going all the way to the agent.  

- Jim
P.S. Roman's enterprise  use cases are distinct from the call center
case, and do involve webRTC connections extending all the way into the
enterprise.  

-----Original Message-----
From: Stefan Hakansson LK [mailto:[e-mail]] 
Sent: Thursday, May 03, 2012 10:44 AM
To: Jim Barnett
Cc: [e-mail]
Subject: Re: [rtcweb] Use Case draft

On 05/03/2012 03:06 PM, Jim Barnett wrote:
> Yes, the use cases in  4.3 are browser-GW, though none of them really 
> covers the call center case (routing to an arbitrary agent, recording 
> the call, etc.)
>
> However, the requirements in section 5 don't seem to mention legacy 
> connectivity, unless that's what F27 is supposed to cover ("The 
> browser MUST be able to initiate and accept a media session where the 
> data needed for establishment can be carried in SIP.")  It might be 
> good to have a specific legacy requirement along the forms of "The 
> Browser must be able to communicate with legacy devices that have the 
> following characteristics ...." Of course, this gets into the whole 
> interoperability discussion. For example, should the Browser be able 
> to interoperate with devices that don't support  ICE?  (I have been 
> assuming that the call center gateway would  support ICE).

I think reqs F21 and F22 are typical legacy device interop related
requirements as well.

What we did when writing the document was to assume that the device in
the other end of a connection would have to implement basically the same
set of protocols as a browser, then we added some specific requirements
to simplify/reduce cost (carry signaling in SIP, telco codec, DTMF).

I say this to explain why there is no specific requirement on "must be
able to interop with a device having the following characteristics", not
to say that such a req does not make sense.

That said, I'm afraid that the work required to specify the exact
characteristics of devices that the browser must be able to interop with
would be very big. Would not the discussion lead into every nitty gritty
detail?

>
> The enterprise use cases that Roman has mentioned are separate from 
> this, and would add new requirements, since they involve webRTC within

> the enterprise connecting to external webRTC endpoints.  In the call 
> center use case, the webRTC call is terminated at the gateway.
>
> - Jim
>
> -----Original Message-----
> From: Stefan Hakansson LK [mailto:[e-mail]]
> Sent: Wednesday, May 02, 2012 11:49 AM
> To: Jim Barnett
> Cc: [e-mail]
> Subject: Re: [rtcweb] Use Case draft
>
> 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: [e-mail] [mailto:[e-mail]] On 
>> Behalf Of Stefan Hakansson LK
>> Sent: Wednesday, May 02, 2012 4:46 AM
>> 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
>