IETF 61 (November 2004) ECRIT1 Requirements and Architecture for Emergency Calling draft-schulzrinne-sipping-emergency-arch draft-schulzrinne-sipping-emergency-req Henning Schulzrinne Columbia University

IETF 61 (November 2004) ECRIT2 Big picture Get citizen emergency call to emergency call center (Public Safety Answering Point) = PSAP Not emergency coordination (see IEPREP) Not just VoIP, but also video, text, data, … Not green field – incremental deployment Architectures: –trunk replacement (last hop only) –VoIP to traditional PSAP –end-to-end VoIP

IETF 61 (November 2004) ECRIT3 Traditional Emergency Calling Basic 911: just route to local PSAP –based on local switch –no location delivery Enhanced 911: route + location delivery (90%+?) –multiple PSAPs per PSTN switch –multiple switches per PSAP –location delivered out-of-band via caller number Phase I wireless (70%) –call delivery based on cell tower and face –no location delivery Phase II wireless (30%) –call delivery based on geo address –geo location delivery to PSAP

IETF 61 (November 2004) ECRIT4 Core problems PSTN: approximate routing often works –same switch –based on cell tower –based on caller number PSTN: relatively few, regionally-limited telecom providers (carriers) IP: carrier = bobs-bakery.com IP: no such approximations (usually) –application layer (e.g., SIP) has no clue as to location –L1—L3 may know about location (at least approximately), but don’t know about emergency calls

IETF 61 (November 2004) ECRIT5 Three stages to VoIP 911 spec. available? use 10- digit admin. number? mobilitycallback number to PSAP? caller location to PSAP? PSAP modificatio n ALI (DB) modification new services I1 nowallowedstationaryno none I2 Dec nostationary nomadic yes no (8 or 10 digit) updatenone I3 late 2004nostationary nomadic mobile yes IP-enabledALI not needed MSAG replaced by DNS location in- band GNP multimedia international calls

IETF 61 (November 2004) ECRIT6 Location-based call routing – UA knows its location GPS 48° 49' N 2° 29' E INVITE DHCP outbound proxy server 48° 49' N 2° 29' E  Paris fire department

IETF 61 (November 2004) ECRIT7 Requirements: Emergency identifier A1: Universal –elements in call path need to recognize emergency call for special handling –cannot use traditional numbers – too many, changing, conflicts with non-emergency numbers A2: Local –users need to be able to dial the local emergency number (112, 911) even if device was bought non- locally A3: Recognizable –proxies and other elements need to recognize emergency calls –location insertion, security, routing A4: Minimal configuration A5: Secure configuration

IETF 61 (November 2004) ECRIT8 Requirements: caller location L1: Multiple location providers –end system & “network” L2: Civic and geographic –precise geo not always available (e.g., within building) “Room 345, 3 rd floor” more useful than “125’ above sea level” –provide both if generated –allow for in-path translations (geocoding) L3: Location-source identification L4: Ascertain validity of location information –could be combined with call testing –existing system: MSAG (street and address range)

IETF 61 (November 2004) ECRIT9 Requirements: Identifying the correct PSAP Decentralized routing –cannot have a global PSAP-level directory –must respect current political and organizational hierarchies (and rivalries…) I1: Correct PSAP I2: Early routing I3: Choice of PSAPs –local vs. public I4: Assuring PSAP identity I5: Traceable resolution

IETF 61 (November 2004) ECRIT10 Requirements: identifying the correct PSAP I6: Assuring directory identity I7: Query response integrity I8: Assuring directory update integrity I9: Call setup latency I10: Multiple directories –no global or nationwide database –but delegation ok

IETF 61 (November 2004) ECRIT11 I11: Referral I12: Multiple query protocols I13: Robustness –work as long as PSAP itself is reachable I14: Incrementally deployable I15: Testable –check if call reaches right PSAP without tying up PSAP call taker resources Requirements: identifying the correct PSAP

IETF 61 (November 2004) ECRIT12 Caller identity C1: Allow (but not mandate) caller identification C2: Privacy override –can’t rely on user to manually enable delivery of location information –user may not be aware of device operation e.g., phone in hotel or when visiting friend

IETF 61 (November 2004) ECRIT13 Requirements: Call setup S1: authentication override –place emergency call even if not subscribed to service S2: mid-call features –disable transfer or hold S3: testable –all aspects, including media path (NATs!) S4: integrity –signaling & media

IETF 61 (November 2004) ECRIT14 Elements: configuration Location-dependent configuration of available emergency numbers –e.g., 911 in North America, 112 in Europe Can use SIP configuration mechanisms, but may not be available or correspond to number boundary

IETF 61 (November 2004) ECRIT15 Architecture Elements: Identification Use Similar to conventions for URIs (RFC xxx) Can be handled at multiple locations in call path If all else fails, user’s home domain does routing –can be tested ahead of time –no need to rely on borrowed device or hotel proxy

IETF 61 (November 2004) ECRIT16 Architecture: routing Can take place at –UAC –outbound proxy –home domain May be done at multiple levels: –UAC routes to country-level emergency call proxy –country-level proxy routes to state/province, etc. –parts of path may be hidden behind firewall

IETF 61 (November 2004) ECRIT17 Routing core requirements Both civic and geo coordinates –conversion from civic to geo may introduce errors –need to check validity of civic addresses –thus, need to map both point-in-polygon and hierarchical strings Delegation –service boundaries follow arcane political maps –mapping updates must be done at local level Scaling –global directory Caching –can’t go to root directory for each call –must work even if routing machinery is temporarily unavailable Reliable –WAN-scale automated replication

IETF 61 (November 2004) ECRIT18 Routing proposals DNS –map civic to labels –e.g., 313.westview-ave.leonia.bergen.nj.us.sos.arpa –store (by reference) geo boundaries TRIP –similar notion of hierarchical resolution, but not based on numbers –not clear that dynamic updates are particularly useful here IRIS –XML-based query protocol used for domain name registrar information, but easily generalizable –would need to deal with referrals –uses SRV for redundancy LDAP

IETF 61 (November 2004) ECRIT19 Open issues Is this the right modularity? –location conveyance, call identification, routing, configuration What existing protocols are suitable for location-based lookups? Worry about existing SIP devices? –do not recognize emergency calls –cannot query directory service

IETF 61 (November 2004) ECRIT20 Open issues: directory Multiple directory operators for each geographic area? Is location  PSAP mapping public or “secret”? –i.e., only high-level routing exposed e.g., all calls for US go to one SIP address –hard to do testing with secret data –likely to be supportable by most directory solutions

IETF 61 (November 2004) ECRIT21 A note on timing Hardest problem is call routing –but may only implemented be relatively few systems (proxies) –or, at least, can be implemented in proxies only But need to solve call identification real soon now (somewhere): –needs to be implemented in end devices –very useful even for I2, not just I3 –e.g., needed for authorizing location disclosure –SIP-specific: could be solved in SIPPING