RE: [Sip] geoloc implementation (Was: SIPit 20 survey summary)
"Brian Rosen" <br@brianrosen.net> Mon, 30 April 2007 14:40 UTC
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiX3D-0008Gs-JF; Mon, 30 Apr 2007 10:40:27 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HiX3B-0008Gm-QT for sip-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 10:40:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiX3B-0008Ge-Gf for sip@ietf.org; Mon, 30 Apr 2007 10:40:25 -0400
Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiX3A-0000zn-T5 for sip@ietf.org; Mon, 30 Apr 2007 10:40:25 -0400
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from <br@brianrosen.net>) id 1HiX23-0006rR-JJ for sip@ietf.org; Mon, 30 Apr 2007 09:39:16 -0500
From: Brian Rosen <br@brianrosen.net>
To: sip@ietf.org
Subject: RE: [Sip] geoloc implementation (Was: SIPit 20 survey summary)
Date: Mon, 30 Apr 2007 10:40:21 -0400
Message-ID: <0bf201c78b35$7cf83f80$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <200704292021.l3TKLWQJ006886@dragon.ariadne.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Thread-Index: AceKm91BQrye8SYrQzaxfaThuuLvfgAjA6Gg
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Source:
X-Source-Args:
X-Source-Dir:
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bf422c85703d3d847fb014987125ac48
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org
I did start this mess, and while I have some regrets, the sooner we get this over with the better. I'm going to take one shot at explaining a couple of years of development in geopriv and ecrit. I will be happy to correspond with anyone off list on these matters, but generally, if you want to change the direction of ecrit and geopriv, go there and work. Okay. So the first thing we realized is that the access network (which for most Internet connected devices is the broadband carrier) usually knows where you are, and the calling network (the sip network) may not. Nomadic operation works on most VoIP and related networks, and when the calling network and the access network are not the same network, it's the access network that knows where you are and not the calling network. In some cases, there are no relationships between the access network and the calling network. Example are Vonage or Sunrocket or even jabber.org. It's clearly not going to work to force relationships between access networks and calling networks. Suppose you are from Sierra Leone, you use Sierra Leone VoIP Services Pty, and you are currently at a Starbucks in Chicago. Is it reasonable, feasible, or even possible for Sierra Leone VoIP to have a relationship with the DSL supplier that is actually supplying a broadband connection, or T-Mobile, who is supplying the WiFi service in Chicago? So, we have pretty much eliminated the notion of the calling network supplying location. It is actually possible: a proxy CAN insert location by reference, but only if it knows FOR CERTAIN, where the endpoint is (specifically, that it knows which access network the UA is connected to and it has a relationship with that access network, and has some kind of identifier which will always yield the right location). An example of such a circumstance is an IMS wireless network. An example that doesn't work is an IMS wired network with a nomadic user. An example that is really hard to deal with is an Ethernet VoIP phone connected to an IMS packet network through a PC card in a router. Of course, if the device has a self contained measurement mechanism inside, and it works where the phone is, great, you don't need an access network. Since GPS doesn't usually work indoors (yet, they are working on it), your choices are difficult for self measuring. The measurement mechanism really has to work wherever the phone could be. That's a tall order. We've made compromises on mobile (cellular) networks, but they do cause considerable difficulty in getting help when the caller is not in a location where the measurement methodology works reliably. Even if it's the access network that knows where you are, it's the calling network that has to get the call to the PSAP (or at least handle it, see below). If we can't assume a relationship between the access network and the calling network, what do we do? The answer is we make use of the observation that the UA is a client of BOTH the access network AND the calling network. The access network gives the UA, which is its subscriber, its own location. The UA uses one of several "Location Configuration Protocols" to get location from the access network. The puts it in the sip signaling (with -conveyance) on an emergency call. The UA is a subscriber to the calling network. There are no other entities that have a relationship with BOTH the access network and the calling network. In this discussion, a large enterprise is an access network. It may have a calling network, but users on the access network may use a service like AIM, which will be able to place an emergency IM session. In smaller enterprises, the underlying broadband carrier is the access network. Side step to formats. There is no easy answer. What looks simple isn't. You can't really just hand over a lat/lon in every circumstance, even though that might work in a few circumstances. There are two big areas to be concerned with. One is civic location. About 2/3 of the endpoints will be civic located (street address). Coming up with a format that works across the Internet is challenging. We spent a lot of time on it, and the result is in geopriv documents. You can't eliminate civic, and you can't short circuit the requirements to work across the Internet. Then there is the problem of measurement errors in geo. The required location accuracy for geo in emergency calls is several cm. This tells you which side of the "demising" wall you are on separating two apartments. When they break down the door to come to your aid, you would like them to break down the right door. Few measurement methods achieve that accuracy. When they don't, we need to understand what the measurement represents. Those that have worked on this problem for some time use two variables: uncertainty and confidence. Uncertainty is usually some kind of 2 or 3 dimensional shape, where you are equally likely to be at any point within the shape. Confidence is usually a percentage and it's the likelihood that the uncertainty holds. When you send a geo, unless it's really, really accurate, you need to send uncertainty and confidence, or have some other way to represent what the measurement means. Also, we want 3D location (remember the "which apartment" problem. And, by the way, don't ever convert (from civic to geo or geo to civic). Conversion requires a database. The database has some error in it. The PSAP often has to convert itself (typically from geo to civic), and it has a database which has some error. If you convert twice, with two different databases, you can get a very significant error, so we advise never convert. We then have the issue of who routes. We have designed a new protocol (LoST) that takes a location and a service (like single number emergency call) and returns a URI to route to. In the development of this scheme, it was important to us that the same mechanism that routes calls to PSAPs be useful to route calls to the nearest pizza parlor. We wanted the access networks to have every possible reason to deploy the location infrastructure, and having the same mechanisms (the way location is obtained, and the way location based routing is done) was considered important to promote the availability of the mechanisms. The servers for emergency call might very well be different from the servers for pizza, but the location is the same, obtained the same way from the same entity, the routing mechanism is the same, and the method for applying it (and sending location for a delivery/response) is the same. The ecrit documents recommend that the endpoint do the routing, and that it compute a route, and cache it, before it needs it. When the emergency call occurs, we recommend the route be re-computed if possible. This guards against the possibility that the route server may not be accessible when you need it (for example, in a disaster). It is possible for the calling network to route. It may need to for really dumb devices, but it's actually pretty hard to make that work. Again, nomadic operation is a challenge. You need to know the "local" dialstring to determine what is an emergency call. Local is local to the endpoint at the time it makes the call. The LoST service supplies the dialstring for a location, but typically, the calling network doesn't have the location of the endpoint unless the endpoint knows it's an emergency call and puts the location on the call. Also, the endpoint is local to the database (the database is distributed, but the part that is relevant for an emergency call is typically local to the environment the call comes from. We wanted to increase the probability that we would get a good route, and that favors having the endpoint route. The calling network may have to route in some circumstances, and to detect fraud (claiming an emergency call when it is not) it has to validate that the URI the UA claims it got from LoST actually is a bona fide emergency call URI. Got it? 1. You get location, in civic or geo forms, from the access network, unless the device self measures. 2. The device pre-computes a route using LoST and caches it. 3. The device recognizes an emergency call (LoST gives it the dialstring to look for) 4. The device acquires location and recomputes the route, if possible 5. The device routes the call to the URI it obtains, along with its location (using -conveyance). We have a mechanism to mark emergency calls (service urn). 6. The calling network CAN, if it really knows what is happening, put location on the call. It CAN, if it really knows what is happening, look for the emergency dialstring(s). It CAN, if it has location and knows its an emergency call, route it. I can also verify that the URI it's routing towards for an emergency call is valid. Again, if you have questions, email me privately, or come over and join the fun in ecrit and geopriv Brian > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > Sent: Sunday, April 29, 2007 4:22 PM > To: sip@ietf.org > Subject: [Sip] geoloc implementation (Was: SIPit 20 survey summary) > > Is this really as much of a problem as people are making out? > > OK, it's *possible* that redesigning the geolocation specification > would be a good thing. But given the amount of work that has already > been done on it, and the complexity of the requirements, it would take > me a month of work straight to verify that I truly had a Better Idea. > So I am not about to suggest that. > > In regard to the complexity of the solution, a UA that provides geoloc > data (once it had some) would seem to have a fairly simple task, > formatting the data into a preselected body. Even multipart-MIME XML > is simple if one knows in advance the skeleton. > > The PSAPs, of course, are stuck parsing and interpreting all possible > formats. That's a hard job, but on the other hand, PSAPs are built by > a small number of vendors who will be highly motivated to do a good > job. (And PSAPs are willing to pay for this.) > > The difficulty in practice is "How does the UA get its geloc data?" > (Or how does an intermediate agent get the data for the UA?) This > does not become simpler if we change the format of geoloc data. > > I expect that the major barrier to implementing geoloc support has > been the instability of the geoloc specification, combined with the > fact that SIP is not yet entering the mainstream where emergency > services support is required by regulation. > > Dale > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
- Re: [Sip] SIPit 20 survey summary Frank W. Miller
- [Sip] SIPit 20 survey summary Robert Sparks
- [Sip] Which sip.instance to use (GRUU and Outboun… Jerry Yin
- Re: [Sip] SIPit 20 survey summary Jeroen van Bemmel
- Re: [Sip] SIPit 20 survey summary Juha Heinanen
- RE: [Sip] SIPit 20 survey summary Brian Rosen
- Re: [Sip-implementors] [Sip] SIPit 20 survey summ… Mark R. Lindsey
- Re: [Sip-implementors] [Sip] SIPit 20 survey summ… Juha Heinanen
- Re: [Sip] SIPit 20 survey summary Cullen Jennings
- Re: [Sip] SIPit 20 survey summary Frank W. Miller
- Re: [Sip] SIPit 20 survey summary Cullen Jennings
- Re: [Sip-implementors] [Sip] SIPit 20 survey summ… Mark R. Lindsey
- Re: [Sip-implementors] [Sip] SIPit 20 survey summ… Juha Heinanen
- Re: [Sip] SIPit 20 survey summary Hannes Tschofenig
- Re: [Sip] SIPit 20 survey summary Jeroen van Bemmel
- Re: [Sip] SIPit 20 survey summary Henning Schulzrinne
- Re: [Sip] SIPit 20 survey summary Juha Heinanen
- Re: [Sip] SIPit 20 survey summary Hannes Tschofenig
- Re: [Sip] SIPit 20 survey summary Hannes Tschofenig
- Re: [Sip-implementors] [Sip] SIPit 20 survey summ… Scott Lawrence
- Re: [Sip] SIPit 20 survey summary Frank W. Miller
- Re: [Sip] SIPit 20 survey summary Juha Heinanen
- Re: [Sip] SIPit 20 survey summary Henning Schulzrinne
- Re: [Sip] SIPit 20 survey summary Henning Schulzrinne
- Re: [Sip] SIPit 20 survey summary Hannes Tschofenig
- Re: [Sip] SIPit 20 survey summary Hannes Tschofenig
- Re: [Sip] SIPit 20 survey summary Hannes Tschofenig
- Re: [Sip-implementors] [Sip] SIPit 20 survey summ… Jeroen van Bemmel
- Re: [Sip-implementors] [Sip] SIPit 20 survey summ… Hannes Tschofenig
- Re: [Sip-implementors] [Sip] SIPit 20 survey summ… Jeroen van Bemmel
- [Sip] geoloc implementation (Was: SIPit 20 survey… Dale.Worley
- Re: [Sip] geoloc implementation (Was: SIPit 20 su… Paul Kyzivat
- [Sip] Support for Multipart/MIME Cullen Jennings
- Re: [Sip] geoloc implementation (Was: SIPit 20 su… Juha Heinanen
- RE: [Sip] geoloc implementation (Was: SIPit 20 su… Brian Rosen
- Re: [Sip] Support for Multipart/MIME Dale.Worley
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- Re: [Sip] Support for Multipart/MIME Frank W. Miller
- RE: [Sip] Support for Multipart/MIME Francois Audet
- RE: [Sip] Support for Multipart/MIME James M. Polk
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- RE: [Sip] Support for Multipart/MIME Dan Wing
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- RE: [Sip] Support for Multipart/MIME James M. Polk
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME Ted Hardie
- Re: [Sip] Support for Multipart/MIME Dean Willis
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME Ted Hardie
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- RE: [Sip] Support for Multipart/MIME Dan Wing
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- Re: [Sip] Support for Multipart/MIME Dean Willis
- RE: [Sip] Support for Multipart/MIME Dan Wing
- Re: [Sip] Support for Multipart/MIME Ted Hardie
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- RE: [Sip] Support for Multipart/MIME Dan Wing
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- RE: [Sip] Support for Multipart/MIME Francois Audet
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- RE: [Sip] Support for Multipart/MIME Dan Wing
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- RE: [Sip] Support for Multipart/MIME Francois Audet
- RE: [Sip] Support for Multipart/MIME Francois Audet
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME Francois Audet
- Re: [Sip] Support for Multipart/MIME Cullen Jennings
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- Re: [Sip-implementors] [Sip] SIPit 20 survey summ… Klaus Darilion
- Re: [Sip-implementors] [Sip] SIPit 20 survey summ… Hannes Tschofenig
- Re: [Sip-implementors] [Sip] SIPit 20 survey summ… Dale.Worley
- RE: [Sip] Support for Multipart/MIME Francois Audet
- Re: [Sip] Support for Multipart/MIME Gonzalo Camarillo
- Re: [Sip] Support for Multipart/MIME Gonzalo Camarillo
- Re: [Sip] Support for Multipart/MIME Gonzalo Camarillo
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- RE: [Sip] Support for Multipart/MIME Francois Audet
- RE: [Sip] Support for Multipart/MIME Francois Audet
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- Re: [Sip] Support for Multipart/MIME Gonzalo Camarillo
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- RE: [Sip] Support for Multipart/MIME Francois Audet
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME Francois Audet
- RE: [Sip] Support for Multipart/MIME Francois Audet
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME Francois Audet
- RE: [Sip] Support for Multipart/MIME Elwell, John
- Re: [Sip] Support for Multipart/MIME Gonzalo Camarillo
- Re: [Sip] Support for Multipart/MIME Gonzalo Camarillo
- Re: [Sip] Support for Multipart/MIME Gonzalo Camarillo
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- RE: [Sip] Support for Multipart/MIME - order of b… Christer Holmberg (JO/LMF)
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- RE: [Sip] Support for Multipart/MIME - order of b… Francois Audet
- RE: [Sip] Support for Multipart/MIME - order of b… Christer Holmberg (JO/LMF)
- Re: [Sip] Support for Multipart/MIME Gonzalo Camarillo
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- RE: [Sip] Support for Multipart/MIME - S/MIME Christer Holmberg (JO/LMF)
- RE: [Sip] Support for Multipart/MIME - support of… Christer Holmberg (JO/LMF)
- Re: [Sip] Support for Multipart/MIME - support of… Gonzalo Camarillo
- RE: [Sip] Support for Multipart/MIME - support of… Christer Holmberg (JO/LMF)
- Re: [Sip] Support for Multipart/MIME - support of… Paul Kyzivat
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME - when is it… Christer Holmberg (JO/LMF)
- RE: [Sip] Support for Multipart/MIME - support of… Christer Holmberg (JO/LMF)
- Re: [Sip] Support for Multipart/MIME Gonzalo Camarillo
- RE: [Sip] Support for Multipart/MIME Dan Wing
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- Re: [Sip] Support for Multipart/MIME Cullen Jennings