1. Emergency Calling for VoIP: A Progress Report
Henning Schulzrinne
(with Anshuman Rawat, Matthew Mintz-Habib, Xiaotao Wu and Ron Shacham)
Dept. of Computer Science
Columbia University
VON – October 19, 2004 (Boston, MA)

2. Overview Problem summary Requirements and opportunities I1, I2, and I3
Competing visions
Early prototype implementations

3. Core long-term requirements
Media-neutral
voice (+TDD) first, IM and video later
Work in systems without a voice service provider
many enterprises will provide their own local voice services
Allow down-stream call data access
as well as access to other “tertiary” data about the incident
Globally deployable
independent of national emergency number (9-1-1, 1-1-2, etc.)
respect jurisdictional boundaries – minimize need for cross-jurisdictional coordination
allow usage even if equipment and service providers are not local
travel, imported equipment, far-flung locations
Testable:
verifiable civic addresses (“MSAG validation”)
call route validation
Secure and reliable

4. Standardization efforts
IETF (Internet Engineering Task Force)
SIP and DNS usage
possibly new protocols for lookups
BOF (pre-WG) at upcoming IETF meeting in Washington, DC
NENA (National Emergency Number Association)
requirements based on operational needs of PSAPs
I2 (mid-term transition) protocols for mapping
EMTEL (Europe)
getting started

5. Three stages to VoIP 911 I1 I2 I3 spec. available?
use 10-digit admin. number?
mobility
callback
number to PSAP?
caller
location to PSAP?
PSAP
modification
ALI (DB)
new services I1
now
allowed
stationary no
none I2
Dec. 2004
nomadic
yes
no (8 or 10 digit)
update I3
late 2004
mobile
IP-enabled
ALI not needed
MSAG replaced by DNS
location in-band
GNP
multimedia
international calls

6. Location, location, location
Location  locate right PSAP & speed dispatch
In the PSTN, local calls remain geographically local
In VoIP, no such locality for VSPs
most VSPs have close to national coverage
Thus, unlike landline and wireless, need location information from the very beginning
Unlike PSTN, voice service provider doesn’t have wire database information
VSP needs assistance from access provider (DSL, cable, WiMax, , …)

7. I3 (long-term) architecture components
Common URL for emergency calls
Convey local emergency number to devices
Allow devices to obtain their location
directly via GPS
indirectly via DHCP
locally via LLDP (802.1ab, TIA LLDP-MED)
initially, often through manual configuration
Route calls to right destination
using look-up in device or proxy

8. I3: Location-based call routing – UA knows its location
GPS
INVITE
48° 49' N 2° 29' E
outbound
proxy server
DHCP
48° 49' N 2° 29' E  Paris fire department

9. Transition: I2 PSAPs won’t convert to VoIP overnight
Need to support services sooner
Rely on components used for Phase II wireless
Assumes voice service provider (VSP)
(Hopefully) more complicated than I3 solution…

10. I2 architecture (draft)
DBMS
IP domain
Emergency Services
Provider Network
Call server/
proxy server
PSTN
Routing Proxy &
Redirect
server(s )
MSAG E9 - 1
Selective
Router
VDB v6
ALI DB
ESGW(s ) v5 v4 v4 E9 - 1 - 1
ESZ
RDB
DHCP
Selective
PSAP
DNS v1
Router
LIS
IP Domain v2
User v2
VPC
Agent
VPC
SRDB
VPC v - e2 v0
ALI DB v8 v3 v7
location information
service
VoIP positioning center
routing database
validation database

11. Different perspectives
MSAG & routing data provided by (national-scale) database vendors
bottom-up: offered by PSAPs and jurisdictions
MSAG and routing data proprietary and not available to public
open data
specialized protocols for emergency services
avoid specialized protocols at all cost
specialized, dedicated emergency services networks
fortified networks, but with rich Internet connectivity
slow transition to I3 (decades)
if possible, make I2 period a matter of years or skip I2

12. I2 interfaces Participants Protocol(s) Description v0 v1 v2 v3 v4 v5
LIS to UA
DHCP
conveys location to endpoint v1
UA to CS
SIP (+ others)
recognize emergency call
transport location object v2
Proxy to VPC
XML query/response
location  ESRN, ESQK v3
VPC to LIS ?
VPC gets location from location key in signaling message v4
CS/routing proxy to ESGW
SIP
ESRN and ESGW inserted v5
CS to redirect server
Redirect server returns call routing information (ESRN, ESQK) in 3xx v6
CS to routing proxy v7
location validation
DNS, ?
LIS requests validation of address v8
VPC to ERDB
VPC sends LO, gets ESQK
ve-2
VPC to ALI-DB
E2+ (wireless)

13. I2 example (embedded LO)

14. Current IETF documents
draft-taylor-sipping-emerg-scen-01 (expired)
scenarios, e.g., hybrid VoIP-PSTN
draft-schulzrinne-sipping-emergency-req-01
abstract requirements and definitions
draft-schulzrinne-sipping-emergency-arch-02
overall architecture for emergency calling
draft-ietf-sipping-sos-00
describes ‘sos’ SIP URI
draft-rosen-dns-sos-01
new DNS resource records for location mapping
RFC 3825
“Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information”
draft-ietf-geopriv-dhcp-civil-04
DHCP option for civic addresses

15. Components sipd sipc SIP proxy server database-backed DNS server
SIP phone
web server
SQL database for call routing
sipc
SIP user agent
geo-coding, PSAP boundaries
GIS software for call location plotting
No endorsement implied – other components likely will work as well

16. I3 prototype
* gray features in progress.

17. Detail: I3 - DNS-based resolution
DHCP INFORM
psap.state.vt.gov
SIP w/location
MAC  loc
Perl sip-cgi script
psap.state.vt.gov
DNS NAPTR:
addison.vt.us
algonquin-dr.addison.vt.us …
proprietary
TCP-based
protocol
151.algonquin-dr.addison.vt.us.sos-arpa.net

18. Call taker setup SIPc client receives calls
GeoLynx software displays caller location

19. GeoLynx displays location
GeoLynx listens for commands from SIPc

20. Emergency call conferencing
PSAP brings all related
parties into a conference call
Hospital
Fire
department
REFER
INVITE
INVITE
Conference
server
REFER
INVITE
INVITE
media
info
Recorder
INVITE
3rd party
call control
REFER
INVITE
media
info
PSAP
Caller

21. Scaling
NENA: “estimated 200 million calls to in the U.S. each year”
 approximately 6.3 calls/second
if 3 minute call, about 1,200 concurrent calls
typical SIP proxy server (e.g., sipd) on 1 GHz PC can handle about 400 call arrivals/second
thus, unlikely to be server-bound

22. Conclusion 9-1-1 core enabling service for consumer-grade VoIP
Progress on defining I2 and I3
but fundamental architectural assumptions differ
I2-I3 transition likely to be gradual and in parts
Early prototypes are being demonstrated
IETF working group likely to be established soon