Subject: Re: [Sip] SIPit 20 survey summary

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 29 Apr 2007 16:39:11 +0200

Hi Henning, 

http://www.xmpp.org/extensions/xep-0080.html takes an interesting approach by largely ignoring previous work on geolocation. It is just too attractive to create your own flavor of civic and geodetic location information format.  

Interestingly enough there is a full-blown solution for XMPP available as well that builds on the OMA protocols. I have to search for the reference, if someone cares. That one is far more complex than GEOPRIV. 

If you argue for simplicity then you refer to  http://www.xmpp.org/extensions/xep-0080.html. 

If you argue for functionality, different environments and interworking with existing systems then you point to the OMA extension. 

It's so easy. Translated to our work in GEOPRIV this would mean the following: If we want to convince people to use it then we just point them to the easy WLAN or enterprise case with a simple civic or a simple point representation. 

Ciao
Hannes

PS: Last November I was at a conference on mobility protocols. Someone gave a presentation on a new mobility protocol design. The author claimed it was very simple. Indeed, it was simple -- because it just didn't care about security. 

-------- Original-Nachricht --------
Datum: Sun, 29 Apr 2007 17:15:18 +0300
Von: [email-masked]
An: Henning Schulzrinne <[email-masked]>
CC: IETF SIP List <[email-masked]>, [email-masked], [email-masked], Robert Sparks <[email-masked]>
Betreff: Re: [Sip] SIPit 20 survey summary

> Henning Schulzrinne writes:
> 
>  > (I'd prefer even simpler solutions, such as the one  
>  > that XMPP uses, but that's beyond the political correctness limit in  
>  > GEOPRIV.)
> 
> sip and xmpp should use identical format for location information.
> there will be need to gw sip and xmpp and same format would make it
> easy.  so my proposal is that sip ww just refers to
> http://www.xmpp.org/extensions/xep-0080.html for location info.
> 
> -- juha
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 29 Apr 2007 10:56:24 -0400

I mis-spoke. I was actually thinking of a different solution, more  
appropriate to the SIP header model. After all, for geo, two numbers  
(long/lat) in WGS84 datum are all that matters in most circumstances,  
on occasion augmented by a third (some 'measurement accuracy'  
indication).

The XMPP XML model that Juha and you refer to isn't all that much  
simpler than GEOPRIV civic or GML Point, just different, as you note.  
(Whether supporting the multitude of geometric shapes in the pdif-lo  
profile spec is truly required and where is another discussion which  
belongs elsewhere.)

I don't know if by 'security' you refer to the embedded privacy  
policies; in most cases, restrictive default values would do the  
trick for those. Plus, for emergency calls, few PSAPs are going to  
observe 'do not distribute' or 'do not retain' in any event, simply  
because the law in many jurisdictions contradicts those desires.

Henning

On Apr 29, 2007, at 10:39 AM, Hannes Tschofenig wrote:

> Hi Henning,
>
> http://www.xmpp.org/extensions/xep-0080.html takes an interesting  
> approach by largely ignoring previous work on geolocation. It is  
> just too attractive to create your own flavor of civic and geodetic  
> location information format.
>
> Interestingly enough there is a full-blown solution for XMPP  
> available as well that builds on the OMA protocols. I have to  
> search for the reference, if someone cares. That one is far more  
> complex than GEOPRIV.
>
> If you argue for functionality, different environments and  
> interworking with existing systems then you point to the OMA  
> extension.
>
> It's so easy. Translated to our work in GEOPRIV this would mean the  
> following: If we want to convince people to use it then we just  
> point them to the easy WLAN or enterprise case with a simple civic  
> or a simple point representation.
>
> Ciao
> Hannes
>
> PS: Last November I was at a conference on mobility protocols.  
> Someone gave a presentation on a new mobility protocol design. The  
> author claimed it was very simple. Indeed, it was simple -- because  
> it just didn't care about security.
>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 29 Apr 2007 17:11:25 +0200

Hi Henning, 

even for the geodetic location information we never came to a clear conclusion how many shapes we need as mandatory to understand by specific nodes. The PIDF-LO profiles draft is listing a number of shape types and currently they are all marked as "mandatory-to-implement". 
 
