Subject: [rtcweb] Use Case draft

From: Ted Hardie <[email-masked]>
Date: Fri, 27 Apr 2012 09:15:23 -0700

The chairs would like to ask the working group to focus on the use
case draft.  If you have use cases that need to be added to the
document or text changes you'd like to suggest, please send them in
for discussion before May 15th.  After this round, we will look toward
having a working group last call on the document (hopefully before the
interim meeting).

regards,

Ted, Magnus, Cullen

---

From: "Jim Barnett" <[email-masked]>
Date: Fri, 27 Apr 2012 09:35:55 -0700

I would like to see a corporate call center use case.  Specifically, a
user downloads a web page from a corporate web site, clicks a 'call us'
button and is connected to a gateway server that is controlled by the
corporation.  The communication up to the corporate boundary cannot be
eavesdropped, but, inside the corporate boundary:  1) the corporation
can route the call to whoever it wants (meaning that the caller can
verify that he is connected to the corporation, but is not necessarily
assured of the identity of the person he is speaking to within the
corporation) 2) the corporation can eavesdrop/record the call (n.b. this
is mandatory in financial institutions, and common in most others). 

This corresponds to a very common current PSTN use case (except that
with webRTC the call is more secure up to the corporate boundary).  I
think that corporations will be eager to add webRTC support to their
call centers - as long as it doesn't mess up their existing operations
(call routing, recording, etc.)  They will most likely want to put in a
gateway, and treat it as the webRTC endpoint.  Inside the gateway the
call should look just like one that came in from the PSTN (via a SIP
trunk or PSTN/SIP gateway.)

I think others have suggested use cases involving outbound calls from
corporations, but I think that those should probably be treated
separately.  

- Jim 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ted Hardie
Sent: Friday, April 27, 2012 12:15 PM
To: [email-masked]
Subject: [rtcweb] Use Case draft

The chairs would like to ask the working group to focus on the use case
draft.  If you have use cases that need to be added to the document or
text changes you'd like to suggest, please send them in for discussion
before May 15th.  After this round, we will look toward having a working
group last call on the document (hopefully before the interim meeting).

regards,

Ted, Magnus, Cullen
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Fri, 27 Apr 2012 09:43:53 -0700

> document or text changes you'd like to suggest, please send them in

I proposed the following use-case back in February, but there wasn't 
much discussion on actually adding it to the document: 
http://www.ietf.org/mail-archive/web/rtcweb/current/msg03357.html

Let me know if the WG would like to proceed with something like this.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 29 Apr 2012 10:20:57 -0700

I agree that the corporate call center use case is important. 

> Date: Fri, 27 Apr 2012 09:35:55 -0700
> From: [email-masked]
> To: [email-masked]; [email-masked]
> Subject: Re: [rtcweb] Use Case draft
>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 30 Apr 2012 04:59:18 +0000

+1

The consumer call center shall support "anonymous" calling wherein there is no need of specific identity mechanism for the caller.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Sunday, April 29, 2012 10:51 PM
To: [email-masked]; [email-masked]
Subject: Re: [rtcweb] Use Case draft

