320 likes | 568 Views
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?.
E N D
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? • 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 • 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 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 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: Signaling & Media Signaling & Media China Internet telephony: Signaling Signaling Media Australia Belgian customer, currently visiting US
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) mobility management signaling serving interrogating interrogating CSCF proxy home IM domain registration signaling (SIP)_ visited IM domain
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
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 • 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 • 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 • 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
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 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 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
Based on GML mark-up GEOPRIV 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 • 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 (“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 GPS INVITE sips:sos@ 48° 49' N 2° 29' E outbound proxy server DHCP 48° 49' N 2° 29' E Paris fire department
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
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 • 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 • 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 • 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 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
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 • 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 • 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