Given that some location determination techniques produce certain shape types we can only discuss whether it makes sense to reduce the quality of the data already at the Location Generator before further distributing it. 

That's, btw, something we still have to decide for the emergency services use case (and it will need to be described in Phone BCP). I have sent a few mails to PSAP operators to learn what type of location shapes they process today. 

I don't care whether the information is carried in the header or in the body. If it is supposed to be consumed by the end points only then I would argue that is is just fine to convey it within the body. Hence, we are largely discussing location-based routing applications here. 

Ciao
Hannes

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 29 Apr 2007 17:36:00 +0200

Based on all these discussions (including the proposal to remove emergency 
related text from the draft), I can't help but wonder: is the use case for 
"location conveyance for emergency calls" important and special enough to 
warrant its own solution?

So far, it has been treated as merely a special case of location-based 
routing. But the need for it (yesterday, regulatory driven), the 
security/privacy aspects (ignore them), the required information (single 
location, no shapes e.d.) all seem vastly different from the general case. 
Link that to the observation that a header-based mechanism would be much 
easier to generate (both by UEs and gateways) and parse at routing proxies 
and PSAPs, reducing the chance at errors in situations that may cost lives 
AND speeding up implementation rates, I'd say : separate it out?

Regards,
Jeroen

Henning Schulzrinne wrote:
> Sip-implementors mailing list
> [email-masked]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 29 Apr 2007 18:33:43 +0200

Hi Jeroen, 

> warrant its own solution?

The proposal to move emergency service related content from the SIP Location Conveyance draft and from the PIDF-LO Profile draft to the ECRIT Phone BCP document is a document management type of thing. 

Nothing to worry about. Just to keep things together that belong together. 

A few of us also tend to quickly jump to examples about emergency services when we talk about location-based routing or location-based SIP applications. 

I am not sure what you mean by special. 
 
> routing. But the need for it (yesterday, regulatory driven),

Please note that there are different regulatory requirements for different parts. There are no regulatory requirement for plain VoIP emergency services (without PSAP interworking or systems that claim to be a replacement of the PSTN). Note, however, that I am not a laywer and some folks on this list might know more about the state of regulatory affairs throughout the world. 

 the 
> security/privacy aspects (ignore them),

Well. We have discussed many security aspects in the context of emergency services. There are also privacy related aspects that need to be considered. In fact, we recently had a separate panel discussion at the SDO emergency services workshop to address this topic. See http://www.emergency-services-coordination.info/2007/, the slides for the panel sessions can be found here:  http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/EswPanelParticipants

It just varies from country to country. Japan, for example, has quite challenging privacy rules even for emergency services. 

