Emergency Calling in SIP

1
Emergency Calling in SIP

• Henning Schulzrinne
• (with Anshuman Rawat, Matthew Mintz-Habib, Amrita
  Rajagopal 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
The core problem
VSP sees emergency call but does not know caller
location
ISP/IAP knows user location but does not handle
call
9
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)

10
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

11
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

12
Three stages to VoIP 911
13
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
14
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
15
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

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

17
Options for location delivery

• L2 LLDP-MED (standardized version of CDP
  location data)
• periodic per-port broadcast of configuration
  information
• L3 DHCP for
• geospatial (RFC 3825)
• civic (draft-ietf-geopriv-dhcp-civil)
• L7 proposals for retrievals
• by IP address
• by MAC address
• by identifier (conveyed by DHCP or PPP)

18
DHCP for locations

• modified dhcpd (ISC) to generate location
  information
• use MAC address backtracing to get location
  information

8020abd5d
DHCP server
CDP SNMP 8020abd5d ? 458/17
DHCP answer staDC locRm815 lat38.89868
long77.03723
458/17 ? Rm. 815 458/18 ? Rm. 816
19
Location-related problems

• Delivery
• How does call or end system get location
  information?
• Validation
• Does the civic address exist and does it have an
  associated PSAP?
• MSAG validation
• Verification
• Is this the real address of the user (rather than
  an attempt to mislead)?
• Privacy
• Avoid revealing location information to third
  parties
• Avoid location disclosure outside an emergency
  call

20
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

21
Components
No endorsement implied other components likely
will work as well
22
Call routing
23
Call routing proposals

• DNS
• map civic to label hierarchy
• drill-down search for geo
• IRIS
• whois-like lookup protocol (registry)
• LUMP
• uses SOAP (web services)
• architecture for reliability
• no root server P2P among entry nodes

24
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
25
IRIS-based resolution
ltrequest xmlns"urnietfparamsxmlnsiris1"gt
ltsearchSetgt ltfindEconByCivic xmlns"urnietf"gt
ltcivilAddressgt ltcountrygtUSlt/countrygt
ltA1gtNew Yorklt/A1gt ltA3gtNew Yorklt/A3gt
ltA6gtBroadwaylt/A6gt lt/civilAddressgt
ltservicegtpolicelt/servicegt lt/findEconByCivicgt lt/sea
rchSetgt lt/requestgt

• IRIS modern whois search protocol, over BEEP
• only specifies query, not update

ltresponse xmlns"urnietfparamsxmlnsiris1"gt ltr
esultSetgt ltanswergt ltemergencyContact
xmlns"urnietf authority"nyc.example
registryType"econ1 entityClass"econ"
entityName"nypd"gt ltdisplayNamegtNYPDlt/displayN
amegt lturigtsip//nypd.example/lt/urigt
lt/emergencyContactgt lt/answergt lt/resultSetgt lt/res
ponsegt
26
LUMP Location-to-URL Mapping
VSP1
cluster serving VSP1
replicate root information
cluster serves VSP2
123 Broad Ave Leonia Bergen County NJ US
root nodes
NY US
NJ US
sippsap_at_leonianj.gov
search referral
Bergen County NJ US
Leonia NJ US
27
3rd party call control
28
3rd Party Call Control Flow
29
Call taker setup
SIPc client receives calls
GeoLynx software displays caller location
30
GeoLynx displays location
GeoLynx listens for commands from SIPc
31
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
32
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

33
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 WG for mapping part just getting started

34
Current IETF documents

• draft-taylor-sipping-emerg-scen-01 (expired)
• scenarios, e.g., hybrid VoIP-PSTN
• draft-schulzrinne-sipping-emergency-req
• abstract requirements and definitions
• draft-schulzrinne-sipping-emergency-arch
• overall architecture for emergency calling

• draft-ietf-sipping-sos
• describes sos SIP URI
• draft-rosen-dns-sos
• new DNS resource records for location mapping
• draft-hardie-ecrit-iris
• uses IRIS for lookup
• RFC 3825
• Dynamic Host Configuration Protocol Option for
  Coordinate-based Location Configuration
  Information
• draft-ietf-geopriv-dhcp-civil-06
• DHCP option for civic addresses

35
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

36
I2 interfaces
37
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

38
I1.5 Global Crossing VoIP 911 transport