IETF Logo Mail Archive

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

Cullen Jennings <fluffy@cisco.com> Wed, 16 May 2012 01:31 UTC

Return-Path: <fluffy@cisco.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B98A11E8095 for <rtcweb@ietfa.amsl.com>; Tue, 15 May 2012 18:31:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.327
X-Spam-Level:
X-Spam-Status: No, score=-110.327 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIbpjZw0Co1C for <rtcweb@ietfa.amsl.com>; Tue, 15 May 2012 18:31:19 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA1911E8099 for <rtcweb@ietf.org>; Tue, 15 May 2012 18:31:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2624; q=dns/txt; s=iport; t=1337131879; x=1338341479; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=i9KEg6u2+XYynqyV4s8uULr6PuomLtGaKOZB7/soEOc=; b=jeOnOt0laPPq5okRRA9AA6g2OZZmxzsugsOl90TPv3X1dut5TFgc9wqe 9YRZ5aNHVbjlEKPpvzlWRomI8c5SjnVVYH0WLKz1Z/tJqEQKeJ4pUnZl3 /N/Z0sYqrF/rJ9ZQvNGUSpFSdKbM5S5LZfkhskXpra2uijPTZ4lXIaF6G Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmYFACwCs0+rRDoI/2dsb2JhbABEgx2wZoEHgi4BFBOCMoVwgXuZb4EooBWNToJDYwSIZI0ZhXWIYoFpgwiBQA
X-IronPort-AV: E=Sophos;i="4.75,599,1330905600"; d="scan'208";a="42377395"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 16 May 2012 01:31:19 +0000
Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q4G1VIvL005217 for <rtcweb@ietf.org>; Wed, 16 May 2012 01:31:18 GMT
From: Cullen Jennings <fluffy@cisco.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 15 May 2012 19:31:18 -0600
Message-Id: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com>
To: rtcweb@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [rtcweb] Comments on draft-ietf-rtcweb-use-cases-and-requirements-07
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 May 2012 01:31:20 -0000

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. 

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.

v2.23.0 | Report a Bug | By Email