[Ecrit] Emergency location alternative: outbound proxy adding location in formation

"Bemmel, Jeroen van (Jeroen)" <jbemmel@lucent.com> Thu, 14 April 2005 13:59 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13718; Thu, 14 Apr 2005 09:59:51 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM52r-0000Ck-7S; Thu, 14 Apr 2005 10:10:13 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM4q2-000508-KO; Thu, 14 Apr 2005 09:56:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM4JV-0007gR-A4 for ecrit@megatron.ietf.org; Thu, 14 Apr 2005 09:23:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10449 for <ecrit@ietf.org>; Thu, 14 Apr 2005 09:23:11 -0400 (EDT)
Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM4TM-00072U-Oa for ecrit@ietf.org; Thu, 14 Apr 2005 09:33:33 -0400
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j3EDN1dq014756 for <ecrit@ietf.org>; Thu, 14 Apr 2005 08:23:02 -0500 (CDT)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <26JFMFG9>; Thu, 14 Apr 2005 15:23:00 +0200
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550577DB48@nl0006exch001u.nl.lucent.com>
From: "Bemmel, Jeroen van (Jeroen)" <jbemmel@lucent.com>
To: "'ecrit@ietf.org'" <ecrit@ietf.org>
Date: Thu, 14 Apr 2005 15:23:00 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c
X-Mailman-Approved-At: Thu, 14 Apr 2005 09:56:57 -0400
Subject: [Ecrit] Emergency location alternative: outbound proxy adding location in formation
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0212997346=="
Sender: ecrit-bounces@ietf.org
Errors-To: ecrit-bounces@ietf.org
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba

Hello,
 
I have been reading the sipping-emergency architecture draft (  <http://www.ietf.org/internet-drafts/draft-schulzrinne-sipping-emergency-arch-02.txt> http://www.ietf.org/internet-drafts/draft-schulzrinne-sipping-emergency-arch-02.txt ) authored by this charter and I have a question / suggestion to share. This may have been discussed before, if so I apologize for the repitition
 
We are currently working on emergency services in the context of an enterprise WiFi environment. In such an environment, we figured it could help if a SIP proxy with some knowledge on the proximity of the user (e.g. within the same building, connected to the same LAN) would add information to outgoing emergency calls to assist with locating the user.
 
The proxy could add a header, e.g.: Emergency-Location: lat=1.2345; long=6.789; postal=xxxx; certainty=500m
It should probably also refer to the source of this information, e.g. the URI of the responsible administrator. This location information could be preconfigured in the proxy. 
 
A second issue is that the proxy could be provisioned with the address of the emergency center to contact for emergency calls. In that case the location information would not be needed for call routing
 
I noted that the current draft does not mention these alternatives, it talks mainly about things that can be done at the terminal side. 
 
I would argue that in case of emergency all information that can assist in locating the user can be helpful. So it would be wise to do "as much as possible", i.e. both have the terminal report its location if possible and have the proxy append information too.
 
>From a privacy perspective I understand there could be objections to this approach, i.e. the user's location is given out without the user's consent. I would say that in case the user is making an emergency call, he should know that it implies he will give out his location information. Furthermore, given the nature of emergency situations which by definition are "life and limb threatening" I would say that users generally would take the risk that their location information ends up in the wrong hands, rather than not share it and risk death.
 
Regards,
 
Jeroen van Bemmel, Lucent Technologies Bell Labs
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit