1 / 21

Henning Schulzrinne Columbia University

Requirements and Architecture for Emergency Calling draft-schulzrinne-sipping-emergency-arch draft-schulzrinne-sipping-emergency-req. Henning Schulzrinne Columbia University. Big picture. Get citizen emergency call to emergency call center (Public Safety Answering Point) = PSAP

shaina
Télécharger la présentation

Henning Schulzrinne Columbia University

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. Requirements and Architecture for Emergency Callingdraft-schulzrinne-sipping-emergency-archdraft-schulzrinne-sipping-emergency-req Henning Schulzrinne Columbia University ECRIT

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

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

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

  5. Three stages to VoIP 911 ECRIT

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

  7. 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 Requirements: Emergency identifier ECRIT

  8. 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, 3rd 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) ECRIT

  9. 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 Requirements: Identifying the correct PSAP ECRIT

  10. 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 Requirements: identifying the correct PSAP ECRIT

  11. Requirements: identifying the correct PSAP • 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 ECRIT

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

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

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

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

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

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

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

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

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

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

More Related