Requirements and Architecture for Emergency Calling draft-schulzrinne-sipping-emergency-arch draft-schulzrinne-sipping-emergency-req

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

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

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) ECRIT 3

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 – L 1—L 3 may know about location (at least approximately), but don’t know about emergency calls IETF 61 (November 2004) ECRIT 4

Three stages to Vo. IP 911 spec. available? use 10 digit admin. number? mobility callback number to PSAP? caller location to PSAP? PSAP modificatio n ALI (DB) modification new services I 1 now allowed stationary no no none I 2 Dec. 2004 no stationary nomadic yes no (8 or 10 digit) update none I 3 late 2004 no stationary nomadic mobile yes IP-enabled ALI not needed MSAG replaced by DNS location inband GNP multimedia international calls IETF 61 (November 2004) ECRIT 5

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

Requirements: Emergency identifier • A 1: Universal • A 3: Recognizable – elements in call path need to recognize emergency call for special handling – cannot use traditional numbers – too many, changing, conflicts with non -emergency numbers • A 2: Local – proxies and other elements need to recognize emergency calls – location insertion, security, routing • A 4: Minimal configuration • A 5: Secure configuration – users need to be able to dial the local emergency number (112, 911) even if device was bought nonlocally IETF 61 (November 2004) ECRIT 7

Requirements: caller location • L 1: Multiple location providers – end system & “network” • L 2: 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) • L 3: Location-source identification • L 4: Ascertain validity of location information – could be combined with call testing – existing system: MSAG (street and address range) IETF 61 (November 2004) ECRIT 8

Requirements: Identifying the correct PSAP • Decentralized routing – cannot have a global PSAP -level directory – must respect current political and organizational hierarchies (and rivalries…) • I 1: Correct PSAP • I 2: Early routing IETF 61 (November 2004) • I 3: Choice of PSAPs – local vs. public • I 4: Assuring PSAP identity • I 5: Traceable resolution ECRIT 9

Requirements: identifying the correct PSAP • I 6: Assuring directory identity • I 7: Query response integrity • I 8: Assuring directory update integrity IETF 61 (November 2004) • I 9: Call setup latency • I 10: Multiple directories – no global or nationwide database – but delegation ok ECRIT 10

Requirements: identifying the correct PSAP • I 11: Referral • I 12: Multiple query protocols • I 13: Robustness – work as long as PSAP itself is reachable • I 14: Incrementally deployable • I 15: Testable – check if call reaches right PSAP without tying up PSAP call taker resources IETF 61 (November 2004) ECRIT 11

Caller identity • C 1: Allow (but not mandate) caller identification • C 2: 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) ECRIT 12

Requirements: Call setup • S 1: authentication override – place emergency call even if not subscribed to service • S 2: mid-call features – disable transfer or hold • S 3: testable – all aspects, including media path (NATs!) • S 4: integrity – signaling & media IETF 61 (November 2004) ECRIT 13

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) ECRIT 14

Architecture Elements: Identification • Use sip: sos@home-domain • 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) ECRIT 15

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) ECRIT 16

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) ECRIT 17

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) ECRIT 18

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) ECRIT 19

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) ECRIT 20

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 I 2, not just I 3 e. g. , needed for authorizing location disclosure SIP-specific: could be solved in SIPPING IETF 61 (November 2004) ECRIT 21