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