From: Henning Schulzrinne <hgs at cs.columbia.edu>
Date: November 2, 2008 2:04:27 PM EST
To: <Gabor.Bajko at nokia.com> <Gabor.Bajko at nokia.com>
Cc: Hannes Tschofenig <Hannes.Tschofenig at gmx.net>, Stephen McCann <stephen.mccann at roke.co.uk
>
Subject: Re: Comments on draft-schulzrinne-ecrit-unauthenticated-
access-03 - Section 1
On Nov 1, 2008, at 4:39 AM, <Gabor.Bajko at nokia.com> <Gabor.Bajko at nokia.com
> wrote:
Isn't it a safe assumtion that in case of NAA, the existence of a VSP
does not matter? I.e., when the ISP gives access to an NAA device for
emergency calls purposes, it is expected to provide additional
assistance for the end host to place the emergency call, without
requiring the end host to have a VSP.
Depends on the assumptions. If PSAPs rely on VSPs to provide user
identity to deal with prank calls, for example, the presence or
absence of a VSP could matter in the NAA case. We haven't discussed
that aspect much, but I wouldn't be surprised if the PSAP started
getting worried if there's no realistic way to track down crank calls.
In NVP case the ISP has no means to know that it needs to provide
emergency call related additional assistance to the end host. The end
host is pretty much on its own and needs to have a way to determine
its
location and find a LoST server, even in case RFC5223 is not
supported
by the ISP.
Realistically, in the NVP case, the ISP has to at least provide a
pointer to a LoST server. I don't think we have any other way to
provide the caller with that information, given that manual
configuration isn't really a viable option.
The text I wrote alludes to that. Are you disagreeing with the text
or the formulation?
Or, have a separate requirement that ISPs committed to assist end
hosts
in emergency calling, need to support RFC5223. Or, as described in
section 5, have an ESRP which routes the call to the PSAP to which
that
access network belongs to.
This is probably something that the phone-BCP needs to address,
namely what happens if the client cannot find a LoST server. In that
case, the ISP would have to offer an ESRP, as you say. Here's some
text for the current draft:
OLD:
the ISP MUST provide the address of a LoST server via DHCP [rfc] if
this model is to be supported.
NEW:
the ISP MUST either provide the ... or an outbound proxy that can
recognize and route emergency calls. Providing a reference to a LoST
server is preferred since it allows the user agent to automatically
obtain the local emergency dial strings.
The ZBP case can be split into either NVP or regular VoIP emergency
call
through a VoIP service provider, depending on whether the VSP is
required by regulation to provide emergency calling services to such
customers or not.
That's true, except for the discussion about fraud prevention. The
current text alludes to that.
It seemed worthwhile to split out the case since it needs to be
addressed explicitly by regulation and VSP need to take it into
account in building their infrastructure. (For example, this will
probably affect how they handle any RADIUS-based authentication,
since it now differs for REGISTER and emergency INVITE.)
I think it is good to have these definitions, but at the end it all
comes down to what assistance an ISP needs to provide to an end
host in
the NAA case, or what the end host is supposed to do when it does
have
network access, but does not have a VSP which could assist it in
emergency calling.
Right - I was just trying to divide the cases, even though the most
interesting case is the NAA case. The previous version wasn't all
that clear on the distinctions and lumped together NAA and NVP. As
you say, these differ significantly.
In general, do you have specific text suggestions to improve clarity?
Henning