ecrit@ietf.org
[Top] [All Lists]

RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do endpoint

Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do endpoint centric LCP without giving away the store
From: "Brian Rosen"
Date: Fri, 13 Apr 2007 12:04:19 -0400
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

<Prev in Thread] Current Thread [Next in Thread>