[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Ecrit] Re: A proposal for closing the gap between i2 and i3
Brian wrote:
>You want a government owned function that has an IP (e.g. Internet)
>connection to VoIP systems, and has connections to all the Selective Routers
>(in a State in North America) or PSAPs (in a Country elsewhere). You
>imagine we would deploy the ecrit mechanism soon, and use it to route to
>that function, and then it would use the i2 mechanism (in North America
>anyway) to route the call onward.
Not necessarily government owned. The financing is also a national matter.
It could be of course government or USF founded or paid by the emergency
call takers (ok, other goverment founds), as EISEC is in UK.
>I think the VoIP carriers would jump on that idea immediately. It would cut
>their 9-1-1 cost to near zero.
Why should VoIP carreirs pay at all for a intermediate solution and i2. With i3
they also have near zero cost. They are finally out of the picture
>They would still have to run a web based LIS
>with a call center or some other mechanism to update location for roamers
>until we got automatic location from access networks.
As I elaborate, the start could be with a very sketchy location infomation
>Please do check in with us in 2010; we may have the funding for that figured
>out. Of course, we'll probably figure out how to upgrade the PSAPs to i3
>around that time.
You should also consider that most countries have much more simpler
systems. You just need a gateway to the PSTN and a correct routing information
In simple cuase you could just route a the geo-number of the PSAP, you just have
to now it and here we are again with the mapping database
>If I understand the situation in the EU, you have the same problem. You
>want the government to change the emergency call system to match the
>characteristics of the VoIP system, and you want to do that as an INTERIM
>step before you change the actual PSAP systems.
not interim, parallel and as a migration, and as I said, in Europe most systems are
simpler.
>I don't think that works, not because we couldn't make it work technically,
>but we couldn't figure out how to pay for it, especially as an interim step.
If they want it, and they want it working for all VoIP providers, they must
find a funding. And then there is no excuse NOT to provide access to emergency
services
-richard
Brian
-----Original Message-----
From: Stastny Richard [mailto:Richard.Stastny at oefeg.at]
Sent: Tuesday, August 23, 2005 11:02 AM
To: Brian Rosen; Dale Worley; sipping
Cc: ecrit at ietf.org
Subject: A proposal for closing the gap between i2 and i3
Thank you Brian fort his comprehensive elaboration
I just want to add a proposal
Ecrit is working on a solution (i3 for short) allowing
finally any IP-based device to access the responsible
PSAP for the given location.
Since (many) PSAPs on the other hand will not be reachable via IP
for some time, as you say, there is work done on a national basis
to allow VoIP providers to access the national specific emergency
system via national specific interfaces. This architecture (e.g i2
in the US) is different in every country. "Interconnected" VoIP
providers (whatever that means) are required to interface to
these systems, "not-interconnected" are not. This is not a good idea.
On the other hand one cannot require from all VoIP providers to
interface to 200 different national PSTN-emergency systems.
So there is a substantial gap between i2 and i3.
This situation could be substantially improved by providing
national Emergency Service Routing Proxies (ESRP) doing
the mapping between i3 and i2. The ESRP take the calls
from VoIP providers and route it according to the location
information given to the PSTN and the correct PSAP interfacing
with the national emergency system
The roadmap is very simple:
The ecrit mapping database is loaded initially with the
ESRP per country or state (e.g. in at.sos.arpa or ca.us.sos.arpa)
The ESRP is doing the additional mapping via the location
information given in the INVITE, in the beginning e.g. to the
state emergency PSAP (this is as good as now)
If a better location information is given, it can do better.
Also, if PSAP appear on the Internet, their URIs are entered
in the ecrit mapping database until in 10-20 years (just kidding)
the ESRP can be shut down.
The ESRP could also provide input to existing (also national
specific) location databases (e.g. EISEC in UK) and also provide
national virtual temporarily call-back numbers for VoIP users
without E.164 numbers.
The advantage of this method is a smooth migration and on the
other hand an immediate availability of access to emergency calls
from ALL VoIP providers (not "interconnected" and also alien)
This will improve the situation substantially for the customer
and also avoid the discussion what "interconnected" means.
The investment for the ESRP is not so huge, the investment
for the gateways is substantial and has to be funded (USF?)
My question is: who may be responsible for guidelines
on an international basis?
-richard
Richard Stastny
OeFEG
tel:+43 664 420 4100
enum:+43 780 203 211
callto://fordprefect
http://voipandenum.blogspot.com
> -----Original Message-----
> From: sipping-bounces at ietf.org [mailto:sipping-bounces at ietf.org] On
Behalf
> Of Brian Rosen
> Sent: Tuesday, August 23, 2005 3:26 PM
> To: 'Dale Worley'; 'sipping'
> Subject: RE: [Sipping] Draft Notes from Ad-hoc on SIP peer-to-peer
>
> Couple of points to be made:
>
> 1. The term PSAP is not US-centric. It appears in several other
countries
> lexicons. There is no universally accepted term, and the authors of
> various
> works on the subject have tried "Emergency Response Center" without
much
> success. PSAP will do.
>
> 2. There is quite a bit of effort underway to develop new IP based
> technology at the PSAP. It will probably be possible some day to have
a
> SIP
> call terminate right at the call taker workstation. This requires
> upgrades
> at the PSAPs, and that is notoriously difficult to accomplish,
primarily
> (almost exclusively) because of funding issues. Unless you are
prepared
> to
> state how new software, hardware and network connectivity, with
> accompanying
> processes, firewalls, training, etc is going to be paid for, then you
> might
> have to wait the usual decade (in the U.S., often longer elsewhere)
until
> every PSAP can terminate a SIP call. I have some optimism that there
will
> be some funding available in the U.S. I don't have any reason to be
> optimistic at the moment elsewhere. Please also realize that,
typically,
> once a call is answered at a PSAP, it is transferred to the
appropriate
> responder(s). They too may need upgrades to their telephony systems.
>
> 3. It is not trivial to connect SIP based VoIP callers to existing
> systems,
> although the difficulty varies quite a bit with the sophistication of
the
> emergency call network. In North America, it's pretty hard if it is
> possible to roam, because existing systems assume the location of the
> caller
> is statically determinable from a database queried by the telephone
> number,
> or the carrier participates in a medium complexity scheme that allows
a
> dynamic location of the caller to be sent to the PSAP when it queries
the
> database. Also, emergency calls are NOT sent through the PSTN. In
North
> America, each switch (central office) has special trunks that connect
to a
> special tandem switch to which PSAPs are connected. In other
countries
> there is no need for a special tandem, but most use special trunks
> directly
> from the CO switch. You can use a relatively straightforward gateway
> (typically SS7 signaling on the TDM side, sometimes, in North America,
an
> odd MF signaling standard called CAMA), but it connects to the 9-1-1
> tandem
> (called a "selective router"), or directly to the PSAP.
>
> There is a standard (called "i2") that NENA (the North American
Emergency
> Number Association) developed that does allow VoIP calls to be put
into
> the
> current NA system correctly. It involves a couple of new databases
> derived
> from the existing one, a specialized service provider and gateways to
the
> Selective Routers.
>
> 4. The ecrit work will provide a way to route a call to a SIP uri
based on
> the location of the caller. That is one of the key mechanisms
required to
> accomplish 1) above. The mechanism is not decided, but, roughly, you
> query
> a database with location, and it gives you a URI. Any entity could
> implement that mechanism, even a P2P UA. Given a URI, that P2P UA
could,
> theoretically, route the call to the PSAP, where, again,
theoretically, it
> could be answered by the call taker. That implies that the PSAP
> implements
> P2P SIP, whatever that turns out to be as well as regular SIP, which
is
> the
> current assumption. I would personally not consider that to be much
of an
> obstacle, but it depends on the complexity, security and other
operational
> issues that are unknown at the moment.
>
> Brian
>
> -----Original Message-----
> From: sipping-bounces at ietf.org [mailto:sipping-bounces at ietf.org] On
Behalf
> Of Dale Worley
> Sent: Monday, August 22, 2005 1:03 PM
> To: 'sipping'
> Subject: RE: [Sipping] Draft Notes from Ad-hoc on SIP peer-to-peer
>
> > From: Michael Hammer (mhammer)
> >
> > Absolutely! The Public Safety Access Points (PSAP or emergency call
> > center -- a colleague reminded me that that is a US-centric term)
might
> > be able to use less expensive terminals (PC?), and would have a more
> > rich environment to work with, IF they stop requiring backward
> > compatibility with the PSTN-based systems.
>
> That isn't a technological issue -- it would be straightforward to
> overhaul
> an emergency call center to handle incoming calls from a "SIP trunk",
and
> to
> process the calls using workstations that are SIP UAs. For PSTN
> compatibility, incoming PSTN trunks could be attached to "SIP
gateways"
> that
> translate PSTN calls to SIP calls. (Gateways are made by Audiocodes,
> Vegastream, Cisco, and a number of other companies.) This is only a
bit
> different from what many companies are now doing with their internal
PBX
> systems. (And there might be a lot of cost savings to be had, too.)
>
> Dale
>
>
> _______________________________________________
> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sip at ietf.org for new developments of core SIP
>
>
>
> _______________________________________________
> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sip at ietf.org for new developments of core SIP
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit