1. Internet Real-Time Lab, Columbia University Emergency Calling for VoIP Wonsang Song, Jong Yul Kim, and Henning Schulzrinne

2. 3/28/20062/23 Project introduction Architecture and implementation References Demo Overview

3. 3/28/20063/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

4. 3/28/20064/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

5. 3/28/20065/23 Phase 1Phase 2Phase 3 Phase 4 Four Phases of Emergency Calls

6. 3/28/20066/23 phase1 phase2 phase3phase4phase3 phase1 System Components

7. 3/28/20067/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

8. 3/28/20068/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]

9. 3/28/20069/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

10. 3/28/200610/23 INVITE urn:service:sos SIP/2.0 To: urn:service:sos Call-ID: 763782461@192.168.1.106 Via: SIP/2.0/TCP 192.168.1.106:4064;rport Content-Type: multipart/mixed; boundary From: sip:caller@irt.cs.columbia.edu Contact: CSeq: 1 INVITE Content-Length: 1379 ------ =_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 header fields request line ------- =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY= MIME-Version: 1.0 Content-Type: application/pidf+xml Content-Transfer-Encoding: 8bit <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:calltaker_ny2@irt.cs.columbia.edu"> us ny new york amsterdam 1214 Manual sip:eddie@160.39.54.70:5060 2005-09-26T15:57:34-04:00 ------- =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY=-- PIDF-LO SIP message for Location Info.

11. 3/28/200611/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

12. 3/28/200612/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 plans e.g., [911 -> urn:service:sos] Emergency Dial Strings

13. 3/28/200613/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

14. 3/28/200614/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 request response LoST (Location-to-Service Translation) recurse urn:service:sos US NY New York Amsterdam 1214 urn:service:sos New York City PSAP sip:psap_ny@irt.cs.columbia.edu US NY New York Amsterdam 1214 911

15. 3/28/200615/23 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

16. 3/28/200616/23 Calltaker’s Screen SIPc as SIP UA Mapping software to display caller’s location –Geolynx –Google Maps

17. 3/28/200617/23 Web Interface Manage PSAP systems Show call logs, details, incident information and statistics

18. 3/28/200618/23 Mapping Server SIP proxy call taker SOS caller (1)Location Location + Service Identifier (2) PSAP URL + emergency dial-string (3) INVITE PSAP URL To: urn:service:sos (5) INVITE PSAP URL To: urn:service:sos (6)(4) dial emergency dial- string or push emergency button Scenario 1: Normal Case (UA recognition, UA resolution)

19. 3/28/200619/23 Mapping Server SIP proxy call taker SOS caller (3)Location Location + Service Identifier (4) PSAP URL (5) INVITE urn:service:sos To: urn:service:sos (2) INVITE PSAP URL To: urn:service:sos (6) (1) dial 911 or push emergency button DHCP Server Scenario 2: No Location from UA (UA recognition, Proxy resolution)

20. 3/28/200620/23 Mapping Server SIP proxy call taker SOS caller (3)Location Location + Service Identifier (4) PSAP URL (5) INVITE sip:911@domain To: sip:911@domain (2) INVITE PSAP URL To: urn:service:sos (6) (1) dial 911 DHCP Server Scenario 3: Backward Compatible (Proxy recognition, Proxy resolution)

21. 3/28/200621/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

22. 3/28/200622/23 Demo