Subject: [rtcweb] Regarding the use-case document

From: Stefan Hakansson LK <[email-masked]>
Date: Wed, 30 May 2012 10:53:56 +0200

The rtcweb chairs asked for input on the use-case document on April 27th
[1].

Browsing the emails that followed, I note:

1. Proposal for a call center use case (made by Jim Barnett) [2]

2. Proposal to add peer-to-peer file sharing to the simple video comm
service (made by Tim Terriberri) [3]

3. Comments related to security, SRTP and key exchange, F20 (by Dan 
Wing) [4]

4. Request for clarifying “eavesdropping”, Andrew Hutton [5]

5. Enterprise policies use-cases proposed, Roman Shpount [6]

6. Multiparty with low complex central node, Stefan Håkansson [7]

7. Multiparty with central node that can not decipher media Oscar
Ohlsson [8]

8. Four new reqs proposed (to be mapped to either new or existing
use-cases), one additional use-case proposed, by Cullen Jennings [9]. Reqs:
8a. Req: When A calls B, B does not reveal their IP address to A
8b. Req: B can tell that the encrypted media is from A and not
from a MITM
8c. Req: Be able to switch off Voice activity detection (if present)
8d. Req: Be able to prioritize between streams
New use-case: “Collaboration between companies with node [in
media path] that does/can not decipher media”

9. Proposal from Magnus Westerlund to clarify the language a bit
[10] regarding 4. in this list

Is anything important missing from the list above?

Going through this list (and the discussion that followed on each item)
it seems quite clear that:

A. The language should be clarified (as Magnus proposed [10]), e.g. to 
clarify that also the data channel should be encrypted (this relates
to 3. and 9. in the previous list)

B. One more derivative of the “Simple Video Communication Service” 
use-case should be added to add peer-to-peer file sharing (this proposal
got some support, no objection, and was also mentioned many times during
the MV interim)

C. There is no need to clarify “eavesdropping” (item 4. in the previous 
list); EKR proposed to do that as part of the security document instead

D. For the new requirements proposed by Cullen (8a - d in the previous 
list), 8a and 8b can be incorporated in existing use cases, 8c is 
already covered in the “Distributed Music Band” use-case, 8d can be
added to the “Hockey Game Viewer” use case. Regarding 8d it can be noted 
that there is already a requirement on "being able to use priority 
functions in network nodes" (F24); 8d would be different and relate more 
to how the browser reduces send rate for different flows as a response 
to e.g. network congestion. The reqs seem  uncontroversial to me.

Unless there are objections to this, the editors plan to update the 
document according to A - D above.

It is less clear on what to do regarding the call-center use
case [2], the enterprise policies use-cases [6] and the two use-cases
where a central node (in the media path) must not be able to access
deciphered media [8] and [9]; I think this should be discussed at the
interim meeting.

Comments?

Stefan

[1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04202.html
[2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04203.html
[3] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04204.html
[4] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04205.html
[5] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04241.html
[6] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04271.html
[7] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04430.html
[8] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04457.html
[9] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04461.html
[10] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04214.html

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 30 May 2012 09:31:39 +0000

Stefan,

1) I have mentioned in Call Center [2] usecase calls for "Anonymous" identity for agents (http://www.ietf.org/mail-archive/web/rtcweb/current/msg04295.html) and also Andrew Hutton mentioned the same in the another mail (http://www.ietf.org/mail-archive/web/rtcweb/current/msg04221.html)

2) Also in another mail thread, "Anonymous" identity for customer is discussed  as part of http://www.ietf.org/mail-archive/web/rtcweb/current/msg04254.html

In case any more information required for clarity, please let me know. Also, I'm fine with discussion about these usecase in interim meeting.  

Thanks
Partha

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Stefan Hakansson LK
>Sent: Wednesday, May 30, 2012 2:24 PM
>To: [email-masked]
>Subject: [rtcweb] Regarding the use-case document
>
>4. Request for clarifying "eavesdropping", Andrew Hutton [5]
>
>8. Four new reqs proposed (to be mapped to either new or existing use-
>cases), one additional use-case proposed, by Cullen Jennings [9]. Reqs:
>8a. Req: When A calls B, B does not reveal their IP address to A 8b.
>Req: B can tell that the encrypted media is from A and not from a MITM
>8c. Req: Be able to switch off Voice activity detection (if present) 8d.
>Req: Be able to prioritize between streams New use-case: "Collaboration
>between companies with node [in media path] that does/can not decipher
>media"
>
>9. Proposal from Magnus Westerlund to clarify the language a bit [10]
>regarding 4. in this list
>
>clarify that also the data channel should be encrypted (this relates to
>3. and 9. in the previous list)
>
>B. One more derivative of the "Simple Video Communication Service"
>C. There is no need to clarify "eavesdropping" (item 4. in the previous
>already covered in the "Distributed Music Band" use-case, 8d can be
>added to the "Hockey Game Viewer" use case. Regarding 8d it can be noted
>_______________________________________________
>rtcweb mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Stefan Hakansson LK <[email-masked]>
Date: Thu, 31 May 2012 09:27:54 +0200

On 05/30/2012 11:31 AM, Ravindran, Parthasarathi wrote:
> Stefan,
>
>
> 1) I have mentioned in Call Center [2] usecase calls for "Anonymous"
> identity for agents
> (http://www.ietf.org/mail-archive/web/rtcweb/current/msg04295.html)
> and also Andrew Hutton mentioned the same in the another mail
> (http://www.ietf.org/mail-archive/web/rtcweb/current/msg04221.html)
>
> 2) Also in another mail thread, "Anonymous" identity for customer is
> discussed  as part of
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04254.html
>
> In case any more information required for clarity, please let me
> know. Also, I'm fine with discussion about these usecase in interim
> meeting.

Hi Partha,

I would prefer if we discussed this at the interim before adding. The 
main reason is that the use-case document, and requirements, currently 
focus on media and data streams. When doing the first draft we 
deliberately left things like identity handling, find-and-connect and so 
on out of scope.

This was partly inspired by the charter (that talks about enabling 
innovation on top of a set of basic components - those being 
peer-to-peer audio, video and data) and partly from that there are 
already a lot of web services used every day which has solved this - 
they have implemented presence, text chat, messaging, ... already and in 
theory it would be simple to add video etc. if we just got those "basic 
components" in place.

If the use-case document is to be updated to cover things like identity, 
user management and so on that would be a big change, and I would prefer 
that to be discussed before starting actual work.

Br,
Stefan

>
> Thanks Partha
>
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Stefan Hakansson LK
>> Sent: Wednesday, May 30, 2012 2:24 PM To: [email-masked] Subject:
>> [rtcweb] Regarding the use-case document
>>
>> The rtcweb chairs asked for input on the use-case document on April
>> 27th [1].
>>
>> 2. Proposal to add peer-to-peer file sharing to the simple video
>> comm service (made by Tim Terriberri) [3]
>>
>> 3. Comments related to security, SRTP and key exchange, F20 (by
>> Dan Wing) [4]
>>
>> use- cases), one additional use-case proposed, by Cullen Jennings
>> [9]. Reqs: 8a. Req: When A calls B, B does not reveal their IP
>> address to A 8b. Req: B can tell that the encrypted media is from A
>> and not from a MITM 8c. Req: Be able to switch off Voice activity
>> detection (if present) 8d. Req: Be able to prioritize between
>> streams New use-case: "Collaboration between companies with node
>> [in media path] that does/can not decipher media"
>>
>> Going through this list (and the discussion that followed on each
>> item) it seems quite clear that:
>>
>> A. The language should be clarified (as Magnus proposed [10]), e.g.
>> to clarify that also the data channel should be encrypted (this
>> relates to 3. and 9. in the previous list)
>>
>> use-case should be added to add peer-to-peer file sharing (this
>> proposal got some support, no objection, and was also mentioned
>> many times during the MV interim)
>>
>> C. There is no need to clarify "eavesdropping" (item 4. in the
>> previous list); EKR proposed to do that as part of the security
>> document instead
>>
>> D. For the new requirements proposed by Cullen (8a - d in the
>> previous list), 8a and 8b can be incorporated in existing use
>> cases, 8c is already covered in the "Distributed Music Band"
>> use-case, 8d can be added to the "Hockey Game Viewer" use case.
>> Regarding 8d it can be noted that there is already a requirement on
>> "being able to use priority functions in network nodes" (F24); 8d
>> would be different and relate more to how the browser reduces send
>> rate for different flows as a response to e.g. network congestion.
>> The reqs seem  uncontroversial to me.
>>
>> Unless there are objections to this, the editors plan to update
>> the document according to A - D above.
>>
>>
>>
>> It is less clear on what to do regarding the call-center use case
>> [2], the enterprise policies use-cases [6] and the two use-cases
>> where a central node (in the media path) must not be able to
>> access deciphered media [8] and [9]; I think this should be
>> discussed at the interim meeting.
>>
>> Comments?
>>
>> Stefan
>>
>> [1]
>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04202.html
>> [2]
>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04203.html
>> [3]
>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04204.html
>> [4]
>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04205.html
>> [5]
>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04241.html
>> [6]
>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04271.html
>> [7]
>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04430.html
>> [8]
>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04457.html
>> [9]
>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04461.html
>> [10]
>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04214.html
>> _______________________________________________ rtcweb mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Jim Barnett" <[email-masked]>
Date: Thu, 31 May 2012 06:04:17 -0700

Yes, let's set aside some time to discuss this at the interim.  When I brought up call center use cases a while ago, we reached the conclusion that the webRTC endpoint was the corporate gateway/ACD and that anything behind it (including the agent) was out of scope (which is another way of saying that it could work any way the corporation wanted.)  The result was that call centers fell under legacy inter-op and no changes were needed to the use cases.  

In general corporate/call center uses of webRTC will be important, so it's worth going over this once more to make sure we agree on how they fit into the framework.

- Jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Hakansson LK
Sent: Thursday, May 31, 2012 3:28 AM
To: Ravindran, Parthasarathi
Cc: [email-masked]
Subject: Re: [rtcweb] Regarding the use-case document

On 05/30/2012 11:31 AM, Ravindran, Parthasarathi wrote:
> In case any more information required for clarity, please let me know. 
> Also, I'm fine with discussion about these usecase in interim meeting.

Hi Partha,

I would prefer if we discussed this at the interim before adding. The main reason is that the use-case document, and requirements, currently focus on media and data streams. When doing the first draft we deliberately left things like identity handling, find-and-connect and so on out of scope.

This was partly inspired by the charter (that talks about enabling innovation on top of a set of basic components - those being peer-to-peer audio, video and data) and partly from that there are already a lot of web services used every day which has solved this - they have implemented presence, text chat, messaging, ... already and in theory it would be simple to add video etc. if we just got those "basic components" in place.

If the use-case document is to be updated to cover things like identity, user management and so on that would be a big change, and I would prefer that to be discussed before starting actual work.

Br,
Stefan

>> detection (if present) 8d. Req: Be able to prioritize between streams 
>> New use-case: "Collaboration between companies with node [in media 
>> path] that does/can not decipher media"
>>
>> proposal got some support, no objection, and was also mentioned many 
>> times during the MV interim)
>>
>> previous list), 8a and 8b can be incorporated in existing use cases, 
>> 8c is already covered in the "Distributed Music Band"
>> _______________________________________________ rtcweb mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Tim Panton <[email-masked]>
Date: Thu, 31 May 2012 14:31:37 +0100

Much as I hate to re-open this, I think there is a significant use-case for Agents using webRTC,
especially in pop-up (e.g. campaign based) call centers.

This would (potentially  be the reverse of the case you described, with webRTC on the inside, 
probably still talking through the ACD/gateway.

So, yes, this merits some further discussion in my view too.

T.