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

["James M. Polk" <[e-mail]>]

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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit