Subject: [Ecrit] Emergency calling without endpoint/VSP location support

From: Richard Barnes <[email-masked]>
Date: Thu, 20 Nov 2008 19:20:23 -0600

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 I'd be 
glad to help out.

--Richard
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Laura Liess" <[email-masked]>
Date: Fri, 21 Nov 2008 02:29:47 +0100

I fully support Richard's proposal. This is a real problem and must be 
solved.

Laura

----- Original Message ----- 
From: "Richard Barnes" <[email-masked]>
To: "ECRIT" <[email-masked]>
Sent: Friday, November 21, 2008 2:20 AM
Subject: [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:
> 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, 
> So I'd like to suggest that ECRIT think about a document of the following 
> form:
> 2. How and when this problem can be solved (and why it doesn't scale up to 
> Internet)

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 20 Nov 2008 19:38:41 -0600

I believe that the tie between PSAP and ISP might be possible - both require a physical presence.  Under the conditions where the VSP also has a tie, this could work.

I've seen a number of proposals and am quite interested in working on a solution.  

Cheers,
Martin

(My gut feel is that this might cross over into the GEOPRIV work relating to LIS discovery, but we can work that out as we go.)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Richard Barnes
> Sent: Thursday, 20 November 2008 7:20 PM
> To: ECRIT

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: Ted Hardie <[email-masked]>
Date: Fri, 21 Nov 2008 13:57:09 -0600

At 5:20 PM -0800 11/20/08, Richard Barnes wrote:
>will be required. 

Is there a reason this requires an IETF standard, though?  There are
existing solutions for this, many of the commercial.  Without standardized access
to the *data* mapping IP to Location, a protocol developed here looks
to be a complete no-op, as it runs parallel to the providers' own
access protocol into the proprietary database.

Is there anyone suggesting that the folks actually doing this work
want to have access to multiple data sources in some standardized
way?  Maybe more to the point, is there anybody claiming that the
people who develop databases in this arena are willing to support this?

I know I was pretty blunt at the mic about this, and I don't want to
appear rude.  But I really don't see the need for this to be an ECRIT/IETF
effort, even if these interim systems are being deployed.
			regards,
				Ted
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: Marc Linsner <[email-masked]>
Date: Fri, 21 Nov 2008 15:27:58 -0500

I agree with Ted on this, why is this an IETF/ECRIT problem?

The IETF has offered a solution, the sooner it's deployed the faster this
problem goes away.

Let's concentrate on phonebcp, framework, and location conveyance.

-Marc-