In the circuit service world - whether it was POTS or mobile, the access network had full responsibility for delivering the emergency call. In that world, routing an emergency call meant getting a circuit established to the correct call center. In most parts of the world, this was done using the regional part of the PSTN to switch the circuit to a call center on the PSTN. In some jurisdictions, such as the US, it was done directly from the local exchange carrier to the call center. Either way, there was no third party involved.
Now we have the Internet. We still have public access network providers. They switch packets onto the Internet for their subscribers. They can similarly ensure that packets reach the local emergency call centers.
The fact is that there was no equivalent of a VSP in the traditional environment. VoIP is a presence service, and it had no common equivalent in the PSTN world. It could have, but the narrowband state of technology and the common market use cases didn't support its development. By the time ISDN arrived, the PSTN had already slipped into its palliative stage without realizing it.
It's an entrenched misconception that because the circuit service provided by exchange carriers was most commonly used for "voice" (but, it should be noted, also for fax, telex, tty, security system monitoring and, even, IP data) that VSPs are somehow equivalent to exchange carriers. They are not.
Indeed, involving VSPs in emergency calls is the Internet equivalent of involving long distance providers in POTS emergency calls. They are neither necessary nor particularly helpful; they can't be guaranteed to be within the emergency jurisdiction; depending on them actually diminishes the efficacy of emergency service access. It does not help the caller, the emergency service, nor the third party to insist on the third party's involvement.
It can't be helped if you have over sold the benefits of VSP involvement to yourself and others Brian. It is time to have a reasoned debate. From my perspective, the argument that there is no "subscription" involved is patently false. There has to be a subscription of some description in order to get to the Internet. Yes, there is free public Internet access (just as there are free courtesy phones on the PSTN and free access to emergency services from pay phones. All these services are still connected to the public Internet infrastructure and they all represent an "operator" with some level of information about the caller.
With the over-emphasis on VSPs, what is missing from the ECRIT and i3 models is the direct interface for querying the access network for subscriber data (should it prove necessary). These models need to take the long view of how emergency calling is done in the Internet age; they should not be protracting an unnecessary reliance on VSPs.
I have deleted the premature and prejudicial text from the subject heading. And I'll leave this on ECRIT as the most appropriate WG.
Cheers,
Martin
-----Original Message-----
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Tuesday, 27 October 2009 8:23 AM
To: ecrit@ietf.org
Subject: [Ecrit] FW: [Geopriv] Winterbottom-ecrit-direct considered harmful, at least given our current experiences
FYI: feedback from Brian regarding a recent ECRIT contribution.
>-----Original Message-----
>From: geopriv-bounces@ietf.org
>[mailto:geopriv-bounces@ietf.org] On Behalf Of Rosen, Brian
>Sent: 26 October, 2009 23:10
>To: geopriv@ietf.org
>Subject: [Geopriv] Winterbottom-ecrit-direct considered
>harmful, at least given our current experiences
>
>The notion behind -direct is to not use a service provider to
>place an emergency call. Instead, the device registers with
>an Emergency Services Routing Proxy immediately before the
>call and the call is routed directly from the device to the ESRP.
>
>At least at the moment, this is an exceedingly bad idea.
>
>Emergency calling authorities like service providers, a lot.
>They like them because they can hold them accountable, and the
>service providers don't like theft of service, which is
>something the emergency call guys have an analog to.
>
>The facts are that where unaccountable access to emergency
>calling is allowed, huge numbers of false calls occur, with no
>way to stop them, and no way to tell the good ones from the
>bad ones. This has been seen multiple times where so called
>"simless" or "unauthenticated" calls are allowed.
>
>-direct precisely duplicates simless calling. The only
>"registration" is an emergency registration, only emergency
>calls are allowed, any device can make an emergency call if
>all it has is a (radio) connection to any network.
>We can predict, with a very high degree of certainty, that the
>feature will be horribly abused: for example to test that a
>phone without a service plan works.
>
>There have been studies which show tens of thousands of bad
>calls with zero good ones. Nearly every authority I know
>where the regulator has insisted on simless calling wants it
>repealed. There is one counter example I know where the fact
>that they got a couple, literally, of good calls among the
>tens of thousands of bad calls was considered enough reason to
>put up with the problem.
>
>Service providers give us information that may be useful: a
>subscriber name and address for example, which is not
>spoofable by the caller. They have ways to trace callers,
>especially bad callers. They don't want their systems abused
>any more than the emergency calling authorities do.
>
>This is a bad idea. A very bad idea. Please stop it.
>
>Someday, we may have better ways to prevent abuse. Until we
>do, service providers are a good thing on an emergency call.
>We don't want them cut out.
>
>Brian
>
>_______________________________________________
>Geopriv mailing list
>Geopriv@ietf.org
>https://www.ietf.org/mailman/listinfo/geopriv
>
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
