|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Providing location information to IP end-nodes
[ questionably OT for NANOG; subject line changed; killfile at your discretion ] On Tue, May 03, 2005 at 03:08:54PM +0100, [email protected] wrote: > > To expand: the problem is the VoIP client being able to *furnish* an > > approximation of where it is, to permit the selection of the proper > > Public Safety Access Point (or equivalent). > > VoIP clients can't provide such information unless they > KNOW this information in the first place. The only somewhat > reliable way to know this information is for the hardware > device containing the VoIP client to also contain a > GPS system or some equivalent (cell triangulation, querying > cell transmitters, triangulate RTT measurements to known IP addresses) > That is a big problem. Except that the problem can be approached on several scales, more of which seem useful than might be obvious at first glance. I was trying to imply this in some of my earlier postings, with apparently questionable luck; I'll try to be more explicit here. > > If each end-router supplied that data, through *some* easily queriable > > protocol, such clients could retrieve it, and then decide (in some > > fashion) where to send Emergency Services Request calls (or furnish it > > to their carrier, if they have one, for similar purposes). > > And if I am using a laptop communicating with IP over Bluetooth > to a GPRS cellphone in order to establish an IPv6 tunnel to > my colocated server in Germany, then which router should my > VoIP client query? My home DSL router in London? The router > at the colo in Germany? The GPRS cell transmitter? The Japanese > IP gateway router between the cell network and the Internet? Well, first, let us define more closely the problem we're trying to solve. We want to know, for a given physical location of an IP end node device (a PC, laptop, WiFi phone, or some other object which has an IP stack and enough processor and hardware to do VoIP) to which Public Safety Access Point (or the logical equivalent of that outside the US) emergency services ("9-1-1") calls should be sent. A second level of information which might need to be provided is the exact physical location of that end-node device; this level of service is commonly referred to as "E-911", and requires Automatic Location Identification (which is provided by a database dip on normal PSTN lines). The final expansion on this issue is called E-ALI, and concerns making sure the PSAP can identify the physical location of a specific end-station when it lives behind a PBX: *which* phone at MIT is calling for help (MIT, for those who don't know this, is mind-bogglingly big. I mean, you might think it's a long way to the corner chemist...). These problems are listed in order of ascending difficulty to solve well, and the stack may be attacked from either end. There may be regulatory requirements (although I don't believe there currently are) upon commercial players in the Internet Telephony space, but those corporations do not make up the total space, and the problem is worthwhile of solution regardless of the fact that some people may {make money,not lose lawsuits} due to it's solution; this is the approach I've been trying to take in my comments to date. > This is not a simple technical problem. There are human factors > included as well, for instance, should there be a separate > specification for different classes of device so that a device > with a screen greater than 320 x 320 pixels should ask the user > to confirm (or override their address)? A quick knee-jerk fix > will only create new problems and muddy the waters further if > it is presented as the ultimate solution. No, it's actually *three* separate technical problems, some of the solutions to which overlap. To go back, though, to your first question, and my first solution: > And if I am using a laptop communicating with IP over Bluetooth > to a GPRS cellphone in order to establish an IPv6 tunnel to > my colocated server in Germany, then which router should my > VoIP client query? My home DSL router in London? The router > at the colo in Germany? The GPRS cell transmitter? The Japanese > IP gateway router between the cell network and the Internet? I'm trying to solve the "which PSAP" problem. There's a lower level "which protocol" problem involved, but the answer to your question, IMHO, is to provide a mechanism whereby the end device can make *some* sort of query (ethernet broadcast, GPRS ping, whatever it might be -- IP level would be nice, but not necessary), to the nearest network device to it, which device would tell it whom to call, based on some hardware and path identifier attached to the incoming request by the network itself. In the instance you gave, you're after the physical location of the *cellphone*. The Bluetooth layer is clearly unuseful, so we ignore it. The next thing is IP. The phone is acting like either an ethernet adapter, or a cell-modem. In either case, it is (virtually) the laptop's network adapter, and it can (possibly via emulation) either acquire or send IP packets with lower-layer identifiers that will denote which tower the phone was talking to. Some piece of equipment at the carrier can then use that to do a short lookup to a locally maintained tabel (this data does not change all that rapidly, TTBOMK), and return an appropriate reply. This clearly requires bridging levels, but that's not that big a deal, is it? That was a bit of a rough example, as I'm sure you intended, but while other topologies are easier to manage, the point remains that there *is* some way to acquire *some* useful information of about the location of an endpoint, to a granularity good enough for the "which PSAP" problem, which can be designed for (and into) the necessary equipment which provides that topology. Certainly some are more difficult than others; some types of gear replacement-cycle slower than others. But it seemed to *me* that the point of the whole thread either was, or should have been, to figure out the solution before the FCC (who are guaranteed to screw it up) did it for us, no? That end doesn't seem to me to be served by the tenor of and contributions to the thread as I saw it. Cheers, -- jra -- Jay R. Ashworth [email protected] Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
|