Upload
madonna-holman
View
45
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Emergency Calling for VoIP. Wonsang Song, Jong Yul Kim, and Henning Schulzrinne. Overview. Project introduction Architecture and implementation References Demo. Introduction. Emergency call is necessary for voice service. People expect to reach PSAP when dials 911. - PowerPoint PPT Presentation
Citation preview
Internet Real-Time Lab, Columbia University
Emergency Calling for VoIP
Wonsang Song, Jong Yul Kim,
and Henning Schulzrinne
3/28/2006
2/23
• Project introduction
• Architecture and implementation
• References
• Demo
Overview
3/28/2006
3/23
• 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?
Introduction
3/28/2006
4/23
• 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:– 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)
Project Goals
3/28/2006
5/23
Phase 1 Phase 2 Phase 3 Phase 4
Determine Location
Present Call to
Calltaker
Route to Correct PSAP
IdentifyEmergencyCalls
Four Phases of Emergency Calls
3/28/2006
6/23
911112
sip:psap@domain2w/location
geo location
POTS/Wireless Network
SIP UA
911
sip:psap@domain2with location
GeoLynx /Google Maps
DHCP Server
civil location
PSAP Info
Location
Mapping Server
geo locationcivil location
psapd
3PCC Controller
IP Gateway
Local SIP Proxy
PSAP
PSAP SIP Proxy
sip:psap@domain2with location
sip:rep@domain2with location
urn:service:sosw/out location
LIS
Location InfoLocation
key
phase1
phase2
phase3 phase4phase3
phase1
System Components
3/28/2006
7/23
• 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.
Phase1: Determining Location
3/28/2006
8/23
DHCP for Location
• modified ISC’s dhcpd to generate location information• use MAC address back-tracing to get location information
DHCP Server
or
request
response
DHCPINFORM[MAC=00:11:20:9d:a0:03]
DHCPACK[option=0:US:1:NY:2:NEW YORK:3:NEW YORK:6:AMSTERDAM:19:1214]
3/28/2006
9/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
Segment from switch 2/port 5
Switch 2
Path of CDP advertisement
SIP UA
InvokecdpCap
cdpCap listens to advertisements
Send switch/port information
Physical location
Switch/port
Location DB
3/28/2006
10/23
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.
3/28/2006
11/23
• 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)
Phase2: Identifying SOS
3/28/2006
12/23
• Different emergency dial strings– different in countries (e.g., 911 for North America, 112 for Europe)– some countries uses separate numbers for ambulance/police/fire
• Required to support both home and 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:– 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:– 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 planse.g., [911 -> urn:service:sos]
Emergency Dial Strings
3/28/2006
13/23
• 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:
– Works in progress for standardization• LoST: A Location-to-Service Translation Protocol
Caller’s location
Service identifier
(urn:service:sos)
+Service provider
(PSAP URL)
Phase3: Routing to Correct PSAP
3/28/2006
14/23
• 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
LoST Server
req
ues
tresp
on
se
LoST (Location-to-Service Translation)
<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>
<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>
3/28/2006
15/23
Call Taker 1
Call Taker 2
Call Taker n
Hospital Police Fire
Controller (psapd)
Policy
Conference Mixer
select available call taker
(2) create conference
(3) INVITE to conference
(4)
(5) join conference
INVITE to conference
(7)
join conference
(8)
(1) psap@domain w/location
(6)
REFER police to conference
Phase4: Call Presentation in PSAP
3/28/2006
16/23
Calltaker’s Screen
• SIPc as SIP UA• Mapping software to display caller’s location
– Geolynx
– Google Maps
3/28/2006
17/23
Web Interface
• Manage PSAP systems• Show call logs, details, incident information
and statistics
3/28/2006
18/23
Mapping Server
SIP proxy call takerSOS caller
(1) Location
Location + Service Identifier
(2)
PSAP URL + emergency dial-string
(3)
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
Scenario 1: Normal Case(UA recognition, UA resolution)
3/28/2006
19/23
Mapping Server
SIP proxy call takerSOS caller
(3) Location
Location + Service Identifier
(4)
PSAP URL
(5)
INVITE urn:service:sosTo: urn:service:sos(2)
INVITE PSAP URLTo: urn:service:sos
<Location>
(6)(1)
dial 911
or
push emergency button
DHCP Server
Scenario 2: No Location from UA(UA recognition, Proxy resolution)
3/28/2006
20/23
Mapping Server
SIP proxy call takerSOS caller
(3) Location
Location + Service Identifier
(4)
PSAP URL
(5)
INVITE sip:911@domainTo: sip:911@domain
(2) INVITE PSAP URLTo: urn:service:sos
<Location>
(6)(1)
dial 911
DHCP Server
Scenario 3: Backward Compatible(Proxy recognition, Proxy resolution)
3/28/2006
21/23
• 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-urn-
01• 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
References
3/28/2006
22/23
Demo