Transcript INVITE sips:sos

An Architecture for NextGeneration Emergency Services
Henning Schulzrinne
Columbia University
April 26, 2004
Critical Issues Forum (Santa
Clara)
1
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
December 2, 2004
2
PSTN vs. Internet Telephony
PSTN:
Signaling & Media
Internet
telephony:
Signaling & Media
China
Signaling
Signaling
Media
Belgian customer,
currently2,visiting
December
2004 US
Australia
3
SIP trapezoid
outbound proxy
destination proxy
(identified by SIP URI domain)
1st request
SIP trapezoid
2nd, 3rd, … request
[email protected]:
128.59.16.1
registrar
voice traffic
RTP
December 2, 2004
4
SIP addressing

Users identified by SIP or tel URIs





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




tel:110
sip:sos@domain
sequential & parallel forking
SIP URIs can be created dynamically:


sip:[email protected]
GRUUs
conferences
device identifiers (sip:[email protected])
domain 
128.59.16.17
via NAPTR + SRV
Registration binds SIP URIs (e.g., device
addresses) to SIP “address-of-record”
(AOR)
December 2, 2004
5




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
don’t have email carriers, either
December 2, 2004
Yahoo
Telephone companies are no
longer needed
voice service provider
ISP
(IP, DHCP, DNS)
NYSERNET

MCI
How does VoIP differ from landline
and wireless PSTN?
(RTP, SIP)
dark fiber
provider
6
Why is VoIP ≠ wireless?

VoIP devices may not have phone numbers as
lookup keys


e.g., sip:[email protected]
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 don’t work in our building…


50m
so A-GPS is unlikely to work there, either
Plus, wireless E911 complexity due to old
signaling mechanism
December 2, 2004
7
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
December 2, 2004
8
Current IETF drafts

draft-taylor-sipping-emerg-scen-01


draft-schulzrinne-sipping-emergency-req


overall architecture for emergency calling
draft-ietf-sipping-sos-00


generic requirements for emergency calling
draft-schulzrinne-sipping-emergency-arch


scenarios, e.g., hybrid VoIP-PSTN
describes ‘sos’ SIP URI
draft-rosen-dns-sos

new DNS resource records for location mapping
December 2, 2004
9
Three stages to VoIP 911
spec.
available?
use 10digit
admin.
number?
mobility
callback
number
to
PSAP?
caller
location
to
PSAP?
PSAP
modificatio
n
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
no
stationary
nomadic
mobile
yes
yes
IP-enabled
ALI not
needed
MSAG
replaced by
DNS
location inband
GNP
multimedia
international
calls
I3
2005
December 2, 2004
10
Architectural assumptions and
goals for I3

SIP-based for interchange

other protocols (e.g., H.323) via gateway



H.248/MGCP not used for interdomain signaling  not needed
here
International





avoid complexity of multiple protocols everywhere
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
December 2, 2004
11
Goals, cont’d.

Support other communications modes



Support access for callers with disabilities



IM
maybe email later
real-time text
video for sign language
Easy access to external data


hazmat records
sensor data (collision data, video images, …)
December 2, 2004
12
Architecture components
1.
2.
3.
4.
Common URL for emergency calls
Convey local emergency number to
devices
Allow devices to obtain their location
Route calls to right destination
December 2, 2004
13
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
December 2, 2004
14
Common URL for emergency calls

IETF draft suggests “sip:sos@home-domain”


Can be recognized by proxies along the way



home-domain: domain of caller
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)
December 2, 2004
15
Service identification


In some countries,
specialized numbers for
police, fire, …
We add SIP protocol
header that identifies call
service:


Accept-Contact: *
;service=“sos.mountain”
sos.fire
fire brigade
sos.rescue
ambulance
sos.marine
marine guard
sos.police
police
sos.mountain mountain
rescue
sos.test
only testing
Generally, not user visible
December 2, 2004
16
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: *;text;require
December 2, 2004
17
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
December 2, 2004
18
Emergency number configuration
via DNS
DHCP server
country=DE
add 110 to list of
emergency dial strings
de.sos.arpa
NAPTR 100 10 "u" "SOS" "/110/sips:[email protected]/i
December 2, 2004
19
Translating dialed numbers to
emergency identifiers
sips:[email protected]
“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
December 2, 2004
20
GEOPRIV and SIMPLE architectures
rule
maker
rule
interface
target
presentity
publication
interface
PUBLISH
caller
December 2, 2004
INVITE
location
server
presence
agent
notification
interface
location
recipient
GEOPRIV
watcher
SIP
presence
SUBSCRIBE
NOTIFY
INVITE
callee
SIP
call
21
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:







Provider usually knows
Does not depend on being a voice service provider
802.11 triangulation
GPS (for mobile devices)
Via configuration protocol (XCAP)


geospatial (longitude, latitude, altitude or floor)
civic (country, administrative units, street)
relies on VSP having accurate service location information
User-configured (last resort)
December 2, 2004
22
Enhancing DHCP for locations


