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

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

Subject: RE: [Ecrit] Not-so-grand compromise on how to do endpoint centricLCPwithout giving away the store
From: "Brian Rosen"
Date: Fri, 13 Apr 2007 15:21:36 -0400
ESRPs URIs are just PSAP URIs as far as anyone outside the Emergency
Services IP Network is concerned.  What you get out of LoST is an ESRP URI
or a PSAP URI, and which you get depends on the local emergency authority's
wishes.   We don't need to know, and we don't do anything different.

Within the ESInet, the ESRP may well use LoST to do further routing.  In
North America, we imagine a common arrangement would be that a regular user
query to LoST would yield an ESRP URI that was roughly operated at the state
level -- all calls from Virginia go to a (replicated, load balanced) ESRP.
The ESRP may do a further LoST dip, and take into account local conditions,
like congestion and PSAP state, and time of day, and decide which PSAP will
actually get the call.

This is invisible to the endpoint, the access network and the VSP.  It's all
in what LoST returns.

So I don't think we need to specify how ESRPs work.  I think the important
part for you is that the access network would trust the ESRP for a
dereference the same as it would trust a PSAP.  In North America, they would
probably have similar credentials.

Brian

> -----Original Message-----
> From: Liess, Laura [mailto:Laura.Liess@xxxxxxxxxxxxx]
> Sent: Friday, April 13, 2007 12:49 PM
> To: Brian.Rosen@xxxxxxxxxxx; Hannes.Tschofenig@xxxxxxx
> Cc: geopriv@xxxxxxxx; ecrit@xxxxxxxx
> Subject: AW: [Ecrit] Not-so-grand compromise on how to do endpoint
> centricLCPwithout giving away the store
> 
> 
> Brian, Hannes,
> thank you for bringing up this issue.
> In principle, I like the option for the access network to supply the PSAP
> URI. A similar option could be for the AN to provide an ESRP URI.  The
> ESRP URI is for the AN a trusted party, so it has the necessary
> credentials to fetch the Location Info from the LIS.
> 
> I figured out how such a scenario could work
> 
> 
> 
>                Configuration           VSP's                      LoST
>        Alice      Servers               SIP proxy         ESRP
Servers
> PSAP
> 
>      ***Alice gets IP-connectivity****
>       [M1]   DHCP (with LbyR, country code and ESRP URI)
>          <---------
> 
>      ***Some time later, Alice dials/initiates emergency call***
>       [M2] INVITE (sos URN or 911/112, contains LbyR, country code and
> ESRP URI)
>          ------------------------------->
>                                [M3] LoST Query (contains country code and
> ESRP URI)
>                                          --------------------------->
>                                [M4] LoST Response (contains a mark if ESRP
> URI is valid)
>                                         <----------------------------
>                                         [M5] INVITE (sos URN or 911/112,
> contains LbyR)
>                                          ------------->
>                          [M6] HTTPS(contains LbyR)
>                     <----------------------------------
>                           [M7] HTTPS(contains Location)
>                      --------------------------------->
>                                                   [M8] LoST Query
> (contains Location)
>                                                    --------------------->
>                                                   [M9] LoST Response
(contains
> PSAP URI)
>                                                   <----------------------
>                                                   [M10] INVITE (contains
> Location)
>                                                    -----------------------
> ------------>
>                                                           200 OK
>          <----------------------------------------------------------------
> ---------------
>                                     ACK
>          -----------------------------------------------------------------
> -------------->
> 
> 
> I think if there is a local ESRP between the VSP's SIP Proxy and the PSAP
> we are more flexible to comply to country-specific regulations.
> The ESRP could choose the PSAP based on a local LoST server which knows
> the capabilities of the local PSAPs. E.g. during a transition period we
> may have the old PSTN PSAPs and very few IP PSAPs with additional
> capabilities, e. g. emergency call takers speaking foreign languages or
> emergency call takers for deaf people. The local LoST server would be able
> to choose the right PSAP (this is just an idea, I don't know whether or
> not it's realistic).
> 
> 
> Thanks
> Laura
> 
> 
> 
> 
> 
> 
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Rosen, Brian [mailto:Brian.Rosen@xxxxxxxxxxx]
> > Gesendet: Freitag, 13. April 2007 13:18
> > An: geopriv@xxxxxxxx
> > Cc: ecrit@xxxxxxxx
> > Betreff: [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
> >
> 
> _______________________________________________
> Ecrit mailing list
> Ecrit@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ecrit


_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit

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