That said, if the LIS has to get this information anyway and then do the
polygon-in-polygon check, it may as well return the resulting
destination URIs as well and do away with having to have 2 protocols
supported by the end-point when one will do.
At what point do we stop?
Cheers
James
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
Behalf
> Of Richard Barnes
> Sent: Wednesday, 3 June 2009 1:09 PM
> To: Dawson, Martin
> Cc: geopriv@ietf.org; Rosen, Brian
> Subject: Re: [Geopriv] HELD ResponseTime parameter withvalue
> emergencyRouting
>
> Martin,
>
> It actually isn't that onerous for the LIS to check whether a given
> location is 'good enough for routing'. Basically, it involves a lot
of
> LoST queries to collect service boundaries for the relevant areas,
some
> off-line computations, then only a polygon-in-polygon check at query
> time. We describe an algorithm in draft-barnes-ecrit-rough-loc:
> <http://tools.ietf.org/html/draft-barnes-ecrit-rough-loc#section-3>
> Picking a service region (as I think your quote from Brian suggests a
> LIS would do) is then just a matter of intersecting the two polygons.
>
> That said, it seems to me that whether the LIS applies such an
algorithm
> is still a matter of local policy, with no protocol changes necessary.
>
> --Richard
>
>
>
>
>
>
>
> Dawson, Martin wrote:
> > The NENA discussion hinged around the question of whether the
routing
> > service (LoST) should apply weighted routing to the location offered
by
> > the device - and let's assume the relevant use case is that the
network
> > LIS provided this location in, say, a cellular network. Proponents
of
> > weighted routing pointed out that the uncertainty around a cell may
> > overlap two or more routing boundaries and that the optimal approach
is
> > to determine which routing area the largest proportion (weight) of
the
> > uncertainy falls into.
> >
> > Those opposed to this approach said that, in fact, the location
should
> > just be provided as point - ignoring the fact that uncertainty is
> > associated with it. And this proposal was made on the basis that
*the
> > LIS should ensure that the point provided falls into the correct
> > (optimal?) routing area before providing it to the client*
> >
> > This sentiment is reflected in the following from Brian's post on
this
> > thread:
> >
> >> I claim that it is perfectly reasonable to expect the LIS to
construct
> > a
> >> PIDF suitable for the purpose of emergency routing when it
encounters
> > the
> >> emergencyRouting value in responseTime
> >
> > The real kicker in this is that the LIS *has to perform actual
routing
> > analysis before providing the location*. The inevitable consequence
of
> > this is that the LIS has to have some sort of access to the routing
> > boundary information in order to do this - don't forget a cellular
> > location can't be stored in the LIS before hand; it's generated
> > dynamically. So now, the LoST data, including multiple adjacent
boundary
> > information, also has to live in the LIS or be otherwise accessible
to
> > it.
> >
> > Now - if this is a reasonable expectation, and I'm not saying it
isn't,
> > then it must raise the question of why use LoST at all to do the
PSAP
> > URI lookup, why not have the LIS deliver it directly since it's
already
> > had to perform routing? I don't buy an interoperability argument
against
> > this. An optional extension in the HELD response could contain the
PSAP
> > URI. Any device not supporting it can fall back to looking for LoST.
It
> > means that broadband providers could start providing ECRIT emergency
> > call routing without the public LoST deployment/management problem
> > having to be solved. Public network operators already do this
routing
> > analysis for the PSTN including cellular; it's not a new ask.
> >
> > Cheers,
> > Martin
> >
> >
> > -----Original Message-----
> > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> > Behalf Of Rosen, Brian
> > Sent: Wednesday, 3 June 2009 10:42 AM
> > To: geopriv@ietf.org
> > Subject: [Geopriv] HELD ResponseTime parameter with value
> > emergencyRouting
> >
> > In NENA, there is a discussion on the best form (shape) to send to
the
> > LoST server when the shape is a cell sector. The discussion itself
is
> > pretty specific to NENA, although it involves the fact that it might
be
> > necessary for the LIS to choose the shape of the response for
emergency
> > routing that might be different than it would return for other
purposes.
> >
> >
> > Martin Thompson is worried about something that I seek advice on.
> >
> > The wording choice for ResponseTime in HELD is:
> > 6.1. "responseTime" Parameter
> >
> > The "responseTime" attribute MAY be included in a location
request
> > message. The "responseTime" attribute includes a time value
> > indicating to the LIS how long the Device is prepared to wait for
a
> > response or a purpose for which the Device needs the location.
> >
> > In the case of emergency services, the purpose of obtaining the
LI
> > could be either for routing a call to the appropriate PSAP or
> > indicating the location to which responders should be dispatched.
> > The values defined for the purpose, "emergencyRouting" and
> > "emergencyDispatch", will likely be governed by jurisdictional
> > policies, and should be configurable on the LIS.
> >
> > Please note the construction of the last sentence of the first
paragraph
> > about "purpose".
> >
> > I claim that it is perfectly reasonable to expect the LIS to
construct a
> > PIDF suitable for the purpose of emergency routing when it
encounters
> > the emergencyRouting value in responseTime, and the fact that it is
in
> > the "responseTime" parameter doesn't limit the LIS from sending an
> > appropriate PIDF content as well as within an appropriate time
limit.
> > The LIS knows the purpose, and can reasonably be expected to respond
> > appropriately in both time and content. Otherwise, we would need
> > another parameter to ask for the right content, which is silly.
> >
> > I have been okay with the current wording because I believed that
the
> > LIS could use the emergencyRouting (or emergencyDispatch for that
> > matter) as an all purpose "purpose" (as it were) and wasn't hung up
on
> > the fact that it's in the responseTime parameter.
> >
> > Am I wrong?
> >
> > Brian
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www.ietf.org/mailman/listinfo/geopriv
> >
> >
------------------------------------------------------------------------
> ------------------------
> > This message is for the designated recipient only and may
> > contain privileged, proprietary, or otherwise private information.
> > If you have received it in error, please notify the sender
> > immediately and delete the original. Any unauthorized use of
> > this email is prohibited.
> >
------------------------------------------------------------------------
> ------------------------
> > [mf2]
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www.ietf.org/mailman/listinfo/geopriv
> >
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