use MAC address backtracing to get location information
can use existing DHCP servers and clients
8:0:20:ab:d5:d
DHCP
server
CDP + SNMP
8:0:20:ab:d5:d  458/17
DHCP answer:
sta=DC loc=Rm815
lat=38.89868 long=77.03723
December 2, 2004
458/17  Rm. 815
458/18  Rm. 816
23
Conveying location along the call
path
placing
emergency
call
on
boot
INVITE sip:[email protected]
From: sip:[email protected]
To: sip:[email protected]
Content-Type: multipart/mixed
<gp:locationinfo>
<loc:civil>
<c:a1>PA</c:a1>
<c:a2>University Park</c:a2>
<c:zip>10025</c:zip>
</loc:civil>
</gp:location-info>
December 2, 2004
24
GEOPRIV geospatial format


GEOPRIV = IETF
working group for
geospatial privacy
Location within
call signaling


not ALI reference
Based on GML
mark-up
December 2, 2004
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0"
entity="pres:[email protected]">
<tuple id="sg89ae">
<timestamp>2003-06-22T20:57:29Z</timestamp>
<status>
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point gml:id="point96" srsName="epsg:4326">
<gml:coordinates>31:56:00S 115:50:00E</gml:coordinates>
</gml:Point>
</gml:location>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2003-06-23T04:57:29Z</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
</tuple>
</presence>
25
GEOPRIV civic format


Based on NENA XML
elements
Except internationalized
administrative divisions:
A1 national subdivisions (state, region, province,
prefecture)
<country>US</country>
<A1>NJ</A1>
<A2>Bergen</A2>
<A3>Leonia</A3>
<A6>Westview</A6>
<STS>Ave</STS>
<HNO>313</HNO>
<NAM>Schulzrinne</NAM>
<ZIP>07605-1811</ZIP>
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
December 2, 2004
26
Location-based call routing – UA
knows its location
GPS
INVITE sips:sos@
48° 49' N 2° 29' E
outbound
proxy server
DHCP
48° 49' N 2° 29' E  Paris fire department
December 2, 2004
27
Location-based call routing –
network knows location
TOA
outbound proxy
IP
include location
info in 302
INVITE sips:sos@
INVITE sips:[email protected]
48° 49' N 2° 29' E
map location to
(SIP) domain
December 2, 2004
28
4. Call Routing

Several possible options to map geo/civic
locations under discussion




Possibly combination of these


DNS – discussed next
CRISP/IRIS – XML-based directory protocol currently
used for DNS registrars
SOAP (web services)
e.g., use DNS for coarse routing
Only DNS has been fleshed out
December 2, 2004
29
Routing core requirements

Both civic and geo coordinates




Delegation




global directory
but not single (logical) server
Caching



service boundaries follow arcane political maps
mapping updates must be done at local level
Scaling


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
can’t go to root directory for each call
must work even if routing machinery is temporarily unavailable
Reliable

WAN-scale automated replication
December 2, 2004
30
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?
pc.example.com
December 2, 2004
caches results
leonia.nj.us
31
A quick review of DNS


Thus, globally visible database, with delegated control of
content
Replication of DNS servers mandatory



Robustness by caching




at least 2, often more
automatically synchronized
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
December 2, 2004
32
How does the PSAP find the caller’s
location?


Largest difference to existing E911 system
In-band, as part of call setup



May be updated during call



carried in body of setup message
rather than by reference into external database
moving vehicles
late availability of information (GPS acquisition delay)
Also possible: subscribe to location information
December 2, 2004
33
Using DNS for determining PSAPs

*.sos.
arpa
*.us.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
December 2, 2004
34
Obtaining all sub-regions
us.sos.arpa PTR al.us.sos.arpa
us.sos.arpa PTR ak.us.sos.arpa
us.sos.
arpa
us.sos.arpa PTR nj.us.sos.arpa
…
PTR …
December 2, 2004
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 …
CN=us
A1=nj
A2=bergen
A3=leonia
35
What about geo addresses?

Store one DNS record for each
PSAP



Point to record containing PSAP
boundary




or whatever the last caller-visible
SIP proxy is
could be state, county, city, …
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
December 2, 2004
Bergen
Passaic
Atlantic
…
36
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
December 2, 2004
source address of SIP and audio
packets
37
Routing layers
firewall boundary
December 2, 2004
38
Privacy and authentication


Want to ensure privacy of call setup information
prevent spoofing of call origins


need to authenticate call destination




but can’t enforce call authentication
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
December 2, 2004
39
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
don’t reach call taker
Also, DNS model allows external consistency
checking

e.g., nationwide 911 testing agency
December 2, 2004
40
Emergency
call
conferencing
PSAP brings all related
parties into a conference call
Hospital
Fire
department
INVITE
INVITE
Conference
server
Recorder
REFER
3rd party
call control
media
INVITE info
INVITE
INVITE
REFER
REFER
INVITE
media
info
PSAP
Caller
December 2, 2004
41
Scaling


NENA: “estimated 200 million calls to 9-11 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
December 2, 2004
42
Open issues

Technical (protocol) issues:




Operational issues:




details of DNS records
top-level DNS domain?
how to do testing with minimal impact?
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
December 2, 2004
43
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
December 2, 2004
44
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 circuitswitched 911 system
December 2, 2004
45