An Architecture for Next-Generation Emergency Services

1
An Architecture for Next-Generation Emergency
Services

• Henning Schulzrinne
• Columbia University

2
Overview

• How does VoIP differ from landline and wireless
  PSTN?
• Getting from here to there I1, I2 and I3
• IETF efforts
• status
• assumptions
• Common URL for emergency services
• Routing emergency calls
• Common location format
• Configuration of local emergency call numbers
• Security issues

3
PSTN vs. Internet Telephony
PSTN
Signaling Media
Signaling Media
China
Internet telephony
Signaling
Signaling
Media
Australia
Belgian customer, currently visiting US
4
SIP trapezoid
destination proxy (identified by SIP URI domain)
outbound proxy
1st request
SIP trapezoid
2nd, 3rd, request
a_at_foo.com 128.59.16.1
registrar
voice traffic RTP
5
SIP addressing

• Users identified by SIP or tel URIs
• sipalice_at_example.com
• tel URIs describe E.164 number, not dialed
  digits (RFC 2806bis)
• tel URIs ? SIP URIs by outbound proxy
• A person can have any number of SIP URIs
• The same SIP URI can reach many different phones,
  in different networks
• sequential parallel forking
• SIP URIs can be created dynamically
• GRUUs
• conferences
• device identifiers (sipfoo_at_128.59.16.15)
• Registration binds SIP URIs (e.g., device
  addresses) to SIP address-of-record (AOR)

tel110
sipsos_at_domain
domain ? 128.59.16.17 via NAPTR SRV
6
How does VoIP differ from landline and wireless
PSTN?
voice service provider (RTP, SIP)

• Telephone companies are no longer needed
• there are still carriers for DSL and cable IP
  dial tone
• but unaware of type of data carried
• VSP may be in another state or country
• Corporations and universities dont have email
  carriers, either

Yahoo
ISP (IP, DHCP, DNS)
MCI
dark fiber provider
NYSERNET
7
Why is VoIP ? wireless?

• VoIP devices may not have phone numbers as lookup
  keys
• e.g., siphgs_at_cs.columbia.edu
• Location information for devices is civic, not
  longitude/latitude
• e.g., service address for VSPs
• GPS not available (nor functional) on indoor
  devices
• plus, accuracy of 50 m (67) or 150 m spans many
  buildings
• no floor information
• Cell phones dont work in our building
• so A-GPS is unlikely to work there, either
• Plus, wireless E911 complexity due to old
  signaling mechanism

50m
8
IETF efforts

• IETF Internet Engineering Task Force
• The Internet Engineering Task Force (IETF) is a
  large open international community of network
  designers, operators, vendors, and researchers
  concerned with the evolution of the Internet
  architecture and the smooth operation of the
  Internet. It is open to any interested
  individual.
• Efforts on 911 services go back to 2001,
• but only recent high-impact efforts
• ECRIT BOF at Washington, DC IETF (November 2004)
• focuses on call routing problem
• likely to be WG soon ? see other talk
• individuals working both in NENA and IETF WGs

9
Current IETF drafts

• draft-taylor-sipping-emerg-scen-01
• scenarios, e.g., hybrid VoIP-PSTN
• draft-schulzrinne-sipping-emergency-req
• generic requirements for emergency calling
• draft-schulzrinne-sipping-emergency-arch
• overall architecture for emergency calling
• draft-ietf-sipping-sos-00
• describes sos SIP URI
• draft-rosen-dns-sos
• new DNS resource records for location mapping

10
Three stages to VoIP 911
spec. available? use 10-digit admin. number? mobility callback number to PSAP? caller location to PSAP? PSAP modification ALI (DB) modification new services
I1 now allowed stationary no no no no none
I2 Dec. 2004 no stationary nomadic yes yes no (8 or 10 digit) update none
I3 2005 no stationary nomadic mobile yes yes IP-enabled ALI not needed MSAG replaced by DNS location in-band GNP multimedia international calls
11
Architectural assumptions and goals for I3