> From: [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf
> Of Ted Hardie
> To: [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Tim Panton <[email-masked]>
Date: Mon, 30 Apr 2012 08:41:46 +0100

My experience of this (with phonefromhere.com) is that there is very limited demand for 
pure click-to-call in the browser. Users don't see any benefit.

The benefit comes if the call in tied into the rest of the web session, so full anonymity 
isn't desirable in this case.
The best results come when the call center is also using similar in-browser technology 
and the session can be properly shared.

So while this use-case has some merit, it shouldn't be seen as critical.

Tim.

On 30 Apr 2012, at 05:59, Ravindran, Parthasarathi wrote:

> +1
>  
> The consumer call center shall support “anonymous” calling wherein there is no need of specific identity mechanism for the caller.    
>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 30 Apr 2012 08:42:25 +0000

Tim,

My experience is different. Click-to-call is attractive in case of toll-free number in the site. WebRTC provides complete free call without any toll.

The registered users should not mandated as it is not generically applicable for all sites. In case of  camera selling site wherein the anonymous customer wish to get the details about the product wherein the sites will not mandate for registration before calling the shop as today, these sites provide their phone number for the customer to contact without any identity.  I really don't know why some identity MUST be mandated  for calling those WebRTC sites. The customer support folks will get the relevant information during the course of the call :)

Having [email-masked]<mailto:[email-masked]> as a identity is not going to much helpful in these sites whereas captcha will confirm the caller as a human.

Thanks
Partha

From: Tim Panton [mailto:[email-masked]]
Sent: Monday, April 30, 2012 1:12 PM
To: Ravindran, Parthasarathi
Cc: Bernard Aboba; [email-masked]; [email-masked]
Subject: Re: [rtcweb] Use Case draft

My experience of this (with phonefromhere.com<http://phonefromhere.com>) is that there is very limited demand for
pure click-to-call in the browser. Users don't see any benefit.

Tim.

+1

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Sunday, April 29, 2012 10:51 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Use Case draft

---

From: "Fabio Pietrosanti (naif)" <[email-masked]>
Date: Mon, 30 Apr 2012 11:04:33 +0200

> is mandatory in financial institutions, and common in most others). 

In that case, from a privacy perspective, it's HIGHLY RELEVANT to show
in the UI to the user that the call does it's encrypted up to a gateway
and not up to another peer.

Please get back the thread on end-to-end vs end-to-site security.

The user *must known and be aware* if a call is secured between two
peers or if it's not secured up to a gateway (and who control such a
gateway).

Fabio

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 30 Apr 2012 09:11:57 +0000

Fabio,

Please note that gateway shall acts as web-browser and compliance to RTCWeb specifications. Here, WebRTC session is between general-purpose web-browser like IE, Chrome in the customer side and customized web-browser in the site side. 

Thanks
Partha

>Of Fabio Pietrosanti (naif)
>Sent: Monday, April 30, 2012 2:35 PM
>To: [email-masked]
>Subject: Re: [rtcweb] Use Case draft (privacy)
>
>> corporation) 2) the corporation can eavesdrop/record the call (n.b.
>> this is mandatory in financial institutions, and common in most
>others).
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 30 Apr 2012 13:38:18 +0200

Hi,

I also agree that calling a corporate call center is an interesting use case and I think we discussed it in the past in the context of media recording and identity.

When calling your bank it is only necessary to know that you are talking to a representative of mybank.com the bank certainly does not want to release the identity of the call centre agent you are talking to. From the consumer perspective they want to be sure that the call really did reach mybank.com but from there on they have to trust the bank with their information and really this is no different for audio/video than it is for text entered on a web page and of course the bank will record the audio.

In this scenario it is really not useful to confuse the calling user with indications of whether the bank encrypts the audio/video when handling it internally or not it is enough to know that they have a secure connection to their bank. 

Regards
Andy  

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ravindran, Parthasarathi
> Sent: 30 April 2012 10:12
> To: Fabio Pietrosanti (naif); [email-masked]
> Please note that gateway shall acts as web-browser and compliance to
> RTCWeb specifications. Here, WebRTC session is between general-purpose
> web-browser like IE, Chrome in the customer side and customized web-
> browser in the site side.
> 
> Thanks
> Partha
>

---

From: Stefan Hakansson LK <[email-masked]>
Date: Mon, 30 Apr 2012 13:41:50 +0200

> Let me know if the WG would like to proceed with something like this.

I think adding another small derivative of the simple video chat (this 
one with peer-to-peer file transfer added) makes a lot of sense. For 
one, we get a use case that requires reliable data (now we only have a 
req for "short latency datagram" which sound like unreliable to me); in 
addition we get a requirement for the data channel API to be able to use 
blobs (as defined in the File API W3C rec) as input/output.

A third good requirement that can be derived (if we want to) is the 
ability to prioritize data in relation to audio/video.

So, I think we should add it.

Stefan

---

From: "Jim Barnett" <[email-masked]>
Date: Mon, 30 Apr 2012 06:07:48 -0700

I think that there are two different issues here.  

1)      In many cases the call center would like to have information
about the caller's web session:  what page he is on, browsing history
information, etc.  This can be passed in the data channel.

2)      However, this does not require that the caller be authenticated
(i.e. identified as a specific individual).  The call center wants  to
know that the caller has been looking at, e.g., warranty info for
cameras on their site, but doesn't  particularly need to know the
caller's name (they can get that during the call if they need it.)   

-          Jim

