2. Emergency calling for VoIP Henning Schulzrinne Columbia University Intrado (January 2004)

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

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

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

6. Basic SIP message flow

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

8. SIP message format INVITE sip:bob@there.com SIP/2.0 Via: SIP/2.0/UDP here.com:5060 From: Alice To: Bob 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 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 SIP/2.0 200 OK Via: SIP/2.0/UDP here.com:5060 From: Alice To: Bob 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 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 SDP message body header fields request line request response

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

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

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

12. Example SIP phones

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

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

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

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

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

18. DHCP for locations modified dhcpd (ISC) to generate location information use MAC address backtracing to get location information DHCP server 458/17  Rm. 815 458/18  Rm. 816 DHCP answer: sta=DC loc=Rm815 lat=38.89868 long=77.03723 8:0:20:ab:d5:d CDP + SNMP 8:0:20:ab:d5:d  458/17

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

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

21. GEOPRIV geospatial format Based on GML mark-up <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"> 2003-06-22T20:57:29Z 31:56:00S 115:50:00E no 2003-06-23T04:57:29Z

22. GEOPRIV civil format Based on NENA XML elements Except internationalized administrative divisions: A1national subdivisions (state, region, province, prefecture) A2county, parish, gun (JP), district (IN) A3city, township, shi (JP) A4city division, borough, city district, ward, chou (JP) A5neighborhood, block A6street US NJ Bergen Leonia Westview Ave 313 Schulzrinne 07605-1811

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

24. Location-based call routing – UA knows its location GPS 48° 49' N 2° 29' E INVITE sips:sos@ DHCP outbound proxy server 48° 49' N 2° 29' E  Paris fire department

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

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

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

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

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

30. High call volume system _sip._udp SRV 0 0 sip1.example.com 0 0 sip2.example.com 0 0 sip3.example.com a2.example.com sip2.example.com sip3.example.com a1.example.comsip1.example.com b1.example.com b2.example.com sip:bob@example.com sip:bob@b.example.com _sip._udp SRV 0 0 b1.example.com 0 0 b2.example.com stateless proxies

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

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

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