• SIP-based for interchange
• other protocols (e.g., H.323) via gateway
• avoid complexity of multiple protocols everywhere
• H.248/MGCP not used for interdomain signaling ?
  not needed here
• International
• devices bought anywhere can make emergency calls
  anywhere
• limit biases in address formats, languages,
• avoid built-in bias for 911 or 112 (mostly)
• use term ECC (emergency call center) instead of
  PSAP ?
• Multimedia
• support non-audio media if available in PSAP
• e.g., images or video for situational awareness

12
Goals, contd.

• Support other communications modes
• IM
• maybe email later
• Support access for callers with disabilities
• real-time text
• video for sign language
• Easy access to external data
• hazmat records
• sensor data (collision data, video images, )

13
Architecture components

1. Common URL for emergency calls
2. Convey local emergency number to devices
3. Allow devices to obtain their location
4. Route calls to right destination

14
Component 1 Common URL for emergency services

• Emergency numbers may be dialed from many
  different places
• about 60 (national) different emergency service
  numbers in the world
• many are used for other services elsewhere (e.g.,
  directory assistance)
• End systems, proxies and gateways should be able
  to tell easily that a call is an emergency call
• Thus, need common identifier for calls

15
Common URL for emergency calls

• IETF draft suggests sipsos_at_home-domain
• home-domain domain of caller
• Can be recognized by proxies along the way
• short cut to emergency infrastructure
• If not, it reaches home proxy of subscriber
• Call can be routed from there easily
• global access to routing information (see later)

16
Service identification

• In some countries, specialized numbers for
  police, fire,
• We add SIP protocol header that identifies call
  service
• Accept-Contact servicesos.mountain
• Generally, not user visible

sos.fire fire brigade
sos.rescue ambulance
sos.marine marine guard
sos.police police
sos.mountain mountain rescue
sos.test only testing
17
Other call identifiers

• Using SIP caller preferences/callee capabilities
• Caller languages
• automatically route to PSAP or call taker that
  speaks French
• Accept-Language fr
• Caller media preferences
• automatically route to PSAP or call taker that
  can deal with typed text
• Accept-Contact textrequire

18
Component 2 Translating dialed digits

• Always available 112 and 911
• Configuration mechanisms
• SIM cards (GSM phones)
• XCAP configuration
• local (outbound) proxy
• home proxy
• DNS
• Default configuration if no other information
  available
• 000, 08, 110, 999, 118 and 119

19
Emergency number configuration via DNS
countryDE
DHCP server
add 110 to list of emergency dial strings
de.sos.arpa
NAPTR 100 10 "u" "SOS" "/110/sipssos.police_at_notfa
ll.de/i
20
Translating dialed numbers to emergency
identifiers
sipssos_at_example.com
9-1-1
no. URI service
911 sos sos
110 sos sos.police
112 sos sos.fire
On many telephone-like systems, only numbers are
available ? number translation
21
GEOPRIV and SIMPLE architectures
rule maker
rule interface
target
location server
location recipient
notification interface
publication interface
GEOPRIV
SUBSCRIBE
presentity
presence agent
watcher
SIP presence
PUBLISH
NOTIFY
caller
callee
SIP call
INVITE
INVITE
22
Component 3 Determining locations

• LLDP-MED periodic delivery of port and location
  information to each switch port
• particularly suited for floor-level location in
  enterprises
• Conveyed via DHCP from IP-level provider
• Formats
• geospatial (longitude, latitude, altitude or
  floor)
• civic (country, administrative units, street)
• Provider usually knows
• Does not depend on being a voice service provider
• 802.11 triangulation
• GPS (for mobile devices)
• Via configuration protocol (XCAP)
• relies on VSP having accurate service location
  information
• User-configured (last resort)

23
Enhancing DHCP for locations

• use MAC address backtracing to get location
  information
• can use existing DHCP servers and clients

24
Conveying location along the call path
placing emergency call
INVITE sipsos_at_example.com From
sipalice_at_example.com To sipsos_at_example.com Cont
ent-Type multipart/mixed ltgplocationinfogt ltloc
civilgt ltca1gtPAlt/ca1gt ltca2gtUniversity
Parklt/ca2gt ltczipgt10025lt/czipgt lt/loccivilgt lt
/gplocation-infogt
on boot
25
GEOPRIV geospatial format
lt?xml version"1.0" encoding"UTF-8"?gt
ltpresence xmlns"urnietfparamsxmlnspidf"
xmlnsgp"urnietfparamsxmlnspidfgeopriv10
" xmlnsgml"urnopengisspecificationgml
schema-xsdfeaturev3.0"
entity"presgeotarget_at_example.com"gt lttuple
id"sg89ae"gt lttimestampgt2003-06-22T205729Z
lt/timestampgt ltstatusgt ltgpgeoprivgt
ltgplocation-infogt
ltgmllocationgt ltgmlPoint
gmlid"point96" srsName"epsg4326"gt
ltgmlcoordinatesgt315600S 1155000Elt/gmlcoor
dinatesgt lt/gmlPointgt
lt/gmllocationgt lt/gplocation-infogt
ltgpusage-rulesgt
ltgpretransmission-allowedgtnolt/gpretransmission-a
llowedgt ltgpretention-expirygt2003-06-23
T045729Zlt/gpretention-expirygt
lt/gpusage-rulesgt lt/gpgeoprivgt
lt/statusgt lt/tuplegt lt/presencegt

• GEOPRIV IETF working group for geospatial
  privacy
• Location within call signaling
• not ALI reference
• Based on GML mark-up

26
GEOPRIV civic format
ltcountrygtUSlt/countrygt ltA1gtNJlt/A1gt ltA2gtBergenlt/A2gt
ltA3gtLeonialt/A3gt ltA6gtWestviewlt/A6gt ltSTSgtAvelt/STSgt lt
HNOgt313lt/HNOgt ltNAMgtSchulzrinnelt/NAMgt ltZIPgt07605-18
11lt/ZIPgt

• Based on NENA XML elements
• Except internationalized administrative divisions

A1 national subdivisions (state, region, province, prefecture)
A2 county, parish, gun (JP), district (IN)
A3 city, township, shi (JP)
A4 city division, borough, city district, ward, chou (JP)
A5 neighborhood, block
A6 street
27
Location-based call routing UA knows its
location
GPS
INVITE sipssos_at_
48 49' N 2 29' E
outbound proxy server
DHCP
48 49' N 2 29' E ? Paris fire department
28
Location-based call routing network knows
location
TOA
outbound proxy
include location info in 302
INVITE sipssos_at_
INVITE sipssos_at_paris.gendarme.fr
48 49' N 2 29' E
map location to (SIP) domain
29
4. Call Routing

• Several possible options to map geo/civic
  locations under discussion
• DNS discussed next
• CRISP/IRIS XML-based directory protocol
  currently used for DNS registrars
• SOAP (web services)
• Possibly combination of these
• e.g., use DNS for coarse routing
• Only DNS has been fleshed out

30
Routing core requirements

• Both civic and geo coordinates
• conversion from civic to geo may introduce errors
• need to check validity of civic addresses
• thus, need to map both point-in-polygon and
  hierarchical strings
• Delegation
• service boundaries follow arcane political maps
• mapping updates must be done at local level
• Scaling
• global directory
• but not single (logical) server
• Caching
• cant go to root directory for each call
• must work even if routing machinery is
  temporarily unavailable
• Reliable
• WAN-scale automated replication

31
A quick review of DNS

• DNS mapping from hierarchical names to resource
  records
• commonly, but not necessarily IP addresses
• Authoritative server for each domain operated by
  domain
• e.g., columbia.edu server is owned operated by
  Columbia University

leonia.nj.us?
caches results
pc.example.com
leonia.nj.us
32
A quick review of DNS

• Thus, globally visible database, with delegated
  control of content
• Replication of DNS servers mandatory
• at least 2, often more
• automatically synchronized
• Robustness by caching
• typically life time of 24 hours
• end system may not notice outage of authoritative
  server
• Host security ? modification control
• DNS security (DNSsec) to ensure authenticity of
  content

33
How does the PSAP find the callers location?

