emergency calling for voip l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Emergency calling for VoIP PowerPoint Presentation
Download Presentation
Emergency calling for VoIP

Loading in 2 Seconds...

play fullscreen
1 / 32

Emergency calling for VoIP - PowerPoint PPT Presentation


  • 180 Views
  • Uploaded on

Emergency calling for VoIP. Henning Schulzrinne Columbia University Intrado (January 2004). Overview. SIP review SIP architecture constraints and assumptions Emergency calling components: call identification user location call routing PSAP verification. What is SIP?.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Emergency calling for VoIP' - arnav


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
emergency calling for voip

Emergency calling for VoIP

Henning Schulzrinne

Columbia University

Intrado (January 2004)

overview
Overview
  • SIP review
  • SIP architecture constraints and assumptions
  • Emergency calling components:
    • call identification
    • user location
    • call routing
    • PSAP verification
what is sip
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
  • Microsoft’s Windows Messenger (4.7) includes SIP
philosophy
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
sip trapezoid
SIP trapezoid

destination proxy

(identified by SIP URI domain)

outbound proxy

1st request

SIP trapezoid

2nd, 3rd, … request

a@foo.com: 128.59.16.1

registrar

voice traffic

RTP

sip message format
SIP message format

response

request

INVITE sip:bob@there.com SIP/2.0

SIP/2.0 200 OK

request line

Via: SIP/2.0/UDP here.com:5060

From: Alice <sip:alice@here.com>

To: Bob <sip:bob@there.com>

Call-ID: 1234@here.com

CSeq: 1 INVITE

Subject: just testing

Contact: sip:alice@pc.here.com

Content-Type: application/sdp

Content-Length: 147

Via: SIP/2.0/UDP here.com:5060

From: Alice <sip:alice@here.com>

To: Bob <sip:bob@there.com>

Call-ID: 1234@here.com

CSeq: 1 INVITE

Subject: just testing

Contact: sip:alice@pc.here.com

Content-Type: application/sdp

Content-Length: 134

header fields

v=0

o=alice 2890844526 2890844526 IN IP4 here.com

s=Session SDP

c=IN IP4 100.101.102.103

t=0 0

m=audio 49172 RTP/AVP 0

a=rtpmap:0 PCMU/8000

v=0

o=bob 2890844527 2890844527 IN IP4 there.com

s=Session SDP

c=IN IP4 110.111.112.113

t=0 0

m=audio 3456 RTP/AVP 0

a=rtpmap:0 PCMU/8000

messagebody

SDP

pstn vs internet telephony
PSTN vs. Internet Telephony

PSTN:

Signaling & Media

Signaling & Media

China

Internet

telephony:

Signaling

Signaling

Media

Australia

Belgian customer,

currently visiting US

sip addressing
SIP addressing
  • Users identified by SIP or tel URIs
    • sip:alice@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 (sip:foo@128.59.16.15)
  • Registration binds SIP URIs (e.g., device addresses) to SIP “address-of-record” (AOR)

tel:110

sip:sos@domain

domain 

128.59.16.17

via NAPTR + SRV

3g architecture registration
3G Architecture (Registration)

mobility management

signaling

serving

interrogating

interrogating

CSCF

proxy

home IM domain

registration signaling (SIP)_

visited IM domain

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

don’t rely on address or network hiding

SIP architecture biases
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

Objectives for emergency call architecture
identifying emergency calls
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
  • sip:sos@home-domain.com
    • also sos.police, sos.rescue, sos.marine, …
  • Ensures testability – can always reach home domain
  • Also support always:
    • tel:911, tel:112
  • Additional local numbers via local dial plan discovery
    • not yet fully defined, but part of SIP configuration effort
verifying the psap
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
determining location
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
dhcp for locations

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

458/17  Rm. 815

458/18  Rm. 816

DHCP for locations
  • modified dhcpd (ISC) to generate location information
  • use MAC address backtracing to get location information
dhcp for locations18
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
geopriv and simple architectures
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

geopriv geospatial format
Based on GML mark-upGEOPRIV geospatial format

<?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:geotarget@example.com">

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

geopriv civil format
GEOPRIV civil format
  • Based on NENA XML elements
  • Except internationalized administrative divisions:

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

emergency calling as an lbs
Emergency calling as an LBS
  • Emergency calling (“911’’, “112”) =
    • call identification  sip:sos@domain or tel:112
    • 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
location based call routing ua knows its location
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

location based call routing network knows location

IP

Location-based call routing – network knows location

TOA

outbound proxy

include location

info in 302

INVITE sips:sos@

INVITE sips:sos@paris.gendarme.fr

48° 49' N 2° 29' E

map location to

(SIP) domain

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

Mapping locations to PSAPs
dns based mapping
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
resiliency
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
scaling and redundancy
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 < 50%
  • Still need common database
    • can separate REGISTER
    • make rest read-only
high call volume system
High call volume system

stateless proxies

sip1.example.com

a1.example.com

a2.example.com

sip2.example.com

sip:bob@example.com

b1.example.com

sip:bob@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

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)

Denial-of-service attacks – signaling
denial of service attacks media
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
conclusion
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