[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09

At 01:13 PM 6/2/2009, John Lange wrote:

I covered a lot of ground in my last post and I can tell from the
responses that some of the points weren't clear.

I apologize so please let me clarify;

- I'm not disputing that having the endpoint do network discovery of
location is the best first choice.


this was not clear in your original post.



What I'm saying is;

1) Endpoint location discovery via DHCP is not going to work for
residential so some other mechanism will need to be employed (and I
think it should be STUN + DNS).

2) The SIP Registrar needs to know if the end point has it's location so
that the SIP Registrar can do OBO and discover the Emergency Services
Routing Proxy (ESRP) URI _before_ an emergency call is placed.
clearly a SIP server that doesn't receive location in a 911 call knows to include Ua location if it knows it. The issue is recognizing the call is 911 from the URI to know location needs to be looked for before transmitting the INVITE on. The trick is recognizing the URI as that of a PSAP (without the sos urn, that is). 



3) allowing the OBO to happen before the call will dramatically reduce
the network infrastructure requirements and therefore the cost of
implementing the solution because real-time IP location determination
done to a standard good enough for emergency call routing (less than 3
seconds) requires a significantly more robust solution than a
query-cache methodology.
OBO before the fact means the location information could be stale/old/wrong... this was the argument for using a URI instead of actual location. It seems we can't get away from this little detail. 



---

The bottom line here is that if the device doesn't know it's location
and the SIP registrar isn't aware that it needs to do OBO, then in all
likelihood the device can not place an emergency call to the correct
ESRP since querying location on-the-fly will be too slow to route the
call correctly.

That's it in a nutshell but I'm going to pull all the threads together
and reply with some more detail to some specific questions inline below:

On Mon, 2009-06-01 at 17:01 -0500, James M. Polk wrote:
> For LLDP, I fully agree with what you have above. I've had 4 ISPs
> over the last 10 years, and EACH of them have used DHCP, so I'm not
> sure where you get your data wrt DHCP not being supported in the
> residential market.

I'm talking about residential firewall/routers. Someone else on this
list pointed me to this:

"Location Information Server (LIS) Discovery From Behind Residential
Gateways"

http://tools.ietf.org/html/draft-thomson-geopriv-res-gw-lis-discovery-00

> >It would therefore seem that the emphasis should be on a LIS discovery
> >mechanism that does not rely on the local network such as STUN + DNS.
>
> How many vendors in the residential market do you know of that implement STUN? 

STUN would be implemented by the VOIP provider and their devices would
be provisioned to query their own STUN servers. Many VOIP providers are
using STUN today and every recent VOIP device I've looked at recently
has an implementation of STUN so I submit that it is widely supported.

> It appears you keep getting back to a solution that requires an
> upgrade in the access networks

Not at all. That is precisely what I'm trying to avoid.

> or endpoints.

An upgrade to endpoints so they can do location is inevitable but the
OBO functionality is there to cover-off those devices which can not be
upgraded.

On Mon, 2009-06-01 at 17:09 -0400, Brian Rosen wrote:
> There isn't any point in caching it at the proxy, and it's a privacy
> issue if it does.

You are correct that caching isn't required if the device knows it's
location _provided that_ the proxy is aware that the device already has
it's location.

However, as I stated above, if the devices doesn't know it's location
the registrar needs to know about it so it can do OBO. And if the
registrar is doing OBO then it needs to cache the result.

So my point would be, if you are going to allow the registrar to do OBO
and cache results then it might as well cache location for the other
devices as well so it can use that information as a backup just in case
the device looses its location or becomes unreachable for some reason
(for example, lets say the internet to the endpoint drops during a 911
call. If the proxy has the info cached it could answer OBO the device).

Furthermore, (*** this is a critical point ***) if the device does not
provide location and the OBO server is not able to determine location,
this could trigger some other action. This allows VOIP providers to
easily identify "dead spots" in the LIS/LOST (such as non-compliant
ISPs) and take corrective action (notify the regulator).

On the topic of privacy; real-time IP location determination is a
_MASSIVE_ privacy issue that will need to be addressed with public
policy, not an RFC.

Keep in mind that the VOIP provider already has sensitive personal
information for the user so suffice to say that as long as the
information is only accessible to authorized people, then exactly who
those authorized people are is something for the politicians to decide.

> "On behalf of" is needed when the device DOESN'T get it's location from its
> access network.  I think you have a point on the language of the on behalf
> of language in -phonebcp, but your suggestion is not good enough.  The
> problem to be solved is one way or another we have to get location.  The
> current wording is aimed at proxies who think they ought to do it always,
> and the language says, fine, as long as you CAN do it always.

Actually, I think BCP would be: "Proxies MUST provide location on behalf
of devices ONLY if the device does not provide it's own location."

"If the device does not provide location and the proxy can't find
location OBO the device, then the call MUST be routed to a 3rd party
call centre for verbal location and routing."

Regards,
--
John Lange
http://www.johnlange.ca

_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit