Re: [Geopriv] Geo in ENUM

["Brian Rosen" <br at brianrosen.net>]

Generally, NENA's NG9-1-1 architecture would not appreciate more complexity
in location conveyance.  We expect each call to arrive with location in a
SIP Geolocation header (by value or by reference).

We assume that, indeed, for a legacy wireline network connecting to an
NG9-1-1 PSAP, that there will be a database indexed by telephone number
containing location.  That issue is local to the carrier that owns that
legacy system; it must deliver SIP calls with location.

One way to do that is to create a location reference that is of the form
heldref://2025551212 at lis.example.com.  Actually, we're likely to suggest
that at a minimum, the TN be hashed, just because of privacy issues.  That
makes the PSAP do the dereference on the LIS that has the TN-to-location
information. On the other hand, since this is legacy wireline, it may be
that the gateway does the dereference and puts the location by value on the
SIP call.  In that case, the gateway and the LIS have to agree on how the
gateway queries the LIS when all it has is the TN of the caller.  It could
use a reference like the above, or something else.

What we're not going to do is allow the call to arrive without location, and
imply that the TN is used to query an ENUM database to get a location
reference.

So, at least for North American emergency calls, this is a bad idea.

Brian

> -----Original Message-----
> From: geopriv-bounces at ietf.org [mailto:geopriv-bounces at ietf.org] On Behalf
> Of creed at opengeospatial.org
> Sent: Tuesday, August 26, 2008 9:31 AM
> To: Alexander Mayrhofer
> Cc: GEOPRIV
> Subject: Re: [Geopriv] Geo in ENUM
> 
> May be appropriate to bring these use cases up with the Next Generation
> 9-1-1 community. Location is a major design component at multiple levels
> in the i3 architecture and is discussed in a number of NG 9-1-1 Working
> Groups.
> 
> Regards
> 
> Carl
> 
> 
> >> I just saw your document in ENUM proposing a location ENUM
> >> service.  Why
> >> is this necessary in addition to the U-NAPTR mechanism in the LIS
> >> discovery document?  (draft-ietf-geopriv-lis-discovery)  It
> >> seems like
> >> you could just one of the U-NAPTR records as defined there with an
> >> e164.arpa domain to do what you're doing.  Is there something special
> >> about the e164.arpa domain that requires a separate NAPTR mechanism?
> >
> > Hello Richard,
> >
> > i've reviewed the LIS Discovery draft, and it has a very different use
> > case from what i'm trying to achieve with the "Geo" ENUM service.
> >
> > The LIS discovery draft says in the introduction that the URI retrieved
> > can jsut be used for location configuration of the requestor, not as a
> > location by reference URI. That's exactly the contrary of what i'm
> > trying to achieve with the ENUM-Service: The ENUM service is supposed to
> > carry a location-by-reference URI for the device that uses the
> > corresponding phone number, and that URI would not be used for location
> > configuration.
> >
> >
> > This might be useful in a scenario like this:
> >
> > - Carrier A delivers an emergency call to a PSAP using "normal" PSTN
> > transport.
> > - PSAP receives only the number, but can "look up" the
> > location-by-reference URI by means of an ENUM tree (that tree may very
> > likely be private to carriers and PSAPs)
> > - PSAP dereferences location-by-reference URI gathered from ENUM.
> >
> > Another scenario might be a quite "open" scenario, like:
> >
> > - I configure the location-by-reference URI into my public ENUM entry.
> > - everybody can look up that ENUM entry by my phone number
> > - However, i limit location dereferencing to "people i know".
> >
> > Hope that made the difference in use cases (compared to the
> > lis-discovery draft) clear.
> >
> > (BTW, small nit - i've not read the held: URI spec, but you say in
> > section 2 that there "is no default port", while the port component is
> > not included in the example URI in section 4)
> >
> >
> > Alex
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv at ietf.org
> > https://www.ietf.org/mailman/listinfo/geopriv
> >
> 
> 
> _______________________________________________
> Geopriv mailing list
> Geopriv at ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv at ietf.org
https://www.ietf.org/mailman/listinfo/geopriv