next-generation emergency calling (ng911) henning schulzrinne dept. of computer science, columbia...
TRANSCRIPT
Next-Generation Emergency Calling (NG911)
Henning SchulzrinneDept. of Computer Science, Columbia University, New York
[email protected](with Jong Yul Kim, Wonsang Song, Anshuman Rawat, Matthew Mintz-Habib, Amrita
Rajagopal and Xiaotao Wu; LoST is joint work with Hannes Tschofenig, Andrew Newton and Ted Hardie)
SIP Workshop
April 25, 2008
April 2008 2
Outline
• Emergency calling– the challenge of two transitions: mobility and VoIP– Emergency alerts
• Emergency alerting– beyond siren replacement
• Emergency coordination– going beyond ad hoc networks
emergency call coordinationalert
April 2008 3
Modes of emergency communications
emergency call
civic coordination
emergency alert(“inverse 911”)
dispatch
information“I-am-alive”
April 2008 4
Background on 9-1-1
• Established in Feb. 1968– 1970s: selective call routing– late 1990s: 93% of population/96% of area covered by 9-1-1– 95% of 9-1-1 is Enhanced 9-1-1– US and Canada
• Roughly 200 mio. calls a year (6 calls/second)– 1/3 wireless
• 6146 PSAPs in 3135 counties– most are small (2-6 call takers)– 83.1% of population have some Phase II (April 2007)
• “12-15 million households will be using VoIP as either primary or secondary line by end of 2008” (NENA)
http://www.nena.org/
April 2008 5
Local Switch
Automatic Number Identification
Automatic Location Identification
Collaboration between local phone providers and local public safety agencies
April 2008 6
Why is this a hard problem?
• More than just installing software and buying new PCs– mapping (GIS systems can’t use Google Maps)– training
• Decentralized system– 6000+ PSAPs– estimated cost of upgrade: $340m (=> $57,000/PSAP)
• 233 million US mobile phone subscribers
• Cost-plus ILEC MSAG– the MSAG update protocol: fax– no incentive to upgrade– no incentive to cooperate with CLECs and VSPs– unclear ownership of database
• Issues of control and “turf”– consolidation
• efficiency vs. local knowledge
– funding: state vs. county vs. town (volunteer fire department)
April 2008 7
What makes VoIP 112/911 hard?POTS PSTN-emulation VoIP end-to-end VoIP
(landline) phone number limited to limited area
landline phone number anywhere in US (cf. German 180)
no phone number or phone number anywhere around the world
regional carrier national or continent-wide carrier
enterprise “carrier” or anybody with a peer-to-peer device
voice provider = line provider (~ business relationship)
voice provider ≠ ISP voice provider ≠ ISP
national protocols and call routing
probably North America + EU
international protocols and routing
location = line location mostly residential or small business
stationary, nomadic, wireless
April 2008 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)
April 2008 9
Phase 1 Phase 2 Phase 3 Phase 4
Determine Location
Present Call to
Calltaker
Route to Correct PSAP
IdentifyEmergency
Calls
Four Phases of Emergency Calls
April 2008 10
Emergency numbers
• Each country and region has their own– subject to change
• Want to enable– traveler to use familiar home
number– good samaritan to pick up cell
phone
• Some 3/4-digit numbers are used for non-emergency purposes (e.g., directory assistance) Emergency number
April 2008 11
Service URN
• Idea: Identifiers to denote emergency calls– and other generic (communication) services
• Described in IETF ECRIT draft draft-ietf-ecrit-service-urn• Emergency service identifiers:
sos General emergency services sos.animal-control Animal control sos.fire Fire service sos.gas Gas leaks and gas emergencies sos.marine Maritime search and rescue sos.mountain Mountain rescue sos.physician Physician referral service sos.poison Poison control center sos.police Police, law enforcement
April 2008 12
Services under discussion
• “211” (social service referral), “311” (non-emergency government services)
• Emergency services (first responders)– used by PSAP, not civilians– e.g., urn:service:es:police
• Non-emergency commercial services– urn:service:restaurant.italian– urn:service:transportation.taxi
April 2008 13
Location, location, location, ...
Voice Service Provider (VSP)sees emergency call
but does not know caller location
ISP/IAP knows user locationbut does not handle call
April 2008 14
Location determination options
Method CDP or LLDP-MED
DHCP HELD GPS manual entry
Layer L2 L3 L7 (HTTP) - user
advantages • simple to implement
• built into switch• direct port/room
mapping
• simple to implement
• network locality
• traverses NATs
• can be operated by L2 provider
• accurate• mobile
devices• no carrier
cooperation
• no infrastructure changes
• no carrier cooperation
problems may be hard to automate for large enterprises
mapping MAC address to location?
mapping IP address to switch port?
• indoor coverage
• acquisition time
• fails for mobile devices
• unreliable for nomadic
Use Ethernet LANs Enterprise LANs
Some ISPs
DSL, cable mobile devices fall back
April 2008 15
Components of NG911 system
• Location determination• Call identification --> service URNs• Call routing --> LoST• PSAP functionality
– IVR, logging, multimedia conferencing, …
LoST(public)
LoST(private)
Internet
ESN
(county, state, …) PSAP
PSAP
April 2008 16
UA recognition & UA resolution
INVITE urn:service:sosTo: urn:service:sosRoute: sip:[email protected]
<location>
9-1-1(dial string)
mapping
INVITE urn:service:sosTo: urn:service:sosRoute: sip:[email protected]
<location>
leonianj.gov
mapping may recurse
location information
DHCPLLDP-MED
identification TBD
LoST: A Protocol for Mapping Geographic Locations to Public Safety Answering Points
Henning Schulzrinne, Hannes Tschofenig, Andrew Newton, Ted Hardie
April 2008 21
Problem: Finding the correct PSAP
• Which PSAP should the e-call go to?– Usually to the PSAP that serves the geographic area– Sometimes to a backup PSAP– If no location, then ‘default’ PSAP– solved by LoST
I am at "Otto -Hahn-Ring 6, 81739 München"
I need contact the ambulance . (Emergency Identifier)
MappingClient
MappingServer
Contact URI [email protected]
April 2008 22
LoST functionality
• Mapping of location to parameters (e.g., URL)• Civic as well as geospatial queries
– civic address validation
• Recursive and iterative resolution• Pre-querying and caching for efficiency and robustness
– query ahead of emergency call (e.g., at boot time for stationary devices)– no re-querying while moving
• Fully distributed and hierarchical deployment– can be split by any geographic or civic boundary– same civic region can span multiple LoST servers
• Indicates errors in civic location data debugging– but provides best-effort resolution
• Supports overlapping service regions– e.g., contested regions (Kashmir, Palestine, Taiwan, ...)
April 2008 23
LoST: Location-to-URL Mapping
clusterserves VSP2
NYUS
NJUS
Bergen CountyNJ US
123 Broad AveLeoniaBergen CountyNJ US
cluster serving VSP1
replicateroot information
searchreferral
rootnodes
LeoniaNJ US
VSP1
LoST
April 2008 24
LoST Architecture
T1
(.us)
T2
(.de) T3
(.dk)
G
G
GG
G broadcast (gossip)T1: .us
T2: .de
resolver
seeker313 Westview
Leonia, NJ US
Leonia, NJ sip:[email protected]
tree guide
April 2008 25
LoST Properties
• Minimizes round trips:– caching individual mappings– returns coverage regions (“hinting”)
• civic (“all of C=US, A1=NY”) or geo (polygon)
• Facilitates reuse of Transport Layer Security (TLS)
• Returns emergency service numbers for a region
• Query for supported Service URN types
April 2008 26
LoST: Query example
• Uses HTTP or HTTPS
<findService xmlns="urn:…:lost1”recursive="true" serviceBoundary="value">
<location profile="basic-civic"> <civicAddress> <country>Germany</country> <A1>Bavaria</A1> <A3>Munich</A3> <A6>Neu Perlach</A6> <HNO>96</HNO> </civicAddress> </location> <service>urn:service:sos.police</service></findService>
April 2008 27
LoST “Find Service” response/warning example
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"> <mapping expires=“1990-12-31T23:59:60Z” lastUpdated=“2006-11-01T01:00:00Z”> <displayName xml:lang="de">München Polizei-Abteilung</displayName> <service>urn:service:sos.police</service> <serviceBoundary profile=”civic”> <civicAddress xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> <country>Germany</country> <A1>Bavaria</A1><A3>Munich</A3><PC>81675</PC> </civicAddress> </serviceBoundary> <uri>sip:[email protected]</uri> <serviceNumber>110</serviceNumber> </mapping> <path> <via source=“lost:esgw.uber-110.de.example”/> <via source=“lost:polizei.munchen.de.example”> </path></findServiceResponse>
April 2008 28
Validation
• Determine if civic location is (partially) valid• Returns XML tag names of components:
– validated and used for mapping– no attempt to validate (and not used)
• e.g., house number
– known to be invalid
• Return (default) PSAP based on validated elements• May return list of guesses for correct addresses, if
requested
<locationValidation> <valid>country A1 A3 A6</valid> <invalid>PC</invalid></locationValidation>
April 2008 29
Advanced LoST functionality
• Get list of (emergency) services supported– by server– for a region
• Obtain service regions– identified by globally-unique tag
<listServicesByLocation> <location profile="geodetic-2d"> <p2:Point srsName="urn:4326"> <p2:pos>-34.407 150.883</p2:pos> </p2:Point> </location><service>urn:service:sos</service></listServicesByLocation>
<listServicesByLocationResponse> <serviceList> urn:service:sos.ambulance urn:service:sos.animal-control </serviceList> <path> <via source="auth.example"/> <via source="res.example"/> </path></listServicesByLocationResponse>
April 2008 30
INVITE urn:service:sos SIP/2.0
To: urn:service:sosCall-ID: [email protected]: SIP/2.0/TCP 192.168.1.106:4064;rportContent-Type: multipart/mixed; boundaryFrom: sip:[email protected]: <sip:[email protected]:5060>CSeq: 1 INVITEContent-Length: 1379
------ =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY=MIME-Version: 1.0content-Type: application/sdpContent-Transfer-Encoding: 8bit
v=0o=eddie 1127764654 1127764654 IN IP4 192.168.1.106s=SIPC Callc=IN IP4 160.39.54.70t=0 0m=audio 10000 RTP/AVP 0 3m=video 20000 RTP 31
SDP
header fields
request line ------- =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY=MIME-Version: 1.0Content-Type: application/pidf+xmlContent-Transfer-Encoding: 8bit
<?xml version="1.0" encoding="ISO-8859-1"?><presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc" xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0" entity="sip:[email protected]"> <tuple id="28185"> <status> <gp:geopriv> <gp:location-info> <cl:civilAddress> <cl:country>us</cl:country> <cl:A1>ny</cl:A1> <cl:A2>new york</cl:A2> <cl:A3>new york</cl:A3> <cl:A6>amsterdam</cl:A6> <cl:HNO>1214</cl:HNO> </cl:civilAddress> </gp:location-info> <gp:method>Manual</gp:method> </gp:geopriv> </status> <contact priority="0.8">sip:[email protected]:5060</contact> <timestamp>2005-09-26T15:57:34-04:00</timestamp> </tuple></presence>------- =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY=--
PIDF-LO
SIP message for Location Info.
April 2008 31
Using LoST for non-emergency services
• Emergency services: “who serves location X”– one answer desired
• Non-emergency services: “what services are within radius R of location X”– restaurants, banks, ATMs, hospitals
• Can use LoST with minor extensions:– shapes allow queries like “show restaurants within Prague city
limits” (polygon) or “within 5 miles of where I am” (circle)– restrict number of responses– allow multiple responses
April 2008 32
Current activities
• IETF ECRIT working group– finishing LoST, architecture, synchronization
• NENA– architecture
– transition documents
– web services for queries
• DOT– NG911 project with BAH, Columbia & TAMU as sub-contractor
– building proof-of-concept, based on earlier NTIA work
– “National architecture for NG9-1-1 system” & “Transition plan for NG9-1-1 implementation”
• Lots of other activities– e.g., semi-annual Emergency Services Coordination Workshop
April 2008 33
NG9-1-1 Prototype Architecture
911112
sip:psap@domain2w/location
POTS/Wireless Network
SIP UA
911
sip:psap@domain2with location
GeoLynx /Google Maps
DHCP Server
PSAP Info
Location
LoST Cluster
geo locationcivil location
psapd
3PCC Cont r ol l er
I P Gat eway
Local SI P Pr oxy
PSAP
PSAP SI P Pr oxy
si p: psap@domai n2wi t h l ocat i on
si p: r ep@domai n2wi t h l ocat i on
ur n: ser vi ce: sosw/ out l ocat i on
LI S
Locat i on I nf oLocat i on
key
GPS
Locat i on I nf o
Conference Server
RoutingLocation
PSTN
April 2008 34
LoST Cluster
SIP proxy
call taker
SOS caller
(1) Location
Location + Service Identifier
(2)
INVITE PSAP URLTo: urn:service:sos
<Location>
(5)
INVITE PSAP URLTo: urn:service:sos
<Location>
(6)
(4)
dial emergency dial-string
or
push emergency button
Emergency Call Flow
(3)
PSAP URL + emergency dial-string
INVITE call takerFrom: caller<Location>(7)
Media Stream Media Stream
April 2008 35
Calltaker screen
• Columbia SIPc as SIP UA
• Mapping software to display caller’s location– Geolynx– Google Maps
April 2008 37
NG911 trial: Lessons learned
• Tested NG911 prototype in 3 PSAPs in TX and VA• Surprise: PSAP is really a conferencing system
– LanguageLine, first responders, …
• Surprise: no uniform incident description– every jurisdiction uses their own variation and level of detail
• What is desirable behavior– rather than current behavior– e.g., for transfer, overflow
• Need to integrate call taker management– presence (availability)– a specialized call center
• Special requirements: partial mute– not typically supported on conference servers
April 2008 38
Conclusion
• Need for loosely-coupled suite of tools for emergency coordination– connecting rather than stovepipe systems– narrow interfaces rather than global master architecture
• NG911 as opportunity to update emergency calling– robustness– features (multimedia, connectivity)– COTS
• Need for large-scale experiments, not yet another ad-hoc network paper– cooperation with non-technical users
April 2008 39
More information
• A VoIP Emergency Services Architecture and Prototype– M. Mintz-Habib, A. Rawat, H. Schulzrinne, and X. Wu, ICCCN 2005, Oct. 2005
• An Enhanced VoIP Emergency Services Prototype– Jong Yul Kim, Wonsang Song, and Henning Schulzrinne, ISCRAM 2006, May 2006
• Providing emergency services in Internet telephony– H. Schulzrinne & K. Arabshian, IEEE Internet Computing, May/June 2002
• Requirements for Emergency Context Resolution with Internet Technologies, draft-ietf-ecrit-requirements
• Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information, RFC 4776
• Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information, RFC 3825
• A Presence-based GEOPRIV Location Object Format, RFC 4119• A Uniform Resource Name (URN) for Services, draft-ietf-ecrit-service-urn• LoST: A Location-to-Service Translation Protocol, draft-ietf-ecrit-lost• Best current practices for third party call control (3pcc) in the session initiation protocol (SIP),
RFC 3725• GETS: http://gets.ncs.gov/
• LoST server at http://honamsun.cs.columbia.edu/lost_homepage/
• NG911 project information at http://ng911.tamu.edu and DOT 911 project