[rtcweb] Rohan Red Cross Use Case
Cullen Jennings <email@example.com> Mon, 18 July 2011 18:30 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2699821F8B73 for <firstname.lastname@example.org>; Mon, 18 Jul 2011 11:30:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-104.193 tagged_above=-999 required=5 tests=[AWL=-1.594, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([22.214.171.124]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaUZguZgu5Ea for <email@example.com>; Mon, 18 Jul 2011 11:30:33 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [126.96.36.199]) by ietfa.amsl.com (Postfix) with ESMTP id AA66821F8B5E for <firstname.lastname@example.org>; Mon, 18 Jul 2011 11:30:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; email@example.com; l=2093; q=dns/txt; s=iport; t=1311013833; x=1312223433; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=TgPLuNG9kuunojEf4I+eT2KD/GdEz3YvU1dgvwVOd6U=; b=ior6KAglYqqplbhjdj4RDrrfH2pO0d0rTjvvc6dkJw8douLWuCOzL5k+ ktuo9MR3Pq4PJdgEbq36sfzLs6kKIUU0+5XJQEwHo+xb/asFlKh1675RJ YaFQ8XRFXLwkWPymcNKzaFV1cw5Qpk/Y8Bv0UfbtWBOndnDA/A4WzwZCK s=;
X-IronPort-AV: E=Sophos;i="4.67,223,1309737600"; d="scan'208";a="4056133"
Received: from mtv-core-1.cisco.com ([188.8.131.52]) by rcdn-iport-6.cisco.com with ESMTP; 18 Jul 2011 18:30:28 +0000
Received: from sjc-vpn3-1134.cisco.com (sjc-vpn3-1134.cisco.com [10.21.68.110]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6IIURae012426 for <firstname.lastname@example.org>; Mon, 18 Jul 2011 18:30:27 GMT
From: Cullen Jennings <email@example.com>
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 18 Jul 2011 11:30:26 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [rtcweb] Rohan Red Cross Use Case
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Mon, 18 Jul 2011 18:30:37 -0000
I'd like to add an use case along the following lines... Rohan works for international aid agency and deploys wireless networks in places where disasters have wiped out all the existing infrastructure. There's just been an earthquake in Haiti. Betty works for Canada Red Cross and need to get the Red Cross location in Haiti connected to other aid groups in Haiti to help arrange complex logistics of things like what order various aid agencies are even going to use the limited resources of the runway at the airport. Rohan and Betty both use the AidNet web application for communicating and have cached copies using the HTML5 offline support on their computers or, if they can't get their computers into the country, can at least get copy in via USB key and find a local computer with a browser. Rohan sets up a wireless access point on the tallest thing he can find and managed to provide wireless coverage for many square miles. Betty connects to that and manages to call Rohan to coordinate and let Rohan know the location of RedCross so that better wireless can be arranged there. This one more or less one of the use cases for P2PSIP work to be able to set up an ad hoc voice communications system before one even had access to DNS server or any global internet infrastructure. I think that the whole P2PSIP system could be done inside browser (or a system similar to it). The underling transport of P2PSIP is very close to the proposal here including the use of ICE. One would probably need to define a new transport that an Reload overlay could use but other than that, I think one could meet this use case using something along the lines of Reload running in browser. It gets more interesting as you add work such as what is a happening in the VIPR WG. The browser on the mobile could have access the the call logs for calls made over the cellular voice part of the phone. That would allow the browser to run the VIPR related protocols and be able to receive VoIP calls for that number.