[Sipping-emergency] Re: Report on sipemergency call
Henning Schulzrinne <hgs@cs.columbia.edu> Fri, 04 April 2003 05:33 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26494
for <sipping-emergency-archive@odin.ietf.org>;
Fri, 4 Apr 2003 00:33:27 -0500 (EST)
Received: (from mailnull@localhost)
by www1.ietf.org (8.11.6/8.11.6) id h345a4c01753
for sipping-emergency-archive@odin.ietf.org; Fri, 4 Apr 2003 00:36:04 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h345a3K01750
for <sipping-emergency-web-archive@optimus.ietf.org>;
Fri, 4 Apr 2003 00:36:03 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26471
for <sipping-emergency-web-archive@ietf.org>;
Fri, 4 Apr 2003 00:32:55 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h345a2K01741
for <sipping-emergency-web-archive@ietf.org>; Fri, 4 Apr 2003 00:36:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h345ZiK01709
for <sipping-emergency@optimus.ietf.org>; Fri, 4 Apr 2003 00:35:44 -0500
Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26463
for <sipping-emergency@ietf.org>; Fri, 4 Apr 2003 00:32:36 -0500 (EST)
Received: from cs.columbia.edu (dhcp64-134-126-202.sjcc.sjc.wayport.net
[64.134.126.202]) (user=hgs10 mech=PLAIN bits=0)
by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h345Z2JV025281
(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
Fri, 4 Apr 2003 00:35:03 -0500 (EST)
Message-ID: <3E8D18CA.6010207@cs.columbia.edu>
Date: Fri, 04 Apr 2003 00:31:54 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.3b) Gecko/20030210
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: Emergency <sipping-emergency@ietf.org>
References: <004901c2f951$09038cd0$ee036e3f@txdwillis>
<3E8B7114.6040607@cs.columbia.edu> <3E8B9D71.9000406@dynamicsoft.com>
In-Reply-To: <3E8B9D71.9000406@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sipping-emergency] Re: Report on sipemergency call
Sender: sipping-emergency-admin@ietf.org
Errors-To: sipping-emergency-admin@ietf.org
X-BeenThere: sipping-emergency@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping-emergency>,
<mailto:sipping-emergency-request@ietf.org?subject=unsubscribe>
List-Id: <sipping-emergency.ietf.org>
List-Post: <mailto:sipping-emergency@ietf.org>
List-Help: <mailto:sipping-emergency-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping-emergency>,
<mailto:sipping-emergency-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
> This is great information. Just to be sure I understand, Intrado is > doing two separate translations? One for a translation of the civil > address to lat/long, done at the time of provisioning of the civil > address, and the other is the translation of the lat/long into a PSAP > identity, done at call setup time? Its not clear to me why both > translations cannot be done at the same time, at provisioning time. They probably could, but the geocoding (civil-to-geo) is presumably much more stable than the assignment of areas to PSAPs, except maybe after California drifts off into the Pacific. > > Is there a site which maintains a list of providers similar to Intrado? Not that I know of. http://www.nena9-1-1.org/Buyers%20Guide/index.htm is the closest I know of, but it doesn't seem to have that category. See also http://www.nena9-1-1.org/PSAPs/index.htm > > Thanks, > Jonathan R. > > Henning Schulzrinne wrote: > >> Dean, thanks for the summary. >> >> As it happened, I had a breakfast conversation with Vonage an hour >> after the call, discussing their "911" implementation. They are not >> calling it that, since it's only an approximation, not the real thing. >> >> From my discussion, their implementation works as follows, >> implementing one of the stop-gap implementations that I described >> during the talk: >> >> - Customer can enter their location (street address) into a web form. >> >> - Customer gets reminder email once a month, as in "are you still >> living there"? Also, the system detects whether the subnet address of >> the phone has changed, indicating a likely change in physical address >> rather than just a new DHCP lease. >> >> - Address gets geo-coded (via a database maintained by Intrado, but >> other companies offer similar services) into longitude/latitude. >> >> - The outbound proxy directs all SIP requests with 911 to a special >> custom-coded proxy that queries (using an Intrado-proprietary >> XML-over-HTTP protocol) the Intrado jurisdictional database. This >> query returns a 10-digit number of the PSAP handling that part of the >> country. The Vonage fellow confirmed my suspicion that this number is >> often an administrative number, but at least it's the right PSAP. The >> call is then handed to a gateway that dials that number. >> >> - This approach has known limitations: >> . requires an agreement with Intrado (they are set up to serve ILECs >> and CLECs, not necessarily a dynamicsoft-sized business). >> . the calling party number is either the gateway or the caller, >> neither of which is likely to be mappable to anything approaching a >> useful street address. >> . the manual address entry is probably only workable with mobility >> measured in months, not "employee takes phone home after work" or >> "person has multiple devices located in different places" cases. The >> latter case may be solvable, but things start to get a bit more >> complicated from a user perspective. >> >> Apparently, Intrado is pretty much the only vendor with nationwide >> coverage. Other, smaller vendors cover parts of the country. >> >> They are starting to roll this out in the next month or so. This is a >> first step, offering "basic" rather than "enhanced" 911 service. >> >> On average, each US household places about 1 911 call per year, so the >> call volume is pretty modest, from a scaling perspective. >> >> I mentioned the on-going IETF efforts. The Vonage fellow was very >> interested in contributing to the discussion. I told him that I would >> mention this to the group. >> >> Henning _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency
- [Sipping-emergency] Re: Report on sipemergency ca… Gonzalo Camarillo
- [Sipping-emergency] [Fwd: Report on sipemergency … Tom Taylor
- [Sipping-emergency] Re: Report on sipemergency ca… Henning Schulzrinne
- [Sipping-emergency] Re: Report on sipemergency ca… Henning Schulzrinne
- RE: [Sipping-emergency] Re: Report on sipemergenc… Rosen, Brian
- [Sipping-emergency] Re: Report on sipemergency ca… Jonathan Rosenberg
- Re: [Sipping-emergency] [Fwd: Report on sipemerge… James M. Polk
- RE: [Sipping-emergency] [Fwd: Report on sipemerge… Dean Willis