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

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

We're trying to define real world solutions.  We may fail, but we're trying.

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.

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.

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.

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, the
query to the provider will have the right thing to get the DHCP system to
return the location of the residence.  If you don't like DHCP, use HELD, but
you still have some remnants of the VPN problem.  Don't confuse DHCP for LIS
discovery with DHCP for location configuration.  Both work, but DHCP
discovery of a HELD server works.

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.

Brian

> -----Original Message-----
> From: John Lange [mailto:john at johnlange.ca]
> Sent: Tuesday, June 02, 2009 5:20 PM
> To: Brian Rosen
> Cc: 'ecrit'
> Subject: RE: [Ecrit] Emergency Call Framework for Canada; Questions on
> draft-ietf-ecrit-framework-09
> 
> On Tue, 2009-06-02 at 14:35 -0400, Brian Rosen wrote:
> > 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.
> 
> Yes, the IP location determination infrastructure requires a
> relationship between the VOIP Provider, the ESRP (PSAP), and the
> ASP/ISP. I took this as being understood because it's mentioned in the
> paragraph 2 of draft-ietf-ecrit-framework: "Supporting emergency
> calling
> requires cooperation by a number of elements, their vendors and service
> providers."
> 
> The requirement to have a relationship between the providers isn't a
> significant obstacle. The regulator will say "you MUST implement this"
> and it will happen. The goal is to have a standard that can be followed
> so that when the mandate is imposed, the solution is known and
> hopefully
> there are already vendors who support it.
> 
> >   You can't have environments where it doesn't always work
> 
> You can't? Well that makes some sense in the context of
> draft-ietf-ecrit-framework. Since the Internet is an environment that
> "doesn't always work", perhaps draft-ietf-ecrit-framework was not
> intended for use there? It makes no specific mention of this but by
> design it could only be deployed where the endpoint has a direct
> relationship with a local network that knows about location. That
> pretty
> much eliminates all residential and small/medium business.
> 
> > You're focused on fixed devices, which is okay, but what you are
> describing
> > won't (necessarily) work for mobile or nomadic devices.
> 
> What I envision will work for fixed and nomadic devices that access the
> internet through fixed access points that cover relatively small
> geographical areas. In other words, residential and small/medium
> businesses.
> 
> Large enterprises would implement their own solutions and that is where
> the DHCP style solution described in the ecrit-framework makes the most
> sense.
> 
> Mobile devices would also work depending on how they are accessing the
> internet but I don't want to side-track on the discussion of cell
> phones
> vs. mobile VOIP phones etc.
> 
> > 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.
> 
> As I said, maybe I've misunderstood the purpose of this group. If
> draft-ietf-ecrit-framework is just intended as "blue-sky" or use in the
> enterprise then I apologize for hijacking this list with my concerns
> over real-world implementation.
> 
> >  If the access network is upgraded to handle location, it's likely to
> > offer DHCP
> 
> ... and a DHCP solution won't work behind residential firewalls and
> won't allow OBO functionality so it can't be implemented for the number
> one place where governments are likely to mandate a solution;
> nomadic/residential VOIP.
> 
> IMHO, if you don't have a solution for residential then it's all just
> theory.
> 
> That is why I'm advocating a closer look at something like STUN + DNS
> for LIS discovery. It will work, allows OBO and requires no new
> hardware.
> 
> If the IETF publishes a standard then each jurisdiction can decide to
> implement it or not.
> 
> Chances are good they will implement it because the advantage of
> implementing an IETF standard over some other "home-brew" solution is
> that your citizens can roam to other jurisdictions and vice-versa. Plus
> the likelihood of endpoints supporting the IETF standard at a
> reasonable
> cost is much higher than if vendors have to implement a unique solution
> for every jurisdiction.
> 
> That is what standards are all about after all...
> 
> On the other hand, I doubt any solution will ever be universally
> implemented but that's fine. As a VOIP provider I only have to meet the
> regulatory requirements in my jurisdiction, not every place on earth.
> 
> Regards,
> --
> John Lange
> http://www.johnlange.ca