NENAs 11th Annual Technical Development Conference

1
NENAs 11th AnnualTechnical Development
Conference

• An Architecture for Next-Generation Emergency
  Services
• Henning Schulzrinne
• Columbia University

2
Overview

• How does VoIP differ from landline and wireless
  PSTN?
• 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)

• 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)
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 civil, 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
• 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-arch-00
• overall architecture for emergency calling
• draft-ietf-sipping-sos-00
• describes sos SIP URI
• draft-rosen-dns-sos-00
• new DNS resource records for location mapping

10
Architectural assumptions and goals

• 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 instead of PSAP ?
• Multimedia
• support non-audio media if available in PSAP

11
Goals, contd.

• Support other communications modes
• IM
• maybe email later
• Support access for callers with disabilities
• real-time text
• video for sign language

12
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

13
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)

14
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

15
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

16
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

17
Translating dialed numbers to emergency
identifiers
sipssos_at_example.com
9-1-1
On many telephone-like systems, only numbers are
available ? number translation
18
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
19
Determining locations

• Conveyed via DHCP from IP-level provider
• Formats
• geospatial (longitude, latitude, altitude or
  floor)
• civil (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)

20
Enhancing DHCP for locations

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

21
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

• Based on GML mark-up

22
GEOPRIV civil 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

23
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
24
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
25
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
26
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

27
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
28
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

29
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

30
Obtaining all sub-regions
us.sos. arpa
nj.us.sos. arpa
CNus A1nj A2bergen A3leonia
31
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,
• New POLY resource record
• 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
32
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
33
Routing layers
firewall boundary
34
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

35
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

36
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

37
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