[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Ecrit] Emergency calling without endpoint/VSP location support
In the ECRIT meeting at IETF 73, Hannes proposed forming a Design Team
on what I'll call "IP-to-location" mapping. He correctly observed that
several planned architectures for VoIP emergency calling involve PSAPs
or VSPs doing something like the following process in order to get
location information for endpoints:
1. Gets an emergency call from a caller at a given IP address
2. Determine the ISP responsible for that IP address
3. Fetch location from the ISP
The solution above is *obviously* a hack, because step 2 involves a lot
of uncertainty on any reasonable scale. However, the problem it
addresses is real, especially in the short term: How should a VSP route
a call if endpoints don't support location? (Likewise, how should a
PSAP get location if VSPs and endpoints don't support location?)
In order to address this problem, some sort of IP-to-location mapping
will be required. As Jon pointed out in the meeting, this will not be
solvable for the general Internet, for the same reason that we've always
assumed that ISPs and VSPs are decoupled. However, I think this mapping
can be enabled in certain circumstances, if the parties involved (ISPs,
VSPs/PSAPs) have the right relationships and implement the right things.
(Purposely vague, because I don't have a solution!)
So I'd like to suggest that ECRIT think about a document of the
following form:
1. Problem statement: Need to route emergency calls even when endpoints
don't support location (get endpoint location at the PSAP when endpoints
and VSPs don't provide it)
2. How and when this problem can be solved (and why it doesn't scale up
to Internet)
3. How to transition from this system to the ECRIT architecture
I don't know if I'm the best person to write such a document, but IFrom ecrit-bounces at ietf.org Thu Nov 20 17:20:32 2008
Return-Path: <ecrit-bounces at ietf.org>
X-Original-To: ecrit-web-archive at megatron.ietf.org
Delivered-To: ietfarch-ecrit-web-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 9C7A03A6A59;
Thu, 20 Nov 2008 17:20:32 -0800 (PST)
X-Original-To: ecrit at core3.amsl.com
Delivered-To: ecrit at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id B3ECC28C100
for <ecrit at core3.amsl.com>; Thu, 20 Nov 2008 17:20:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5
tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id ZIdZgI8ybLYz for <ecrit at core3.amsl.com>;
Thu, 20 Nov 2008 17:20:31 -0800 (PST)
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80])
by core3.amsl.com (Postfix) with ESMTP id 09A623A69D8
for <ecrit at ietf.org>; Thu, 20 Nov 2008 17:20:31 -0800 (PST)
Received: from [128.89.255.114] (helo=Richard-Barnes-Laptop.local)
by mx11.bbn.com with esmtp (Exim 4.60)
(envelope-from <rbarnes at bbn.com>) id 1L3Kh6-00062D-DN
for ecrit at ietf.org; Thu, 20 Nov 2008 20:20:24 -0500
Message-ID: <49260CD7.4020005 at bbn.com>
Date: Thu, 20 Nov 2008 19:20:23 -0600
From: Richard Barnes <rbarnes at bbn.com>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: ECRIT <ecrit at ietf.org>
Subject: [Ecrit] Emergency calling without endpoint/VSP location support
X-BeenThere: ecrit at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>,
<mailto:ecrit-request at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:ecrit at ietf.org>
List-Help: <mailto:ecrit-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>,
<mailto:ecrit-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ecrit-bounces at ietf.org
Errors-To: ecrit-bounces at ietf.org
In the ECRIT meeting at IETF 73, Hannes proposed forming a Design Team
on what I'll call "IP-to-location" mapping. He correctly observed that
several planned architectures for VoIP emergency calling involve PSAPs
or VSPs doing something like the following process in order to get
location information for endpoints:
1. Gets an emergency call from a caller at a given IP address
2. Determine the ISP responsible for that IP address
3. Fetch location from the ISP
The solution above is *obviously* a hack, because step 2 involves a lot
of uncertainty on any reasonable scale. However, the problem it
addresses is real, especially in the short term: How should a VSP route
a call if endpoints don't support location? (Likewise, how should a
PSAP get location if VSPs and endpoints don't support location?)
In order to address this problem, some sort of IP-to-location mapping
will be required. As Jon pointed out in the meeting, this will not be
solvable for the general Internet, for the same reason that we've always
assumed that ISPs and VSPs are decoupled. However, I think this mapping
can be enabled in certain circumstances, if the parties involved (ISPs,
VSPs/PSAPs) have the right relationships and implement the right things.
(Purposely vague, because I don't have a solution!)
So I'd like to suggest that ECRIT think about a document of the
following form:
1. Problem statement: Need to route emergency calls even when endpoints
don't support location (get endpoint location at the PSAP when endpoints
and VSPs don't provide it)
2. How and when this problem can be solved (and why it doesn't scale up
to Internet)
3. How to transition from this system to the ECRIT architecture
I don't know if I'm the best person to write such a documen'd be
glad to help out.
--Richard
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
t, but I'd be
glad to help out.
--Richard
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit