Emergency calling for VoIP

1
Emergency calling for VoIP

• Henning Schulzrinne
• Columbia University
• Intrado (January 2004)

2
Overview

• SIP review
• SIP architecture constraints and assumptions
• Emergency calling components
• call identification
• user location
• call routing
• PSAP verification

3
What is SIP?

• Session Initiation Protocol ? protocol that
  establishes, manages (multimedia) sessions
• also used for IM, presence event notification
• uses SDP to describe multimedia sessions
• Developed at Columbia U. (with others)
• Standardized by IETF, 3GPP (for 3G wireless),
  PacketCable
• About 60 companies produce SIP products
• Microsofts Windows Messenger (4.7) includes SIP

4
Philosophy

• Session establishment event notification
• Any session type, from audio to circuit emulation
• Provides application-layer anycast service
• Provides terminal and session mobility
• Based on HTTP in syntax, but different in
  protocol operation
• Peer-to-peer system, with optional support by
  proxies
• even statefull proxies only keep transaction
  state, not call (session) state
• transaction single request retransmissions
• proxies can be completely stateless

5
Basic SIP message flow
6
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
7
SIP message format
response
request
INVITE sipbob_at_there.com SIP/2.0
SIP/2.0 200 OK
request line
Via SIP/2.0/UDP here.com5060 From Alice
To Bob C
all-ID 1234_at_here.com CSeq 1 INVITE Subject
just testing Contact sipalice_at_pc.here.com Conten
t-Type application/sdp Content-Length 147
Via SIP/2.0/UDP here.com5060 From Alice
To Bob C
all-ID 1234_at_here.com CSeq 1 INVITE Subject
just testing Contact sipalice_at_pc.here.com Conten
t-Type application/sdp Content-Length 134
header fields
v0 oalice 2890844526 2890844526 IN IP4
here.com sSession SDP cIN IP4
100.101.102.103 t0 0 maudio 49172 RTP/AVP
0 artpmap0 PCMU/8000
v0 obob 2890844527 2890844527 IN IP4
there.com sSession SDP cIN IP4
110.111.112.113 t0 0 maudio 3456 RTP/AVP
0 artpmap0 PCMU/8000
message body
SDP
8
PSTN vs. Internet Telephony
PSTN
Signaling Media
Signaling Media
China
Internet telephony
Signaling
Signaling
Media
Australia
Belgian customer, currently visiting US
9
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
10
3G Architecture (Registration)
mobility management
signaling
serving
interrogating
interrogating
CSCF
proxy
home IM domain
registration signaling (SIP)_
visited IM domain
11
Example SIP phones
12
SIP architecture biases

• International ? no national variants
• Internet intranet
• separation of data and signaling
• signaling nodes can be anywhere
• end-to-end security where possible, hop-by-hop
  otherwise
• S/MIME bodies
• TLS (sips)
• end system control of information

• proxies can
• inspect, modify and add headers
• may be able to inspect the message body (if not
  encrypted)
• should not modify the message body ? may break
  end-to-end integrity
• no security by obscurity
• dont rely on address or network hiding

13
Objectives for emergency call architecture

• International
• any device works anywhere
• same basic network standards even if local
  arrangements differ
• Media-independent
• first voice, but also video, interactive text,
  bio sensors, IM,
• Protocol-independent
• same rough architecture should work for H.323 and
  other architectures
• Leverage SIP capabilities
• end-to-end security
• PSAPs can easily be relocated and moved
• caller preferences, callee capabilities ? routing
  for TTY calls

• Independent of current phone numbering mechanism
• no assumptions about dial plans, local emergency
  numbers
• Testable
• should be able to test call routing without
  placing actual call
• e.g., using SIP OPTIONS

14
Identifying emergency calls

• Universal identifier
• device may not know which country it is in
• should be applicable to wider variety of
  communications, e.g., IM
• sipsos_at_home-domain.com
• also sos.police, sos.rescue, sos.marine,
• Ensures testability can always reach home
  domain
• Also support always
• tel911, tel112
• Additional local numbers via local dial plan
  discovery
• not yet fully defined, but part of SIP
  configuration effort

15
Verifying the PSAP

• Some want to be able to verify that PSAP
  answering is indeed one
• Probably easiest if last proxy uses TLS with
  server certificates that verify domain
• Longer term, maybe signed capability

16
Determining location

• Determine (person, location) tuple
• Two modes
• end-system based
• GPS, beacons, 802.11 triangulation (STA)
• infrastructure, but explicit user action
• swipe card, RFID (maybe), biometrics
• network-based
• 802.11 triangulation (AP), face recognition
• GPS may not be practical (cost, power, topology)
• A-GPS for indoor use leverages cell
  infrastructure
• Add location beacons
• extrapolate based on distance moved
• odometer, pedometer, time-since-sighting
• idea meet other mobile location beacons
• estimate location based on third-party information

17
DHCP for locations

• modified dhcpd (ISC) to generate location
  information
• use MAC address backtracing to get location
  information

18
DHCP for locations

• Proposal DHCP extensions for geographic and
  civil location
