Emergency Calling for VoIP: A Progress Report

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
6
Location, location, location

• Location ? locate right PSAP speed dispatch
• In the PSTN, local 9-1-1 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 doesnt have
  wire database information
• VSP needs assistance from access provider (DSL,
  cable, WiMax, 802.11, )

7
I3 (long-term) architecture components

• Common URL for emergency calls
• sipssos_at_home-domain
• 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 sipssos_at_
48 49' N 2 29' E
outbound proxy server
DHCP
48 49' N 2 29' E ? Paris fire department
9
Transition I2

• PSAPs wont convert to VoIP overnight
• Need to support 9-1-1 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)
Routing Proxy
Redirect
server(s
)
v6
v4
v5
v4
E9
-
1
-
1
PSAP
Selective
Router
v1
IP Domain
v2
User
v2
Agent
v
-
e2
v0
v8
v3
v7
location information service
VoIP positioning center
validation database
routing database
11
Different perspectives
12
I2 interfaces
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
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.u
s
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
INVITE
Conference server
Recorder
3rd party call control
PSAP
Caller
21
Scaling

• NENA estimated 200 million calls to 9-1-1 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