Emergency Calling in SIP

1
Emergency Calling in SIP

• Henning Schulzrinne
• (with Anshuman Rawat, Matthew Mintz-Habib and
  Xiaotao Wu)
• Dept. of Computer Science
• Columbia University
• hgs_at_cs.columbia.edu

2
Overview

• VoIP emergency communications
• What makes emergency calling hard?
• Stages of deployment
• I1 quick fixes
• I2 backward-compatible
• I3 end-to-end IP
• Initial prototype
• NENA IETF efforts

3
VoIP emergency communications
emergency call
dispatch
emergency alert (inverse 911)
civic coordination
4
Current wireline calls
dial 911, 112
route call to right PSAP
map ANI to civic location
(Brian Rosen)
5
Wireless (Phase II) Calls
(Brian Rosen)
6
Components of emergency calling
now
transition
all IP
Contact well-known number or identifier
112 911
112 911
dial 112, 911 signal sos_at_
Route call to location-appropriate PSAP
selective router
VPC
DNS
Deliver precise location to call taker to
dispatch emergency help
phone number ? location (ALI lookup)
in-band ? key ? location
in-band
7
What makes VoIP 112/911 hard?
8
More than pain

• Multimedia from the caller
• video capture from cell phones
• video for sign language
• text messaging and real-time text for the deaf
• Data delivery
• caller data floor plan, hazmat data, medical
  alerts
• measurement data input automobile crash data,
  EKGs,
• Delivering video to the caller
• e.g., CPR training
• Load balancing and redundancy
• currently only limited secondary PSAP
• VoIP can transfer overload calls anywhere
• Location delivery
• carry location with forwarded and transferred
  calls
• multiple location objects (civic geo)

9
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

10
Staged deployment

• 6,134 PSAPs in North America
• average 2-3 active call takers each
• some serve town, some large parts of a state
• only 30 of PSAPs can receive geo coordinates
• 30-40 may be voice only
• many using 1970s telecom technology
• CAMA (operator) trunks
• limited to delivering 8 (regional) or 10 digits
  (national) of information
• already facing pressure from supporting cellular
  services
• Phase I (cell tower and face) and Phase II
  (caller geo location)
• EU smaller number of PSAPs, but often without
  location delivery
• Initial version (I1)
• dial 10-digit administrative number
• like telematics services
• does not deliver caller location to PSAP

11
Three stages to VoIP 911
12
I1.5 Level 3 ESGW solution

• uses Level 3 as CLEC to feed ALI information to
  local ILEC
• requires emergency services GW for each tandem
• only works for non-ported numbers
• does not work for mobile users

13
I1.5 Global Crossing VoIP 911 transport
14
I2 architecture (draft)
Routing Proxy
Redirect
server(s
)
v6
v4
v5
E9
-
1
-
1
v4
PSAP
Selective
Router
v1
IP Domain
v2
User
v2
Agent
v
-
e2
v0
v8
v3
location information service
v7
VoIP positioning center
validation database
routing database
15
I2 interfaces
16
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
17
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 (MAC ? switch port ? location
  database)
• on LAN via LLDP (802.1ab, TIA LLDP-MED)
• initially, often through manual configuration
• Route calls to right destination
• using look-up in device or proxy

18
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, )

19
Columbia/MapInfo prototype

• Goal build prototype VoIP SIP-based emergency
  calling system
• including caller end system
• call routing (DNS)
• PSAP infrastructure
• Use commodity components where possible
• Test reliability and redundancy

20
Components
No endorsement implied other components likely
will work as well
21
Call routing
22
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
23
3rd party call control
24
3rd Party Call Control Flow
25
Call taker setup
SIPc client receives calls
GeoLynx software displays caller location
26
GeoLynx displays location
GeoLynx listens for commands from SIPc
27
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
28
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

29
Current standardization efforts

• NENA (National Emergency Number Association)
• I2 and I3 architecture
• requirements based on operational needs of PSAPs
• ETSI OCG EMTEL
• exploratory also emergency notification
• NRIC
• goals and long-term architecture
• IETF
• individual and SIPPING drafts for identifier,
  call routing, architecture
• SIP and DNS usage
• possibly new protocols for lookups
• ECRIT BOF (pre-WG) at IETF-61 in Washington, DC

30
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

31
Conclusion

• Emergency calling services necessary condition
  for first-line wireline-replacement services
• US large numbers of PSAPs financially exhausted
  from Phase II wireless support
• often 1970s technology end of bailing wire
  reached
• Long-term opportunity for better services