• geographic resolution (bits), long/lat, altitude
  (meters or floors)
• civil
• what end system, switch or DHCP server
• hierarchical subdivisions, from country to
  street, landmark name, occupant
• Also, some LAN switches broadcast port and switch
  identification
• CDP for Cisco, EDP for Extreme Networks
• Can also use backtracking via SNMP switch tables
• locally implemented for emergency services (Perl
  sip-cgi script)
• depends on switch vendors
• needs database switch port ? room number

19
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
20
GEOPRIV geospatial format

xmlnsgp"urnietfparamsxmlnspidfgeopriv10
" xmlnsgml"urnopengisspecificationgml
schema-xsdfeaturev3.0"
entity"presgeotarget_at_example.com" id"sg89ae" 2003-06-22T205729Z


gmlid"point96" srsName"epsg4326"
315600S 1155000Edinates


nollowed 2003-06-23
T045729Z

• Based on GML mark-up

21
GEOPRIV civil format

• Based on NENA XML elements
• Except internationalized administrative
  divisions

US NJ Bergen
Leonia Westview Ave HNO313 Schulzrinne 07605-18
11
22
Emergency calling as an LBS

• Emergency calling (911, 112)
• call identification ? sipsos_at_domain or tel112
• destination identification
• is this really an emergency call center?
• special call handling
• priority handling of signaling or media packets ?
• bypass authentication and authorization ?
• call routing to nearest emergency call center
  (ECC)
• Call routing is hardest
• must work internationally
• end system network-based location determination
• Once solved
• roadside emergency (AAA, ADAC, )
• pizza emergency (nearest PizzaHut)
• but different privacy trade-offs ? voluntary
  disclosure

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
Mapping locations to PSAPs

• LDAP
• no natural hierarchy
• high session overhead
• DNS
• naturally hierarchical in management
• redundant with synchronization
• low-overhead queries
• built-in caching of results
• integrity protection with secure DNS
• requires new resource record
• kludge for geospatial (no zone transfers)

• SIP redirect or proxy
• efficient
• SIP-specific
• SOAP
• protocol independent
• large overhead
• undefined hierarchy

26
DNS-based mapping

• Similar to ENUM, but .sos.arpa domain with civil
  hierarchy
• e.g., leonia.bergen.nj.us.sos.arpa
• proxies are expected to cache local values based
  on DNS caching mechanisms
• more difficult for geo coordinates
• use pseudo-domains (47n13.13e4.sos.arpa)
• use RR polygon entries only and have proxy do
  inverse mapping
• zone transfer
• maybe combine with default proxy if outside known
  range

27
Resiliency

• Compared to traditional 911, very decentralized
• each county/city can have its own set of DNS
  servers
• data from country and state-level DNS lookups can
  be cached at proxies for days and weeks
• local calls should not depend on a national
  infrastructure
• thus, put DNS/SIP servers on each of the major
  local broadband access providers (DSL, cable
  modem, )
• PSAP addresses can be changed easily
• e.g., if address is part of some DOS worm
• Use multiple SIP proxy servers
• single SIP proxy can handle 100 calls/second
• SIP SRV/NAPTR offers fail-over and load sharing
• cross-service A backs up B, B backs up A

28
Scaling and redundancy

• DNS SRV records allow static load balancing and
  fail-over
• but failed systems increase call setup delay
• can also use IP address stealing to mask failed
  systems, as long as load
• Still need common database
• can separate REGISTER
• make rest read-only

29
High call volume system
stateless proxies
a1.example.com
sip1.example.com
a2.example.com
sip2.example.com
sipbob_at_example.com
b1.example.com
sipbob_at_b.example.com
sip3.example.com
b2.example.com
_sip._udp SRV 0 0 b1.example.com 0
0 b2.example.com
_sip._udp SRV 0 0 sip1.example.com
0 0 sip2.example.com 0 0
sip3.example.com
30
Denial-of-service attacks signaling

• attack targets
• DNS for mapping
• SIP proxies
• SIP end systems at PSAP
• types of attacks
• amplification ? only if no routability check, no
  TCP, no TLS
• state exhaustion ? no state until return
  routability established
• bandwidth exhaustion ? no defense except filters
  for repeats
• one defense big iron fat pipe
• danger of false positives

• unclear number of DOS attacks using spoofed IP
  addresses
• mostly for networks not following RFC 2267
  (Network Ingress Filtering Defeating Denial of
  Service Attacks which employ IP Source Address
  Spoofing)
• limit impact of DOS require return routability
• built-in mechanism for SIP (null
  authentication)
• also provided by TLS
• allow filtering of attacker IP addresses
  (pushback)

31
Denial-of-service attacks media

• Attacker could attempt to flood end systems with
  RTP (or other) packets
• push back attack to large pipe (POP)
• install filter managed by incoming SIP call
• only packets for completed calls are permitted
• assuming SIP source RTP source

32
Conclusion

• Requirements
• international
• multimedia
• multi-protocol
• Basic components for SIP-based emergency services
  in view
• need work on mapping component
• Internet-based, rather than closed systems
• re-use existing Internet protocols, rather than
  design 911-specific systems