Emergency calling for Vo IP Henning Schulzrinne Columbia

Emergency calling for Vo. IP Henning Schulzrinne Columbia University Intrado (January 2004)

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

What is SIP? l Session Initiation Protocol protocol that establishes, manages (multimedia) sessions l l l also used for IM, presence & event notification uses SDP to describe multimedia sessions Developed at Columbia U. (with others) Standardized by IETF, 3 GPP (for 3 G wireless), Packet. Cable About 60 companies produce SIP products Microsoft’s Windows Messenger (4. 7) includes SIP

Philosophy l l l 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 l l l even statefull proxies only keep transaction state, not call (session) state transaction: single request + retransmissions proxies can be completely stateless

Basic SIP message flow

SIP trapezoid outbound proxy destination proxy (identified by SIP URI domain) 1 st request SIP trapezoid 2 nd, 3 rd, … request a@foo. com: 128. 59. 16. 1 registrar voice traffic RTP

request line header fields message body SIP message format request INVITE sip: bob@there. com SIP/2. 0 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 v=0 o=alice 2890844526 IN IP 4 here. com s=Session SDP c=IN IP 4 100. 101. 102. 103 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap: 0 PCMU/8000 SDP response SIP/2. 0 200 OK 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 v=0 o=bob 2890844527 IN IP 4 there. com s=Session SDP c=IN IP 4 110. 111. 112. 113 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap: 0 PCMU/8000

PSTN vs. Internet Telephony PSTN: Signaling & Media Internet telephony: Signaling & Media China Signaling Media Belgian customer, currently visiting US Australia

SIP addressing l Users identified by SIP or tel URIs l l l tel: URIs describe E. 164 number, not dialed digits (RFC 2806 bis) tel URIs SIP URIs by outbound proxy tel: 110 A person can have any number of SIP URIs The same SIP URI can reach many different phones, in different networks l l sip: sos@domain sequential & parallel forking SIP URIs can be created dynamically: l l sip: alice@example. com GRUUs conferences device identifiers (sip: foo@128. 59. 16. 15) Registration binds SIP URIs (e. g. , device addresses) to SIP “address-of-record” (AOR) domain 128. 59. 16. 17 via NAPTR + SRV

3 G Architecture (Registration) mobility management signaling serving CSCF interrogating proxy interrogating home IM domain registration signaling (SIP)_ visited IM domain

Example SIP phones

SIP architecture biases l l l International no national variants Internet = intranet separation of data and signaling l l S/MIME bodies TLS (sips: ) end system control of information proxies can l l signaling nodes can be anywhere end-to-end security where possible, hop-by-hop otherwise l l 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 l don’t rely on address or network hiding

Objectives for emergency call architecture l International l l first voice, but also video, interactive text, bio sensors, IM, … Protocol-independent l l any device works anywhere same basic network standards even if local arrangements differ Media-independent l same rough architecture should work for H. 323 and other architectures Leverage SIP capabilities l l 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 l l no assumptions about dial plans, local emergency numbers Testable l l should be able to test call routing without placing actual call e. g. , using SIP OPTIONS

Identifying emergency calls l Universal identifier l l l sip: sos@home-domain. com l l l also sos. police, sos. rescue, sos. marine, … Ensures testability – can always reach home domain Also support always: l l device may not know which country it is in should be applicable to wider variety of communications, e. g. , IM tel: 911, tel: 112 Additional local numbers via local dial plan discovery l not yet fully defined, but part of SIP configuration effort

Verifying the PSAP l l l 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 l l Determine (person, location) tuple Two modes: l l GPS may not be practical (cost, power, topology) l l end-system based l GPS, beacons, 802. 11 triangulation (STA) infrastructure, but explicit user action l swipe card, RFID (maybe), biometrics network-based l 802. 11 triangulation (AP), face recognition A-GPS for indoor use – leverages cell infrastructure Add location beacons l l extrapolate based on distance moved l odometer, pedometer, time-since-sighting idea: meet other mobile location beacons l estimate location based on third-party information

DHCP for locations l l modified dhcpd (ISC) to generate location information use MAC address backtracing to get location information 8: 0: 20: ab: d 5: d DHCP server CDP + SNMP 8: 0: 20: ab: d 5: d 458/17 DHCP answer: sta=DC loc=Rm 815 lat=38. 89868 long=77. 03723 458/17 Rm. 815 458/18 Rm. 816

