|
|
James,
>
> I am not so sure that this anymore the case than it would be
> with a location value is it?
No, if the client has LbyV, the client can do the LoST lookup at call time.
>
> If the device is fixed, then the likelihood of change in low,
> but the PSAP route could be tagged with an expiry the same as
> a literal location can. So I think this is the same problem.
You are suggesting the host go back to the access network when setting up an
emergency call?
I wonder if a course location (enough to route properly) with LbyR embedded
in the LbyV would be better.
The access provider can take the fine grain location, perform a LoST lookup,
give the client only the tuples that LoST returned in the service boundary.
The client can then perform a LoST lookup anytime with that set of tuples.
If the client is fixed no need to contact the access network at emergency
call time.
I worry about too many dependencies at call time.
-Marc-
>
> If the device is mobile then yes this does require an extra
> dip prior to the mobile sending the initial invite, but the
> proxy doesn't have to the LoST dip on the way, so the net
> result may be neutral depending on how the proxy does URI
> checking etc.
>
> I am not suggesting that this solution is optimal either, but
> like Brian and I can live with it.
>
> Cheers
> James
>
> > -----Original Message-----
> > From: Marc Linsner [mailto:mlinsner@xxxxxxxxx]
> > Sent: Sunday, 15 April 2007 1:32 PM
> > To: 'Brian Rosen'
> > Cc: ecrit@xxxxxxxx
> > Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise
> on how to
> > doendpointcentric LCPwithout giving away the store
> >
> > Brian,
> >
> > You also realize that an emergency call is going to be routed using
> > 'stale'
> > data. We've always stated that routing at call time is
> optimal. You
> are
> > prepared to give that up?
> >
> > -Marc-
> >
> > > -----Original Message-----
> > > From: Brian Rosen [mailto:br@xxxxxxxxxxxxxx]
> > > Sent: Friday, April 13, 2007 3:11 PM
> > > To: 'Marc Linsner'; Rosen, Brian; geopriv@xxxxxxxx
> > > Cc: ecrit@xxxxxxxx
> > > Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand
> compromise on how to
> > > do endpointcentric LCPwithout giving away the store
> > >
> > > I think that is part of the tradeoff an access network makes.
> > > If its restricting access to location, and location is needed to
> > > route, then it has to assume the liability for misroute,
> since it's
> > > providing the route in lieu of providing location for the VSP to
> > > route.
> > >
> > > If it doesn't want to assume that liability, then it has to give
> > > location to someone who does the route, and we're back
> around that
> > > axle again.
> > >
> > > So, I think it's reasonable that the access network deal with
> > > misroutes in this case.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Marc Linsner [mailto:mlinsner@xxxxxxxxx]
> > > > Sent: Friday, April 13, 2007 1:23 PM
> > > > To: 'Rosen, Brian'; geopriv@xxxxxxxx
> > > > Cc: ecrit@xxxxxxxx
> > > > Subject: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to
> do
> > > > endpointcentric LCPwithout giving away the store
> > > >
> > > > Who is responsible for PSAP mis-routes? I would think this
> > > transfers
> > > > liability for routing to the access-provider, are they
> > > willing to step
> > > > up to that?
> > > >
> > > > -Marc-
> > > >
> > > > > -----Original Message-----
> > > > > From: Rosen, Brian [mailto:Brian.Rosen@xxxxxxxxxxx]
> > > > > Sent: Friday, April 13, 2007 7:18 AM
> > > > > To: geopriv@xxxxxxxx
> > > > > Cc: ecrit@xxxxxxxx
> > > > > Subject: [Ecrit] Not-so-grand compromise on how to do
> endpoint
> > > > > centric LCPwithout giving away the store
> > > > >
> > > > > 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
>
> --------------------------------------------------------------
> ----------------------------------
> 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]
>
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
|
|