On Apr 24, 2007, at 10:12 PM, Andrew Newton wrote:
On Apr 24, 2007, at 9:30 PM, Henning Schulzrinne wrote:
(2) Transformation in LIS: The carrier that wants to hide a
location creates a convex location region that has no holes and
includes the location of the UA. A very simple way to do this is
to return a triangle (square, circle, ...) that includes the
caller's location (not in the center) and whose centroid falls
into the PSAP service area. This has to be done only once (unless
the PSAP boundary changes), so the computational burden is trivial.
Well, that's certainly a creative approach, and complex. And it
screws with the caching and periodic requery at the end point. The
created shape must fall entirely within service boundary. If any
part of it overlaps the service
Not really; caching works just as before. The created shape does
*not* have to fall completely within the service boundary, given the
centroid computation that determines matching. As per the previous
discussion, any non-point shape will need to be transformed to a
point (centroid) by the LoST server.
boundary, then there is the potential for a misrouted call. If the
created shape falls within the service boundary, it will be less
than the area of the service boundary and cause needless requerys
by the endpoints, which will believe they may have crossed from one
service boundary to another when, in fact, they haven't.
That seems like a lot of extra burden on the system, when we could
just add some meta-data to the service boundary and allow LoST
servers to do exact matches.
This would not be the service boundary, but it would have to be the
<location-info> element, so it would have to be a PIDF-LO extension,
which seems rather strange.
Ecrit mailing list