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

About This Presentation
Title:

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

Description:

Requirements and Architecture for Emergency Calling draft-schulzrinne-sipping-emergency-arch draft-schulzrinne-sipping-emergency-req Henning Schulzrinne – PowerPoint PPT presentation

Number of Views:83
Avg rating:3.0/5.0
Slides: 22
Provided by: ietfOrgpr
Learn more at: https://www.ietf.org
Category:

less

Transcript and Presenter's Notes

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


1
Requirements and Architecture for Emergency
Callingdraft-schulzrinne-sipping-emergency-archd
raft-schulzrinne-sipping-emergency-req
  • Henning Schulzrinne
  • Columbia University

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

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

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
  • L1L3 may know about location (at least
    approximately), but dont know about emergency
    calls

5
Three stages to VoIP 911
6
Location-based call routing UA knows its
location
GPS
INVITE sipssos_at_
48 49' N 2 29' E
outbound proxy server
DHCP
48 49' N 2 29' E ? Paris fire department
7
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

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)

9
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

10
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

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

12
Caller identity
  • C1 Allow (but not mandate) caller identification
  • C2 Privacy override
  • cant 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

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

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

15
Architecture Elements Identification
  • Use sipsos_at_home-domain
  • Similar to conventions for URIs (RFC xxx)
  • Can be handled at multiple locations in call path
  • If all else fails, users home domain does
    routing
  • can be tested ahead of time
  • no need to rely on borrowed device or hotel proxy

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

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
  • cant go to root directory for each call
  • must work even if routing machinery is
    temporarily unavailable
  • Reliable
  • WAN-scale automated replication

18
Routing proposals
  • DNS
  • map civic to labels
  • e.g., 313.westview-ave.leonia.bergen.nj.us.sos.arp
    a
  • 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

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

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

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
Write a Comment
User Comments (0)
About PowerShow.com