From: Tim Panton [mailto:[email-masked]] 
Sent: Monday, April 30, 2012 3:42 AM
To: Ravindran, Parthasarathi
Cc: Bernard Aboba; Jim Barnett; [email-masked]
Subject: Re: [rtcweb] Use Case draft

My experience of this (with phonefromhere.com) is that there is very
limited demand for 

The benefit comes if the call in tied into the rest of the web session,
so full anonymity 

The best results come when the call center is also using similar
in-browser technology 

Tim.

+1

The consumer call center shall support "anonymous" calling wherein there
is no need of specific identity mechanism for the caller.    

Of Bernard Aboba

> corporation) 2) the corporation can eavesdrop/record the call (n.b.
this
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> The chairs would like to ask the working group to focus on the use
case

---

From: Tim Panton <[email-masked]>
Date: Mon, 30 Apr 2012 14:54:50 +0100

> My experience is different. Click-to-call is attractive in case of toll-free number in the site. WebRTC provides complete free call without any toll.

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.

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 30 Apr 2012 12:41:22 -0400

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:
> ...

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 30 Apr 2012 20:31:48 +0200

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.

So I think we need it.

Regards
Andy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Faynberg
Sent: 30 April 2012 17:41
To: [email-masked]
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.)

Igor

rtcweb mailing list

---

From: Randell Jesup <[email-masked]>
Date: Mon, 30 Apr 2012 17:00:16 -0400

> blobs (as defined in the File API W3C rec) as input/output.

The game case can need both reliable and unreliable data at the same 
time, which gets us reliable, unreliable and multiple streams.

> ability to prioritize data in relation to audio/video.

File transfer or "let me show you the photo I took" while talking would 
do I think.

-- 
Randell Jesup
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Mon, 30 Apr 2012 17:09:39 -0400

>> My experience is different. Click-to-call is attractive in case of
>> toll-free number in the site. WebRTC provides complete free call
>> without any toll.
>

How many people browsing have mic, speakers, or headphones, set up, and 
are comfortable with it?

Things are changing, but a friend who consults for non-tech small 
businesspeople and individual home-based businesses avoids using audio 
when doing screen-share type stuff and instead starts a parallel audio 
POTS call, because it's too frequently a waste of time for them to find 
and set up headphones, get their mic to work.

If it's people who are already using Skype/etc, there's a better chance 
- but they still may only be comfortable with Skype for "calls".

-- 
Randell Jesup
[email-masked]

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 30 Apr 2012 22:27:51 +0000

Hi Randell,
I don't buy this argument.
Speakers are a standard piece of equipment now; almost everyone with a PC
has them in some form.  Without a webcam, webrtc would be pretty useless,
and every webcam nowadays has a microphone.
I have no reason to distrust Tim's assessment, but the reason for the lack
of success of PC facilitated sales doers you cited, IMO, cannot be the
main reason, and certainly not among the expected users of webrtc (who
WILL have speakers, camera and mic set up, ready to go, and used to make
calls from their machine).  And if your argument refers to the call center
site--well, those guys will get their equipment right and train their
employees, or go out of business.
Lets not dismiss a use case based on short term observations.
Stephan

---

From: Randell Jesup <[email-masked]>
Date: Mon, 30 Apr 2012 19:12:46 -0400

> and every webcam nowadays has a microphone.

And why do you believe every desktop computer has a webcam?  All 
nowadays have connectors for mic and speakers, and almost all have 
speakers, but probably (guess) 50% of desktops out there don't have a 
microphone attached (probably more than 50%).

Most *laptops* have builtin cameras and mics now, but a few years ago 
that wasn't the case.

> calls from their machine).

One hopes so, yes, though webrtc does not require sending video.

>  And if your argument refers to the call center

Agreed.  I was just giving an alternate explanation why "no one clicked 
Free Internet Call", and why that was NOT a reason to invalidate the 
usecase.

-- 
Randell Jesup
[email-masked]

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 30 Apr 2012 23:41:37 -0400

On Mon, Apr 30, 2012 at 2:31 PM, Hutton, Andrew
<[email-masked]> wrote:
> 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

> cannot call the 800 number. (I routinely use Web interface for calls when
> traveling.)
>
>
>

---

From: Stefan Hakansson LK <[email-masked]>
Date: Tue, 1 May 2012 07:06:20 +0200

> time, which gets us reliable, unreliable and multiple streams.

You're right; but currently only game state updates is mentioned. 
Probably that use case should be updated.