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

["Brian Rosen" <br at brianrosen.net>]

Why would the proxy really care to know if the device can get its own
location?  I would assume it would OBO as much as it could.  In general, OBO
isn't reliable unless there is a regulatory requirement to make
relationships between providers exist in every case.  You can't have
environments where it doesn't always work (unless you know for sure that the
access network provides location).

You're focused on fixed devices, which is okay, but what you are describing
won't (necessarily) work for mobile or nomadic devices.

We're also familiar with the no DHCP in DSL environments.  Although we
recognize that this is the case today, we understand that is not the case
tomorrow, and this whole document is aimed at new devices.   If the access
network is upgraded to handle location, it's likely to offer DHCP (and, BTW,
it doesn't have to use DHCP to give out IP addresses).

Brian

> -----Original Message-----
> From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On Behalf
> Of John Lange
> Sent: Tuesday, June 02, 2009 2:13 PM
> To: ecrit
> Subject: Re: [Ecrit] Emergency Call Framework for Canada; Questions on
> draft-ietf-ecrit-framework-09
> 
> 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.
> 
> 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.
> 
> 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.
> 
> ---
> 
> 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