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: 763782461@192.168.1.106Via: SIP/2.0/TCP 192.168.1.106:4064;rportContent-Type: multipart/mixed; boundaryFrom: sip:caller@irt.cs.columbia.eduContact: <sip:eddie@160.39.54.70: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:calltaker_ny2@irt.cs.columbia.edu"> <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:eddie@160.39.54.70: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:psap_ny@irt.cs.columbia.edu</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