|
|
[I think it would be helpful to align the subject with the topic at
hand, as this is confusing enough already...]
While it is certainly a good idea to provide country information to
the user, as that will also allow retrieval of the dial string using
LoST and possibly a default if-all-else-fails "PSAP", I don't see
this as necessary for checking whether a URL is a PSAP or not. As I
mentioned before, the number of such URLs and the total data volume
is so small that flooding this to all resolvers isn't a big problem.
If we don't want to flood, there are other mechanisms that can be
used to efficiently determine where in the server hierarchy a URL
might be. In particular, Bloom filters are a good way to do this.
Henning
On Apr 16, 2007, at 9:52 AM, Brian Rosen wrote:
Thank you for this reminder.
I don't think we have a real problem. The call is going to be
routed based
on the country of the location you have when you place the call.
That is
going to match the country code that we are using for the
validation. The
PSAP that gets the call may transfer it when the actual fine grained
location is determined, but that is after the call is routed. This
is all
about routing. The entity returning the LbyR, the country code and
the PSAP
URI is the access network. It can keep the information consistent.
Even if the location were to change between the time the endpoint
got the
data from its access network, and the time the VSP validated, the
VSP isn't
getting updated location. It's just validating that the PSAP URI it's
routing for is valid within the country that it's routing to.
If a bad guy could seed bad information in the worldwide LoST
database, then
he could put his URI in there, and get calls. I think we have to
accept
this kind of problem.
We don't actually need the country code, and in fact perhaps we should
consider it a hint. If there is a URI in the database that matches
the
proffered URI, it's valid. The country code just gives us a hint
of where
to look. We might want to recommend that the URIs belong to the
country
where the URI is routed towards (eg psap.london.uk). However, it
works with
any URI.
Brian
-----Original Message-----
From: Raymond Forbes (CV/ETL) [mailto:raymond.forbes@xxxxxxxxxxxx]
Sent: Saturday, April 14, 2007 1:14 PM
To: Brian Rosen; Hannes Tschofenig; Rosen, Brian
Cc: ecrit@xxxxxxxx
Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to
doendpoint centric LCP without giving away the store
In many areas, especially Mobile Networks Country codes are not
reliable.
Geneva is a good case. Most calls originated by Non-Swiss mobiles in
Geneva are actually made on the French networks and so will get the
Country Code +33 of the base station on the surrounding Mountains,
the
French authorities have no jurisdiction to enter Switzerland even
in the
case of Emergencies.
True because of Cross-boarder agreement on this friendly boarder
region
the French PSAPs will forward the calls to Switz PSAPs.
I am sure that what Brian says may be reasonable from fixed
access, but
not from Radio Access, radio has no respect for artificial political
boundaries.
Regards,
Ray Forbes
BU Networks (CV/ETL/BBC/D)
Telephone: +44 (0) 24 7656 3106
Mobile: +44 (0) 771 851 1361
-----Original Message-----
From: Brian Rosen [mailto:br@xxxxxxxxxxxxxx]
Sent: 13 April 2007 17:04
To: 'Hannes Tschofenig'; Rosen, Brian
Cc: geopriv@xxxxxxxx; ecrit@xxxxxxxx
Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to
doendpoint centric LCP without giving away the store
Huh, I didn't get that.
I'd like to eliminate the country code thing, because otherwise we
need
a way to carry it in the SIP Geolocation. However, I don't really
want
the VSP having to ask the ASP/ISP for a dereference of any sort,
and I'd
like to minimize the work of the ASP/ISP. The notion that the ASP/
ISP
has to help the VSP determine if what it has is a valid PSAP URI
strikes
me as a problem.
Now, you may remember WAAAY WAAY back, I strongly suggested that
the geo
form of location always include a country code. I suggested this for
disputed areas. The access network is in a very good position to
tell
you how best to interpret which country actually is the on-the-ground
administrator of the location. If you are connected to an Israeli
access network, and you ask LoST for a PSAP URI, you probably want an
Israeli fire brigade. If you are on a Palestinian access network,
then
you probably want a different answer. So, having country code in
a PIDF
with an otherwise geo location is actually helpful.
The current answer for this is some kind of manual configuration
of the
LoST servers so you get the answer you want. While that can work, I
think something more automatic might work better, and it fixes the
problem.
Brian
-----Original Message-----
From: Hannes Tschofenig [mailto:Hannes.Tschofenig@xxxxxxx]
Sent: Friday, April 13, 2007 11:26 AM
To: Rosen, Brian
Cc: geopriv@xxxxxxxx; ecrit@xxxxxxxx
Subject: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do
endpoint centric LCP without giving away the store
Hi Brian,
I only described a different way of doing the verification without
returning a country code.
I also focus on LbyR only rather than LbyV.
Ciao
Hannes
Rosen, Brian wrote:
Hannes
I am confused by your message.
The problem you describe, where a VSP is trying to validate that
the
Request URI in what is claimed to be an emergency call is a bona
fide PSAP URI seems to be a valid concern. My message described
one
way to do this validation when what the VSP received (in a SIP
Geolocation
header) is an LbyR.
Are you now wondering how you validate when you have an LbyV? I
would think you do the same thing: send the country code (or the
whole
location) and the PSAP URI to LoST and ask if the PSAP URI is
valid.
This does not require any query by the VSP to the ASP/ISP. The VSP
should be able to query its local LoST server and be referred to
the
authoritative server for the location it proffers.
I'd rather not have to have the VSP try to dereference an LbyR, and
if you have an LbyV then you don't even know, necessarily, who the
ASP/ISP is.
Is there something else I'm missing here?
Brian
-----Original Message-----
From: Hannes Tschofenig [mailto:Hannes.Tschofenig@xxxxxxx]
Sent: Friday, April 13, 2007 10:43 AM
To: Rosen, Brian
Cc: geopriv@xxxxxxxx; ecrit@xxxxxxxx
Subject: Re: [Ecrit] Not-so-grand compromise on how to do endpoint
centric
LCP without giving away the store
Hi Brian,
thanks for posting this message.
When the end host is provided with LbyV and triggers the LoST
lookup
and
routes the call via its VSP then the VSP (in some circumstances*)
might
want to verify that the PSAP URI in the message indeed corresponds
to
a
PSAP. The idea that was mentioned a long time ago already was to
let
the
VSP to use the location information for LoST and to compare the
result with the content of the message.
The main goal here is that the VSP does not need to have a
"business"
contract to the ASP/ISP.
Since there is only a location reference that neither the end host
nor the VSP can dereference it is necessary to enhance the
existing
procedures a bit (as Brian mentioned).
I see two ways todo so:
a) Enhance LoST
b) Enhance the dereferencing protocol
In both cases you want to have the LbyR as input and the PSAP URI
(and potentially the service number) as output.
For (a) you would have to address the LoST query to the LoST
server
in the ASP/ISP network and the result would be a nomal LoST
response.
For (b) you would have todo a dereferencing step with an
additional
parameter for "verify only". The response would be similar to the
lookup
by the end host -- just the identity that is being used for the
lookup would be different.
Both approaches are possible and since the VSP has to support both
protocols it does not make a big difference which one to use.
In both cases you would have to compare the result of the lookup
with the content of the message.
Ciao
Hannes
*: It is only necessary when the VSP charges for individual calls
or
for
specific calls (with the given call falling into this category).
Rosen, Brian wrote:
In the Emergency Services SDO Coordination workshop, a familiar
discussion took place: how does location get provided for
emergency calls? The real issue is revenue. Access networks
have
location.
They
may be willing to (or may be regulated to be required to) provide
location for emergency calls. However, they are not willing to
give
it
away for free for other uses. The issue with that is how we
support calling networks that don't have relationships with
access
networks, i.e. the Skype situation. How is location provided
such
that a
Skype
emergency call can be placed, but the access network can restrict
what
else may be done with the location it provides?
We have been wrapped around the axle on this for, dare I say,
years.
So, I think Barbara Stark first described this, and it needs some
work,
but suppose that, as an option, an access network could supply:
1. A reference to location
2. The results of a LoST query on the location value (viz, PSAP
URI
and
local dialstring)
With this, an endpoint could recognize an emergency call and
start
routing it to the right PSAP. The LIS would agree to dereference
for
PSAPs, but could restrict other uses of location.
Hannes points out that we need one more thing: the calling
network
has
to be able to validate that the PSAP URI really is a PSAP URI so
that
charging (emergency calls generally are free) is protected. We
need
a
mechanism for them to do that.
Perhaps we include in the LoST return a country code for a query
with a
geo. We add a new operation to LoST that takes a service, a
country code and a PSAP URI and returns yes/no validation ("Yes,
that URI is
a
valid URI for that service in that country").
What would we need to do to make this happen?
We need extensions to LCPs or some new protocol that returns an
LbyR
and
the LoST results. I wonder if this is just more HELD work.
We need the PSAP URI validation.
Again, this is optional. The access network may well give up an
LbyV.
It may give up an LbyR that it will dereference for the endpoint.
The
access network may have a relationship with the calling network
such that the endpoint need not be involved.
The PSAP URI validation is actually useful without this idea,
especially
when location is an LbyR. Instead of having to have the calling
network
dereference, and then do a LoST query to validate, it can just do
this
PSAP URI validation.
Would this solve our problem? Would access carriers concerned
about revenue issues with "giving away" location to it's
subscribers be willing to provide LbyR dereferenceable by PSAPs
(again remembering
that
the access network are local to the PSAPs) as well as LoST query
services to their endpoints? Would this address the concerns
raised
by
Deutsche Telecom on this issue?
Let me be very clear that I think this is an ugly solution. I
think that everyone will be much better off if endpoints knew
where they
were,
and apps could take advantage of that. I think we'll get there.
I think tying location configuration with the LoST query is a bad
idea. I
think using LbyR for emergency calls is a bad idea.
But I can live with it.
Brian
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Geopriv mailing list
Geopriv@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
|
|