Transcript Emergency Calling for VoIP Internet Real-Time Lab, Columbia University

Emergency Calling for VoIP
Wonsang Song, Jong Yul Kim,
and Henning Schulzrinne
Internet Real-Time Lab,
Columbia University
Overview
•
•
•
•
Project introduction
Architecture and implementation
References
Demo
3/28/2006
2/23
Introduction
• Emergency call is necessary for voice service.
– People expect to reach PSAP when dials 911.
– Many people use VoIP as primary telephone.
• Traditional 9-1-1 system does not work well with VoIP
– Identity = Line number, Location = billing address
– Covering limited area
– National protocols and routing
• Three (related) fundamental problems
– Where is the caller?
– To which PSAP should the call go to?
– How to identify the emergency call?
3/28/2006
3/23
Project Goals
• Develop a prototype system that routes emergency calls over
SIP based VoIP networks.
• Implement requirements for IP-based PSAP
• Provide opportunities to enhance 911 system:
–
–
–
–
–
3/28/2006
Multimedia (audio, video, text)
Data delivery (floor plan, medical information)
Delivering video (CPR how-to)
Load balancing and redundancy
Location delivery (location with forwarded, transferred calls)
4/23
Four Phases of Emergency Calls
Phase 1
Phase 2
Phase 3
Determine
Location
Identify
Emergency
Calls
Route to
Correct
PSAP
3/28/2006
Phase 4
Present
Call to
Calltaker
5/23
System Components
phase1
phase1
phase2
phase3
phase3
LIS DHCP Server
Location
key
Location
Info
phase4
Mapping Server
Location
PSAP
Info
PSAP
civil location
geo location
sip:psap@domain2
w/location
911
112
sip:psap@domain2
with location
SIP UA
PSAP SIP Proxy
urn:service:sos
w/out location
Local SIP Proxy
civil location
geo location
sip:psap@domain2
with location
sip:rep@domain2
with location
911
POTS/Wireless
Network
3/28/2006
IP Gateway
psapd
3PCC Controller
GeoLynx /
Google Maps
6/23
Phase1: Determining Location
• Purpose
– To get the visited emergency dial strings (Phase2)
– To resolve the correct PSAP URL (Phase3)
– To present the caller’s location on the call taker’s screen using
mapping software (Phase4)
• Solution
– UA can be stationary, nomadic or mobile -> apply different
methods
– GPS, CDP (LLDP-MED), DHCP and Manual Entry
– The result location information is either civic address or
geospatial coordinates.
– The location information will be included in the INVITE request
as PIDF-LO.
3/28/2006
7/23
DHCP for Location
•
•
modified ISC’s dhcpd to generate location information
use MAC address back-tracing to get location information
DHCPINFORM
[MAC=00:11:20:9d:a0:03]
request
or
response
DHCPACK
[option=0:US:1:NY:2:NEW YORK:
3:NEW YORK:6:AMSTERDAM:19:1214]
3/28/2006
DHCP Server
8/23
CDP for Location
•
•
•
Cisco Discovery Protocol (Layer2)
Cisco switches broadcast switch/port ID periodically.
A Switch covers a floor, a port leads to a jack in a room
-> room-level accuracy
Switch 2
Path of CDP
advertisement
Segment from
switch 2/port 5
Physical
location
Invoke
cdpCap
cdpCap listens to
advertisements
Switch/port
Location DB
3/28/2006
SIP UA
Send switch/port
information
9/23
SIP message for Location Info.
INVITE urn:service:sos SIP/2.0
To: urn:service:sos
Call-ID: [email protected]
Via: SIP/2.0/TCP 192.168.1.106:4064;rport
Content-Type: multipart/mixed; boundary
From: sip:[email protected]
Contact: <sip:[email protected]:5060>
CSeq: 1 INVITE
Content-Length: 1379
request line
header fields
------ =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY=
MIME-Version: 1.0
content-Type: application/sdp
Content-Transfer-Encoding: 8bit
v=0
o=eddie 1127764654 1127764654 IN IP4 192.168.1.106
s=SIPC Call
c=IN IP4 160.39.54.70
t=0 0
m=audio 10000 RTP/AVP 0 3
m=video 20000 RTP 31
SDP
------- =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY=
MIME-Version: 1.0
Content-Type: application/pidf+xml
Content-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
3/28/2006
10/23
Phase2: Identifying SOS
•
Purpose
– For UA : To send caller’s location information
– For Proxies: To handle the emergency call specially
•
Emergency Identifier (Emergency Service URN)
– Service URN: identifies a generic service, not a specific resource
– For emergency:
•
•
•
•
•
urn:service:sos
urn:service:sos.ambulance
urn:service:sos.fire
urn:service:sos.police
…
– Can be used in request URI and To header.
– Will be resolved into PSAP URL using mapping service (phase3)
3/28/2006
11/23
Emergency Dial Strings
•
Different emergency dial strings
–
–
•
Required to support both home and visited emergency dial strings
–
•
User can set his/her home country through configuration.
In initial time, UA gets the home emergency dial strings using mapping protocols.
For the visited emergency dial strings:
–
•
e.g., for an American traveler who is visiting Europe, both 911 and 112 should be
recognized as emergency
For the home emergency dial strings:
–
–
•
different in countries (e.g., 911 for North America, 112 for Europe)
some countries uses separate numbers for ambulance/police/fire
Whenever current location is changed, UA gets the visited emergency dial strings using
mapping protocols.
UA keeps all emergency dial strings in the local dial plans
e.g., [911 -> urn:service:sos]
3/28/2006
12/23
Phase3: Routing to Correct PSAP
•
Which PSAP should the call go to?
–
–
–
•
Usually to the PSAP that covers the area
Sometimes to a backup PSAP
If no location, then ‘default’ PSAP
PSAP determination
–
mapping problem:
Caller’s location
+
Service identifier
Service provider
(PSAP URL)
(urn:service:sos)
–
Works in progress for standardization
•
3/28/2006
LoST: A Location-to-Service Translation Protocol
13/23
LoST (Location-to-Service Translation)
•
•
For mapping a service identifier and location information to {PSAP URL &
emergency dial-string}
Supports both civic and geo location information
Uses web service (SOAP base) as underlying protocol
3/28/2006
response
<mapping>
<request>
<operation>recurse</operation>
<service>urn:service:sos</service>
<gp:location-info>
<cl:civicAddress>
<cl:country>US</cl:country>
<cl:A1>NY</cl:A1>
<cl:A3>New York</cl:A3>
<cl:A6>Amsterdam</cl:A6>
<cl:HNO>1214</cl:HNO>
</cl:civicAddress>
</gp:location-info>
</request>
</mapping>
request
•
LoST Server
<mapping>
<response expires="2006-03-09T01:53:33.396Z">
<service>urn:service:sos</service>
<displayName>New York City PSAP</displayName>
<uri>sip:[email protected]</uri>
<civicMatch>
<gp:location-info>
<cl:civicAddress>
<cl:country>US</cl:country>
<cl:A1>NY</cl:A1>
<cl:A3>New York</cl:A3>
<cl:A6>Amsterdam</cl:A6>
<cl:HNO>1214</cl:HNO>
</cl:civicAddress>
</gp:location-info>
</civicMatch>
<dialstring>911</dialstring>
</response>
</mapping>
14/23
Phase4: Call Presentation in PSAP
Hospital
Police
Fire
(8)
join
conference
(5)
join
conference
(6)
Conference Mixer
Call Taker 1
REFER police
to conference
(7)
INVITE to
conference
Policy
(4)
INVITE to
conference
Call Taker 2
(3)
(2) select available create
call taker
conference
(1) psap@domain
w/location
Controller (psapd)
3/28/2006
Call Taker n
15/23
Calltaker’s Screen
• SIPc as SIP UA
• Mapping software to display caller’s location
– Geolynx
– Google Maps
3/28/2006
16/23
Web Interface
• Manage PSAP systems
• Show call logs, details, incident information
and statistics
3/28/2006
17/23
Scenario 1: Normal Case
(UA recognition, UA resolution)
(2)
Location +
Service Identifier
Mapping Server
(1) Location
(3)
PSAP URL +
emergency
dial-string
(4)
SOS caller
dial emergency dialstring
(5)
INVITE PSAP URL
To: urn:service:sos
<Location>
or
SIP proxy
(6)
INVITE PSAP URL
To: urn:service:sos
call taker
<Location>
push emergency button
3/28/2006
18/23
Scenario 2: No Location from UA
(UA recognition, Proxy resolution)
DHCP Server
(4)
Mapping Server
(5)
PSAP URL
Location +
Service Identifier
(3) Location
(1)
dial 911
SOS caller
(2)
INVITE urn:service:sos
To: urn:service:sos
SIP proxy
(6)
INVITE PSAP URL
To: urn:service:sos
call taker
or
push emergency button
3/28/2006
<Location>
19/23
Scenario 3: Backward Compatible
(Proxy recognition, Proxy resolution)
DHCP Server
(4)
Mapping Server
(5)
PSAP URL
Location +
Service Identifier
(3) Location
(1)
dial 911
(2)
SOS
caller
INVITE sip:911@domain
To: sip:911@domain
SIP proxy
(6)
INVITE PSAP URL
To: urn:service:sos
call taker
<Location>
3/28/2006
20/23
References
•
•
•
•
•
•
•
•
SIP: Session initiation protocol, RFC 3261
Requirements for Emergency Context Resolution with Internet
Technologies, draft-ietf-ecrit-requirements-04
Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for
Civic Addresses Configuration Information, draft-ietf-geopriv-dhcp-civil-07
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-urn01
LoST: A Location-to-Service Translation Protocol, draft-hardie-ecrit-lost-00
Best current practices for third party call control (3pcc) in the session
initiation protocol (SIP), RFC 3725
3/28/2006
21/23
Demo
3/28/2006
22/23