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

[John Lange <john at johnlange.ca>]

On Tue, 2009-06-02 at 17:44 -0400, Brian Rosen wrote:
> We're trying to define real world solutions.  We may fail, but we're trying.

The work ecrit has done on this issue is exemplary. Much better than
previous attempts (i2).

However, as James Winterbottom pointed out, "There was one very strong
point made in i2 all along, and that is NO UPGRADES to residential
equipment is required in order for it work."

So i2 might be dead, but the various groups that represent PSAPs in the
US and Canada have made this a clear requirement. So, even if you
completely disagree with the need for equipment replacement, the
parameters have already been set.

> OBO doesn't always work, because by the time a call gets to a VoIP provider,
> it's IP address can be obscured by VPNs.  It doesn't work because the
> regulator can't force connections between a service provider it doesn't have
> jurisdiction over to an access network (which it probably always has
> jurisdiction over, because it's always local).

>   The easy example is my
> famous "Sierra Leone VoIP Services Pty" provider serving a customer at a
> Starbucks in, say, Calgary.  You can scream all you want, but CRTC can't
> tell SLVS to connect to Rogers Cable.

Your example clearly identifies the divide between a
technical+regulatory solution and a strictly technical one.

In the above example, technically it may not work but from a regulatory
perspective it does work. It works because the CRTC doesn't care if the
SLVS user can reach 911 from his laptop in a Calgary Starbucks. SLVS is
not regulated by the CRTC and therefore users of SLVS are not required
to have access to 911.

To be clear, the CRTC only requires that customers of Canadian VOIP
providers have access to 911 while in Canada.

Conversely, Canadians using their devices while outside of Canada _MUST
NOT_ have access to a Canadian PSAP (i.e. create nuisance calls). It's
the opposite of what some might think.

If the SLVS regulator wants to dictate that SLVS customers have access
to 911 (or whatever) everyplace on earth, then I say good luck with
that.

> On the other hand, the device can get location from the hotspot in
> Starbucks, who can pass it through SLVS on it's way to the Calgary PSAP.

On the one hand you've argued that anything based on a public IP won't
work because the CRTC doesn't have jurisdiction over SLVS, but on the
other hand you've ignored that very same regulatory restriction by
assuming that SLVS will have a relationship with a Calgary PSAP.

This is not the case. I can positively assure you that the Calgary PSAP
will not accept calls from any VOIP provider that it does not have a
prior relationship with and for the foreseeable future that means VOIP
providers inside Canada.

PSAPs are _very_ sensitive to nuisance calls so the concept that the
PSAP/ESRP will be open to any IP address in the entire world... no.

And as you already pointed out, there can't be a regulatory requirement
for this because the CRTC has no jurisdiction to require a relationship
with SLVS. (as a side note; the CRTC actually has no jurisdiction over
PSAPs what-so-ever but PSAPs will likely go along with the CRTC
decision).

So, if I understand the position of this group, solutions that require
relationships between VOIP providers, ISPs, and PSAPs are not considered
viable because they require regulatory authority over all three parties
everyplace on earth which is impossible.

But the reality is, regulators only care about their own jurisdictions
and they DO have authority to order relationships between all three
parties.

>From the standpoint of the VOIP provider, the PSAP, the ISP and the
regulator, the fact that a given solution might not work if one of the
three parties is outside the jurisdiction of the regulator is
irrelevant.

> OBO is usually aimed at transition: before we get the devices all upgraded,
> what do we do.  In that environment, we may not be able to get location
> every time, although I think the VPN problem is so prevalent that it's going
> to fail too often.  I'm still in favor of trying to get OBO to work, for
> transition only, and with the caveat that it may not always work.

That is a very reasonable position and one I fully support. OBO must be
implemented even though it won't work 100% of the time.

> DHCP works very well in residential VoIP.  The phone may have a NATed
> address, but as long as the home router passes the location option,

Ok, full stop here... A couple of messages on this list have made this
point without providing any technical explanation.

What I don't understand is how this will be done without upgrading or
replacing residential firewalls?

It's like saying "it's easy to get to the moon provided we shut off the
earth's gravity."

> If you don't like DHCP, use HELD,

I'm advocating using HELD, but first you have to discover the LIS so you
can do the HELD query. That's why we need STUN + DNS for LIS discovery
on endpoints and DNS LIS discovery for OBO.

>  but you still have some remnants of the VPN problem.

Again, there is a split here between the regulatory and technical. The
vast majority of users doing VOIP over VPN are "dialing-in" to corporate
VOIP servers. There is no regulatory requirement to provide location for
corporate users. It may well become a regulatory requirement in the
future but nobody has even raised it yet. Given that we're still
struggling with residential, it's safe to say that any such requirement
is several years off so holding up everything on that requirement isn't
necessary.

That being said, the technical solution is for the provider (in this
case the corporation) to provide the LIS and by forming a relationship
between the VPN tunnel and the enterprise LIS so that the LIS knows to
query an external LIS for location based on the public IP, not the
WAN/VPN IP.

>   Don't confuse DHCP for LIS
> discovery with DHCP for location configuration.  Both work, but DHCP
> discovery of a HELD server works.

Again, I fundamentally disagree with this statement because it leaves
out the phrase "provided we upgrade and/or replace most every
residential firewall device currently in service."

> I've stayed out of most of the LIS discovery discussions because I don't
> seem to have much to offer.  I'll let others reply to STUN + Reverse lookup
> + SRV. It's been discussed many times.

On this list? I went through a fair portion of the list archives and
can't find anything. And "google: ecrit stun" turns up nothing from this
group.

---

The comment by Barbra Stark is quite telling; "But I'm fine for the IETF
not to document or provide a BCP for that. I can go elsewhere for
refining best practices. Which is why I don't really care to argue this
question anymore."

With apologies to Barbra for putting words in her mouth; "The BCP
developed by this group ignores reality. I'll go elsewhere for for BCP".

I get the impression that this has been argued many times in the past so
I guess it's just my turn to stir up the pot ;)

The framework document I'm developing for submission to my regulator
will not follow ecrit-framework or ecript-phonebcp (though it will be
based on it) for all of the reasons that I've made apparent on this
list.

However, the framework would be stronger if it did follow ecrit and
likewise, ecrit-framework and ecrit-phonebcp would be stronger if they
could demonstrate success in the marketplace.

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