Re: [rtcweb] Comments on draft-ietf-rtcweb-use-cases-and-requirements-07

Hi Cullen

Inline.

Göran 

> -----Original Message-----
> From: rtcweb-bounces@ietf.org 
> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings
> Sent: den 16 maj 2012 03:31
> To: rtcweb@ietf.org
> Subject: [rtcweb] Comments on 
> draft-ietf-rtcweb-use-cases-and-requirements-07
> 
> 
> Cone and symmetric nat are probably not what exactly what we 
> mean here - perhaps just refer to it as the various types of 
> NATs described in RFC 4787. 
> 
> Might want to add to some use case that when A calls B, and B 
> does not reveal their IP address to A.
> 
> Like to add Alice calls Bob with an encrypted media. Bob can 
> tell the that the encrypted media is from Alice and not from an MITM
> 
> Like to add ability to make a call in a situation where even 
> small sounds from microphone should be sent to the other side 
> and not filtered out. Emergency calls are examples of this as 
> are some games and "jam session"
> 
> Like to add case where application has one two video streams 
> but one is far more important than the other. Should be a way 
> to make sure that preferential treatment is given the the 
> important stream over the less important streams. 

I agree that this is a relevant area to address to secure that WebRTC is competitive compared to
apps done in native OS's, especiallin in enterprise context.

The current use case document states something like "being able to use priority functions in network nodes".
This is vague since it touches many matters such as whether to put audio and video on the same IP-flow or have them in different
ones, which is essential when considering mapping on LTE radio channels; the potential use of DS to identify flows, which
may be relevant in enterprise context, etc, how to cater for treament of stuff on the datagram channel, multihoming consequences, etc.

I am not sure however how far into such matters we should go in this WG, but given the importance of making a
good solution working across OS's and browser vendors and access technologies, I am leaning towards support a discussions about such
details in this WG for instance using the use case document.

What is Your take of this? 

> 
> In F22, "the IVR" -> "an DTMF based IVR"
> 
> I have a hard time deciding what level the requirements 
> should be at. It seems likely that given the level they are 
> currently at, the requirements are somewhat incomplete. As 
> long as we treat these as partial set of requirements derived 
> from the use cases, I'm fine with that. 
> 
> 
> New use case:
> 
> Imagine a service like webex that facilitates collaboration 
> between two companies called A and B. Webex has no need to 
> see the content of the communication from A to B. So webex 
> might run the web server that helps set up a RTCWeb session 
> between A and B, but webex needs to be able to write it's 
> code such that it does not get the keying material used to 
> encrypt the media from A to B and the companies need to be 
> able to verify that webex did not get the keys. Webex has no 
> need to see the media from A to B and if it can provide this 
> sort of promise that it does not get the media, it makes it 
> much easier for a customer (say Juniper) to use webex and 
> know the contents of their calls are not being sold or used 
> by a competitor. Given how much WebRTC will be used by cloud 
> services, this is an important feature. When installing the 
> "webex" application in the browser and granting permissions 
> to the application, it would be good to have one of the 
> permissions be if the JS got access to  the media or keying 
> material for it to enforce this promise. 
> 
> Note this use case is not phrase to say this is the only way 
> it can work. This is not mutually exclusive with they type of 
> use cases described by Skype folks where there is an 
> explicitly desire to make sure the calling service does have 
> the keys to decrypt the media. 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 