|
|
Hi Laura,
in some sense your proposal is similar to use a SIP proxy in the access
network (or someone that is closely related to it). Couldn't we just use
the DHCP discovery technique for SIP proxies for that purpose?
Ciao
Hannes
Liess, Laura wrote:
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
|
|