• Largest difference to existing E911 system
• In-band, as part of call setup
• carried in body of setup message
• rather than by reference into external database
• May be updated during call
• moving vehicles
• late availability of information (GPS acquisition
  delay)
• Also possible subscribe to location information

34
Using DNS for determining PSAPs
?
.us.sos. arpa
.sos. arpa
.nj.us.sos. arpa
?
?
firedept.leonia.nj.gov
?
leonia.nj.us.sos.arpa?

• Define new domain, e.g., sos.arpa
• .arpa used for infrastructure functions
• top-level queries done only rarely
• results are cached at client

35
Obtaining all sub-regions
us.sos.arpa PTR al.us.sos.arpa
us.sos.arpa PTR ak.us.sos.arpa
us.sos.arpa PTR nj.us.sos.arpa
PTR
us.sos. arpa
nj.us.sos. arpa
nj.us.sos.arpa PTR sussex.nj.us.sos.arpa
nj.us.sos.arpa PTR passaic.nj.us.sos.arpa
nj.us.sos.arpa PTR bergen.nj.us.sos.arpa
PTR
CNus A1nj A2bergen A3leonia
36
What about geo addresses?

• Store one DNS record for each PSAP
• or whatever the last caller-visible SIP proxy is
• could be state, county, city,
• Point to record containing PSAP boundary
• retrieved via HTTP (web)
• cached as needed
• Records polygon edges of PSAP service area
  (longitude-latitude tuples)
• Same descent of hierarchy
• at each level, search all leaves for match

Bergen Passaic Atlantic
37
Address hiding

• Some advocate hiding IP addresses of PSAPs (or
  groups of PSAPs)
• Not clear what this means
• if call made, IP address will be returned in
  packets
• Can, however, have different perimeters

source address of SIP and audio packets
38
Routing layers
firewall boundary
39
Privacy and authentication

• Want to ensure privacy of call setup information
• prevent spoofing of call origins
• but cant enforce call authentication
• need to authenticate call destination
• ideally, certificate for PSAPs
• but initially just verify that reached
  DNS-indicated destination
• use TLS (SSL), as in https//
• host certificates widely available
• just need a domain name and a credit card

40
Testing emergency calls

• Current E911 system has no good way to test 911
  reachability without interfering with emergency
  services
• With VoIP, more distributed system ? more need
  for testing
• Use SIP OPTIONS request ? route request, but
  dont reach call taker
• Also, DNS model allows external consistency
  checking
• e.g., nationwide 911 testing agency

41
Emergency call conferencing
PSAP brings all related parties into a
conference call
Hospital
Fire department
INVITE
Conference server
Recorder
3rd party call control
PSAP
Caller
42
Scaling

• NENA estimated 200 million calls to 9-1-1 in
  the U.S. each year
• ? approximately 6.3 calls/second
• if 3 minute call, about 1,200 concurrent calls
• typical SIP proxy server (e.g., sipd) on 1 GHz PC
  can handle about 400 call arrivals/second
• thus, unlikely to be server-bound

43
Open issues

• Technical (protocol) issues
• details of DNS records
• top-level DNS domain?
• how to do testing with minimal impact?
• Operational issues
• who runs sos.arpa and us.sos.arpa?
• export of MSAG information into DNS?
• will DSL and cable modem carriers provide
  location information?
• Funding issues
• use IP-layer funding for 911, not voice services

44
Different perspectives
MSAG routing data provided by (national-scale) database vendors bottom-up offered by PSAPs and jurisdictions
MSAG and routing data proprietary and not available to public open data
specialized protocols for emergency services avoid specialized protocols at all cost
specialized, dedicated emergency services networks fortified networks, but with rich Internet connectivity
slow transition to I3 (decades) if possible, make I2 period a matter of years or skip I2
45
Conclusion

• Good news
• VoIP-based 911 is not nearly as hard as Phase II
  wireless
• can be leveraged to provide simpler Phase II
  services for non-VoIP terminals
• PC-based end system can be maintained as is
• use of COTS, across national borders
• Challenges
• cannot simply add one more patch to existing
  circuit-switched 911 system