DHCP for locations l Proposal: DHCP extensions for geographic and civil location l geographic: resolution (bits), long/lat, altitude (meters or floors) l civil: l l 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 l CDP for Cisco, EDP for Extreme Networks Can also use backtracking via SNMP switch tables l locally implemented for emergency services (Perl sip-cgi script) l depends on switch vendors l needs database switch port room number

GEOPRIV and SIMPLE architectures rule maker rule interface target presentity caller publication interface PUBLISH INVITE location server presence agent notification interface location recipient GEOPRIV watcher SIP presence SUBSCRIBE NOTIFY INVITE callee SIP call

GEOPRIV geospatial format l Based on GML mark-up <? xml version="1. 0" encoding="UTF-8"? > <presence xmlns="urn: ietf: params: xml: ns: pidf" xmlns: gp="urn: ietf: params: xml: ns: pidf: geopriv 10" xmlns: gml="urn: opengis: specification: gml: schema-xsd: feature: v 3. 0" entity="pres: geotarget@example. com"> <tuple id="sg 89 ae"> <timestamp>2003 -06 -22 T 20: 57: 29 Z</timestamp> <status> <gp: geopriv> <gp: location-info> <gml: location> <gml: Point gml: id="point 96" srs. Name="epsg: 4326"> <gml: coordinates>31: 56: 00 S 115: 50: 00 E</gml: coordinates> </gml: Point> </gml: location> </gp: location-info> <gp: usage-rules> <gp: retransmission-allowed>no</gp: retransmission-allowed> <gp: retention-expiry>2003 -06 -23 T 04: 57: 29 Z</gp: retention-expiry> </gp: usage-rules> </gp: geopriv> </status> </tuple> </presence>

GEOPRIV civil format l l Based on NENA XML elements Except internationalized administrative divisions: A 1 national subdivisions (state, region, province, prefecture) A 2 county, parish, gun (JP), district (IN) A 3 city, township, shi (JP) A 4 city division, borough, city district, ward, chou (JP) A 5 neighborhood, block A 6 street <country>US</country> <A 1>NJ</A 1> <A 2>Bergen</A 2> <A 3>Leonia</A 3> <A 6>Westview</A 6> <STS>Ave</STS> <HNO>313</HNO> <NAM>Schulzrinne</NAM> <ZIP>07605 -1811</ZIP>

Emergency calling as an LBS l Emergency calling (“ 911’’, “ 112”) = l l call identification sip: sos@domain or tel: 112 destination identification l l special call handling l l priority handling of signaling or media packets bypass authentication and authorization call routing to nearest emergency call center (ECC) Call routing is hardest l l l is this really an emergency call center? must work internationally end system + network-based location determination Once solved: l l l roadside emergency (AAA, ADAC, …) pizza emergency (nearest Pizza. Hut) 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

Location-based call routing – network knows location TOA outbound proxy IP include location info in 302 INVITE sips: sos@paris. gendarme. fr 48° 49' N 2° 29' E map location to (SIP) domain

Mapping locations to PSAPs l LDAP l l l no natural hierarchy high session overhead DNS l l l l 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 l l l efficient SIP-specific SOAP l l l protocol independent large overhead undefined hierarchy

DNS-based mapping l l 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 l l l use pseudo-domains (47 n 13. 13 e 4. sos. arpa) use RR polygon entries only and have proxy do inverse mapping l zone transfer maybe combine with default proxy if outside known range

Resiliency l Compared to traditional 911, very decentralized: l l l 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 l thus, put DNS/SIP servers on each of the major local broadband access providers (DSL, cable modem, …) PSAP addresses can be changed easily l e. g. , if address is part of some DOS worm Use multiple SIP proxy servers l l l 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 l DNS SRV records allow static load balancing and fail-over l but failed systems increase call setup delay l can also use IP address “stealing” to mask failed systems, as long as load < 50% l Still need common database l can separate REGISTER l make rest read-only

High call volume system stateless proxies sip 1. example. com a 2. example. com sip: bob@example. com sip: bob@b. example. com b 1. example. com sip 3. example. com b 2. example. com _sip. _udp SRV 0 0 sip 1. example. com 0 0 sip 2. example. com 0 0 sip 3. example. com _sip. _udp SRV 0 0 b 1. example. com 0 0 b 2. example. com

Denial-of-service attacks – signaling l attack targets: l l l l DNS for mapping SIP proxies SIP end systems at PSAP unclear: number of DOS attacks using spoofed IP addresses l types of attacks: l l l 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 l 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 l l l built-in mechanism for SIP (“null authentication”) also provided by TLS allow filtering of attacker IP addresses (pushback)

Denial-of-service attacks – media l l l 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: l l only packets for completed calls are permitted assuming SIP source = RTP source

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