1 / 32

Emergency calling for VoIP

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

arnav
Download Presentation

Emergency calling for VoIP

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 • Microsoft’s 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@foo.com: 128.59.16.1 registrar voice traffic RTP

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

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

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

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

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

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

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

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

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

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

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

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

  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 < 50% • Still need common database • can separate REGISTER • make rest read-only

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

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

  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

More Related