> the required information (single 

I don't know where you got the message that emergency services works with simpler location shapes. In fact, it would even be necessary to indicate what the different shapes would be used for since there are different consumers in the entire message flow. 

The SDO emergency services workshop I asked the audience about the state-of-the-art location shape types that are being used and I got the impression that fairly complex shapes are already in use today (in the cellular world). I have asked NENA to solicit feedback from the PSAP operator community to learn more about their needs with this respect. A few responses from my own investigations revealed that they would certainly like to have more location information (requiring more complex shapes) for dispatch purposes.  

> AND speeding up implementation rates, I'd say : separate it out?

Would be great if everything would be just that simple. 

Ciao
Hannes

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 29 Apr 2007 21:47:37 +0200

Hi Hannes,

You asked where I saw the complexity of the proposed solution. I see 
complexity in trying to satisfy too many requirements / use cases with a 
single solution. As you illustrate below, the use case for emergency service 
alone is already quite complex by itself.

So, one way to simplify things would be to reduce the number of requirements 
to be satisfied, by focusing on location conveyance for emergency calls only 
(and then perhaps even be selective about the requirements to be included, 
e.g. if the majority of regulators don't have strict privacy requirements 
then don't include those, at least not in the base solution)

Regards,
Jeroen

Hannes Tschofenig wrote:
> Hi Jeroen,
>
>> Based on all these discussions (including the proposal to remove
>> emergency related text from the draft), I can't help but wonder: is
>> the use case for "location conveyance for emergency calls" important
>> and special enough to warrant its own solution?
>
> The proposal to move emergency service related content from the SIP
> Location Conveyance draft and from the PIDF-LO Profile draft to the
> ECRIT Phone BCP document is a document management type of thing.
>
> A few of us also tend to quickly jump to examples about emergency
> services when we talk about location-based routing or location-based
> SIP applications.
>
>
>> So far, it has been treated as merely a special case of
>> location-based routing. But the need for it (yesterday, regulatory
>> driven),
>
> Please note that there are different regulatory requirements for
> different parts. There are no regulatory requirement for plain VoIP
> emergency services (without PSAP interworking or systems that claim
> to be a replacement of the PSTN). Note, however, that I am not a
> laywer and some folks on this list might know more about the state of
> regulatory affairs throughout the world.
>
>
> the
> Well. We have discussed many security aspects in the context of
> emergency services. There are also privacy related aspects that need
> to be considered. In fact, we recently had a separate panel
> discussion at the SDO emergency services workshop to address this
> topic. See http://www.emergency-services-coordination.info/2007/, the
> slides for the panel sessions can be found here:
> http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/EswPanelParticipants
>
> It just varies from country to country. Japan, for example, has quite
> challenging privacy rules even for emergency services.
>
>
> I don't know where you got the message that emergency services works
> with simpler location shapes. In fact, it would even be necessary to
> indicate what the different shapes would be used for since there are
> different consumers in the entire message flow.
>
> The SDO emergency services workshop I asked the audience about the
> state-of-the-art location shape types that are being used and I got
> the impression that fairly complex shapes are already in use today
> (in the cellular world). I have asked NENA to solicit feedback from
> the PSAP operator community to learn more about their needs with this
> respect. A few responses from my own investigations revealed that
> they would certainly like to have more location information
> (requiring more complex shapes) for dispatch purposes.
>
>> Link that to the observation that a header-based mechanism would be
>> much easier to generate (both by UEs and gateways) and parse at
>> routing proxies and PSAPs, reducing the chance at errors in
>> situations that may cost lives AND speeding up implementation rates,
>> I'd say : separate it out?
>
>>> (long/lat) in WGS84 datum are all that matters in most
>>> circumstances, on occasion augmented by a third (some 'measurement
>>> accuracy' indication).
>>>
>>> simpler than GEOPRIV civic or GML Point, just different, as you
>>> note. (Whether supporting the multitude of geometric shapes in the
>>> pdif-lo profile spec is truly required and where is another
>>> discussion which belongs elsewhere.)
>>>

---

From: [email-masked]
Date: Sun, 29 Apr 2007 16:21:32 -0400

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

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Mon, 30 Apr 2007 00:48:09 +0200

(As WG chair)

You have already had one warning from the area director.

Now this is one from the WG chair.

Get this discussion down to specific proposal to the appropriate WG. We are here to discuss chartered drafts. Make specific proposals to the chartered drafts on the table or desist.

If you do not know what those are, then go and read the charters. 

And under no circumstances start including this list in a lot of cross postings to other groups.

Regards

Keith

> -----Original Message-----
> From: Jeroen van Bemmel [mailto:[email-masked]] 
> Sent: Sunday, April 29, 2007 4:36 PM
> To: Henning Schulzrinne; Hannes Tschofenig
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [Sip-implementors] [Sip] SIPit 20 survey summary
> 
> Based on all these discussions (including the proposal to 
> remove emergency related text from the draft), I can't help 
> but wonder: is the use case for "location conveyance for 
> emergency calls" important and special enough to warrant its 
> own solution?
> 
> location-based routing. But the need for it (yesterday, 
> regulatory driven), the security/privacy aspects (ignore 
> them), the required information (sinFrom [email-masked] Sun Apr 29 18:48:27 2007
Content-class: urn:content-classes:message
Subject: RE: [Sip-implementors] [Sip] SIPit 20 survey summary
Date: Mon, 30 Apr 2007 00:48:09 +0200
From: "Drage, Keith \(Keith\)" <[email-masked]>
To: "Jeroen van Bemmel" <[email-masked]>
Cc: [email-masked]

(As WG chair)

You have already had one warning from the area director.

Now this is one from the WG chair.

Get this discussion down to specific proposal to the appropriate WG. We are here to discuss chartered drafts. Make specific proposals to the chartered drafts on the table or desist.

If you do not know what those are, then go and read the charters. 

And under no circumstances start including this list in a lot of cross postings to other groups.

Regards

Keith

> -----Original Message-----
> From: Jeroen van Bemmel [mailto:[email-masked]] 
> Sent: Sunday, April 29, 2007 4:36 PM
> To: Henning Schulzrinne; Hannes Tschofenig
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [Sip-implementors] [Sip] SIPit 20 survey summary
> 
> Based on all these discussions (including the proposal to 
> remove emergency related text from the draft), I can't help 
> but wonder: is the use case for "location conveyance for 
> emergency calls" important and special enough to warrant its 
> own solution?
> 
> location-based routing. But the need for it (yesterday, 
> regulatory driven), the security/privacy aspects (ignore 
> them), the required information (single location, no shapes 
> e.d.) all seem vastly different from the general case. 
> Link that to the observation that a header-based mechanism 
> would be much easier to generate (both by UEs and gateways) 
> and parse at routing proxies and PSAPs, reducing the chance 
> at errors in situations that may cost lives AND speeding up 
> implementation rates, I'd say : separate it out?
> 
> Regards,
> Jeroen
> 
> circumstances, 
> > policies; in most cases, restrictive default values would 
> do the trick 
> > for those. Plus, for emergency calls, few PSAPs are going 
> to observe 
> > 'do not distribute' or 'do not retain' in any event, simply because 
> > the law in many jurisdictions contradicts those desires.
> >
> > Henning
> >
> >> approach by largely ignoring previous work on geolocation. 
> It is just 
> >> too attractive to create your own flavor of civic and geodetic 
> >> available as well that builds on the OMA protocols. I have 
> to search 
> >> for the reference, if someone cares. That one is far more complex 
> >> than GEOPRIV.
> >>
> >> If you argue for simplicity then you refer to  
> http://www.xmpp.org/ 
> >> extensions/xep-0080.html.
> >>
> >> following: If we want to convince people to use it then we 
> just point 
> >> them to the easy WLAN or enterprise case with a simple civic or a 
> >> simple point representation.
> >>
> >> Ciao
> >> Hannes
> >>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Apr 2007 00:22:18 -0400

I ignored my mail over the weekend and a lot of water has flowed over 
the dam.

I agree with Dale on this - what is the big deal here?

It was a *huge* mistake not to require multipart support in 3261. Since 
then what has  been lacking is a strong motivator for implementors to 
support it. If this provides the motivation, then hurrah!

Regarding those suggesting adopting the xmpp solution: how do you 
propose to incorporate it into a sip message? The most obvious answer is 
to incorporate it as a body part - still requiring multipart. XMPP has 
the advantage that already supports the moral equivalent of multipart.

	Paul

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 30 Apr 2007 08:18:15 +0300

> the advantage that already supports the moral equivalent of

multipart is not a big deal to me, but 2027 lines of specification to
read and implement is.

 > job.  (And PSAPs are willing to pay for this.)

you try to say that only PSAPs need to deal with complexity.  that is a
big lie.  there has already been message on this list saying that also
provider and enterprise SIP proxies need to examine and add stuff to the
location data.

to SIP WG management:

you should not disallow discussion on the madness of the resulted
internet draft as whole.  even if GW accepted a charter item, the end
result of the work CAN BE that the requirements led to a too complex
solution that is not implementable in sip proxies in any reasonable
amount of work and that the project needs to be re-charted.

-- juha

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 30 Apr 2007 10:40:21 -0400

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

> From: [email-masked] [mailto:[email-masked]]
> Sent: Sunday, April 29, 2007 4:22 PM
> To: [email-masked]
> Subject: [Sip] geoloc implementation (Was: SIPit 20 survey summary)
>