Subject: [Sipping] Re: A proposal for closing the gap between i2 and i3

From: "Stastny Richard" <[email-masked]>
Date: Tue, 23 Aug 2005 19:33:39 +0200

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:[email-masked]]
Sent: Tuesday, August 23, 2005 11:02 AM
To: Brian Rosen; Dale Worley; sipping
Cc: [email-masked]
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: [email-masked] [mailto:[email-masked]] 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: [email-masked] [mailto:[email-masked]] 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 [email-masked] for questions on current sip
> Use [email-masked] 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 [email-masked] for questions on current sip
> Use [email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 23 Aug 2005 20:56:34 +0300

Stastny Richard writes:

 > systems. You just need a gateway to the PSTN and a correct routing
 > information.

exactly, in finland when my sip user dials 112, my proxy simply prefixes
that number with string 3979<communityCode>, where <communityCode> is a
three digit code of the town the caller is in.  pstn network then knows
how to route the call the correct emergency center based on the
community code.  thus any sip/pstn gw can handle also emergency calls
and the cost to sip provider is zero.

the next step that i'm pushing is that government sets up these sip/pstn
gws for emergency call purpose, which would make the system independent
of sip providers.  this would cost the government almost nothing and
would allow also sip user who are not customers to any sip provider to
make emergency calls.

the next step is to include real location information in the sip
request based, for example, on mobile base station coordinates.

-- juha

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 23 Aug 2005 16:05:07 -0400

I think this is naïve.

Where is the location information coming from?  In i2, it initially comes
from a self reported location = a website the VoIP carrier runs.  That's a
poor answer, but it's the only one we can do in a short time frame.  What
you want is automatic location reporting, and that takes a bunch of work in
the access network, and the phones and/or the call servers.  Is the
government going to run the website?  

Then you need to decide if PSTN routing from a gateway, is appropriate.
Most emergency call systems I know about don't do this; they have special
routing directly from the end office serving the subscriber to the PSAP (or
to the special tandem in North America).  Using the PSTN to route calls has
been considered (several times) here, and it has been rejected.  One reason
is that 9-1-1 calls are not given special treatment in normal inter-switch
routing (because they aren't sent between switches except as noted).

Then you have the problem of Denial of Service.  If you make it real easy to
"bomb" the emergency service with lots of calls with no authentication, they
will not be happy.

Brian

-----Original Message-----
From: Juha Heinanen [mailto:[email-masked]] 
Sent: Tuesday, August 23, 2005 1:57 PM
To: Stastny Richard
Cc: Brian Rosen; Dale Worley; sipping; [email-masked]
Subject: [Sipping] Re: A proposal for closing the gap between i2 and i3

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 24 Aug 2005 08:08:09 +0300

Brian Rosen writes:

 > from a self reported location = a website the VoIP carrier runs.  

right now community information comes from whatever the user has
configured in his proxy as his community using a web page.  so this
seems to match what you have.

 > That's a

the only thing i have proposed is that each mobile operator is MANDATED
to have a web site accessible via xml-rpc, for example, that contains
coordinates of their mobile base stations.  sip phone having mobile
network access, can then calculate its location that can be mapped to
community code by another xml-rpc call.  gps would be another choice,
but not a very good one, because it seems to work only outside and even
then takes long time to initialize.

 > to the special tandem in North America).  

this is not the case in many countries outside of n.a.

 > "bomb" the emergency service with lots of calls with no authentication, they

today it is possible to make emergency calls with a cell phone without a
sim card.  so the same problem exists already.  the question is, which
is more important:  possibility to make emergency call anonymously or
not to be able to make the call at all.

-- juha