Clarifying the latest thinking on emergency access from the Internet Telecoms Regulation

1
Clarifying the latest thinking on emergency
access from the InternetTelecoms Regulation
Competition LawBrussels, 26. October 2005

• Richard Stastny, ÖFEG

The opinions expressed here may or may not be
that of my company
2
Content

• The current and future situation
• The basic emergency call requirements
• The problems to be solved
• The location problem
• The international situation
• A phased approach is necessary
• FCC and NENA
• Emergency Calls on the Internet
• IETF ECRIT
• A migration strategy

3
The Current Situation

• Consumers are accustomed to reach emergency
  services within their country from fixed and
  mobile devices at any time.
• With the introduction of the European (global)
  emergency number 112 this is also possible from
  mobile phones abroad.
• But with mobile phones some restrictions of
  location detection and identification were
  introduced, which are eliminated only recently.
• Currently the conventional voice telephony is
  supplemented and eventually replaced with new
  communication methods.

4
New Communication Methods

• The consumer basically does not care about
  technology,
• especially if the consumers device is looking
  similar and has similar functionality like a
  phone
• Although the consumer is expecting new
  functionality from new communication methods,
• he is expecting also that the familiar
  functionality continues to exist
• This definitely includes the possibility to make
  emergency calls
• What are these new communication methods?

5
The Internet

• The Internet is (or is intended to be) a network
  without central intelligence gt the stupid
  network
• The Internet is based on the end-to-end principle
• Every user may reach any other user via the IP
  address
• All services may be offered anywhere and may be
  accessed from everywhere
• This is of course also valid for voice and other
  communication services
• Voice and other communications do not need a
  service provider at all, they are applications.

6
VoIP

• Voice-over-IP, also Internet Telephony, IP
  Telephony oder IP Communications
• A VoIP Service Provider may offer its services
  globally
• The End-User may use these services from any
  Internet Access globally (separation of service
  and access)
• Many VoIP Provider provide the possibility to
  reach PSTN subscribers (OutCalls) and to be
  reached by PSTN subscribers (InCalls)
• There are some restrictions and national
  differences regarding the E.164 Numbers available
  for InCalls
• Additional problem. Two End-Users on the Internet
  may also communicate without using a service
  provider. VoIP is an application, not a
  service.
• -gt Peer-to-peer (P2P) networks

7
The IETF SIP Trapezoid
DNS Server
Location Server
DNS
SIP
Inbound Proxy Server
Outbound Proxy Server
SIP
SIP
SIP
Media (RTP)
User Agent A
User Agent B
Henry Sinnreich and Alan Johnston
8
VoIP and IP Communications on the Internet
Internet
DNS SRV lookup fwd.pulver.com
SIP
SIP
server
server
sip19343_at_fwd.pulver.com
sip19343_at_fwd.pulver.com
session
sipaxelm_at_nic.at43.at
sipmah_at_nic.at43.at
sip18341_at_fwd.pulver.com
sip19343_at_fwd.pulver.com
9
THE Basic Requirement

• From any with the Internet connected device it
  MUST be possible at any time
• to contact the ECC/PSAP responsible for the
  current location
• without dependency on a certain protocol
  infrastructure (e.g. SIP proxies)
• and with the most appropriate method for
  communication for the user, the device and the
  ECC/PSAP, e.g. voice, text and video.

10
The Basic Emergency Call Problems

• Determine that a call is an emergency call
• Route the call to the correct ECC(PSAP)
• Include the location of the caller so help can be
  dispatched to the right place
• Include a way to call back if disconnected
• Provide caller identity
• Prevent DoS attacks to the PSAP
• Guarantied PSAP reachability
• Provide additional means of communication (Text,
  Video, )
• Provide automatic emergency calls (e.g. from
  vehicles)

ECC Emergency Call center PSAP Public Safety
Answering Point
11
The Location Problem

• Example
• A German using a VoIP service provider from the
  US,
• is traveling to Austria and
• connects to the Internet via a WiFi Hotspot
  (eventually using a VPN connection)
• Now he needs to make an emergency call.
• Basic problem to be solved
• Route the call to the PSAPin Austria responsible
  for this location

12
IETF-Architecture for Emergency Services
(Coordinate Adsress),ES Type -gt PSAP
ITSP
GPS
Selfprovision
Sipsos.police_at_bmi.gv.at
Internet
Location
IAP
IP2Geo
13
International Situation

• Situation in Europe
• European Framework
• European Regulators Group (ERG)
• CEPT ECC TRIS
• ETSI EMTEL
• National consultations
• General consensus light touch, no final
  conclusions
• Situation in the US
• FCC
• NENA
• Common consensus that finally a global solution
  is required

14
Phased Approach Necessary

• The IETF approach assumes the PSAP is accessible
  via the Internet.
• This is currently not the case.
• Most countries have already recognized that a
  phased approach is necessary
• Phase 1 basically a quick and dirty solution
  (allow emergency calls from national
  interconnected VoIP Service Providers)
• Phase 2 routing of VoIP to the existing national
  emergency system (including the usage of existing
  databases) and to ECCs or PSAPs connected to the
  PSTN
• Phase 3 direct routing of emergency calls on the
  Internet only
• Requires PSAPs connected directly to the Internet
  via VoIP (SIP)

15
Different National Solutions

• For Phase 1 and 2 different national solutions
  are required and also implemented.
• This will cause (and is already causing) problems
  for global VoIP service providers
• Problem 1 it is difficult for a global VoIP
  service provider to interact with numerous
  different national implementations
• Problem 2 What are the criteria for a VoIP
  service provider to be required or allowed to
  interact with the national emergency system?
• All responsibilities are currently with the VoIP
  service providers

16
New responsibilities and obligations

• Currently the service providers have the primary
  obligation to provide access to the PSAPs of the
  emergency service call takers
• This obligations will change in future to other
  entities
• Device manufacturers
• Access provider, enterprises
• Operating system manufacturers
• Infrastructure in the environment
• Infrastructure on the Internet (DNS)
• So why load currently ALL obligations on the
  service providers, if this has to change in the
  near future anyway?

17
New Ruling from FCC

• FCC-05-116A1 E911 Requirements for IP-Enabled
  Service Providers
• First Report and Order and Notice of Proposed
  Rulemaking (Adopted May 19, 2005)
• Contains
• Definitions, Background Information
• Discussion
• Proposed Rulemaking (Consultation)
• Tentative Final Rules
• Tentative Final rules to be implemented with 120
  days
• Only applicable to interconnected VoIP
  providers
• Calls must be routed via E911 Wireline network to
  default state PSAP
• Must provide user possibility to update location
  (manually)
• Customers must be made aware of restrictions

18
Critical issues raised in response to the FCC
rules

• Only for Interconnected VoIP providers
• Definition of two-way voice communication unclear
• Scope restricted to registered locations within
  the coverage of wireline 911
• Does an Austrian VoIP provider need to comply to
  these requirements if I register in hotel in the
  US?
• Etc.
• But, many of these issues are covered in the
  consultation for further discussion.

19
Example Phase 2 i2 from NENA

• About NENA
• Industry participants, state agencies and
  commissions, public safety officials and PSAPs,
  and the Association of Public-Safety
  Communications Officials - International, Inc.
  (APCO) have been working together under the
  auspices of NENA to develop solutions that will
  lead to VoIP subscribers receiving E911
  functionality.
• Specifically, NENA is expected to publish within
  the next few months an I2 standard designed to
  allow VoIP providers to deliver 911 calls through
  the Wireline E911 Network with call back numbers
  and location information.
• In parallel, NENA and others are working also on
  an I3 standard allowing direct access to PSAP
  via the Internet.

20
NENA Public Review for I2

• NENA Interim/Migratory Solution for VoIP E9-1-1
  Posted for Public Review
• NENA announces the start of the 20 day public
  review period for NENAs Interim Solution
  standard (short name I2) on August 22, 2005. This
  is NENAs first major standard on VoIP and E9-1-1
  system interface, and is an interim solution for
  VoIP telecommunications service providers to
  provide full Enhanced 9-1-1 service through
  current E9-1-1 infrastructure. The draft standard
  is available for review and comments through the
  NENA web site.
• Click here to read the PDF.
• Click here to read the official press release PDF.

21
NENA i2
22
Phase 3

• Phase 3 should solve these problems by allowing a
  direct routing from the device to the PSAP
• The basic intention is to create a globally
  compatible and consistent system.
• IETF ECRIT

23
IETF ECRIT Work Group

• ECRIT Emergency Context Resolution using
  Internet Technologies
• BOF IETF61(Washington, Nov. 2004)
• BOF Chairs Jon Peterson, Hannes Tschofenig
• Official WG, first meeting in Minneapolis
  (IETF62) on March 9
• Chairs Hannes Tschofenig, Marc Linsner
• Working group had an interim meeting in New York
  (Columbia University), May 2005
• Charter Page
• http//www.ietf.org/html.charters/ecrit-charter.ht
  ml
• Weblog
• http//www.ietf-ecrit.org
• Narrowly chartered to deal with how to route
  emergency calls.
• You would like to learn more about the IETF
• Look at IETF Education Team http//edu.ietf.org/

24
ECRIT Topics (1/2)

• Terminology and requirements
• Threats and Security Considerations
• Identify an Emergency Call

• Currently actively discussed
• draft-taylor-ecrit-security-threats-00.txt
• draft-ietf-ecrit-requirements-00.txt

25
ECRIT Topics (2/2)

• Mapping protocol
• ... and some more topics
• Good news IETF protocols offer a good source for
  reuse.

26
ECRIT Relationships

• IETF Geopriv Working Group
• Location Information based on GML (civic and
  geospatial) http//www.ietf.org/internet-draft
  s/draft-ietf-geopriv-pidf-lo-03.txt
• Distribution of location information in DHCP
  RFC 3825 http//www.ietf.org/internet-drafts/dr
  aft-ietf-geopriv-dhcp-civil-07.txt
• SIP working group
• Plenty of SIP protocol specific work
• Session Initiation Protocol Location Conveyance
  http//www.ietf.org/internet-drafts/draft-ietf
  -sip-location-conveyance-01.txt

27
Architectural Considerations (1/3)

• Who knows the location of the end host?
• Often the access network, the Internet service
  provider and the application service provider are
  different parties.

OSI Model
Common point - The end device!
VoIP, Inc. (Application Service Provider)
Layer 7
ISP, Inc. (Internet Service Provider)
Layer 3
Last Mile, Inc. (Access Provider)
Layer 2
28
Architectural Considerations (2/3)

• SIP Proxy

extract locationidentity determine
language determine media
911
Contact PSAP
Phone
Fetch Location
PSAP
Determine PSAP
Distributed Directory
Query / Response Protocol
48 49' N 2 29' E ? Paris fire department

• Assumption Network intermediary is able to
  obtain location of end host.

29
Architectural Considerations (3/3)
extract user locationidentity determine
language determine media
Contact PSAP
PSAP
Phone
Fetch Location
Query / Response Protocol
determine PSAP location
Distributed Directory
48 49' N 2 29' E ? Paris fire department
30
Next Steps Develop Mapping Protocol (1/2)

• A few proposals are available for discussion
• Location-to-URL Mapping Protocol (LUMP)
• http//www.ietf.org/internet-drafts/draft-schul
  zrinne-ecrit-lump-00.txt
• Emergency Call Information in the Domain Name
  System (DNS-SOS)
• http//www.ietf.org/internet-drafts/draft-rosen
  -dns-sos-02.txt
• An IRIS Schema for Emergency Service Contact URIs
  (ECON)
• http//www.ietf.org/internet-drafts/draft-hardi
  e-ecrit-iris-01.txt
• Requirements and security threats need to be
  understood before the work on the mapping
  protocols can be completed.

31
Next Steps Challenges (2/2)

• A number of security threats need to be
  addressed.
• The typical solution, namely cryptography, cannot
  be applied in all cases.
• Difficult part Denial of Service
• Example Adversary places an emergency call and
  attaches the wrong location information.

Denial of Service Layers of Defense
32
How to get from here to there

• IETF ECRIT is working on a future solution to
  enable IP end-points to communicate with IP PSAPs
• But most PSAPs are still on the PSTN and can only
  be reached via national specific emergency
  systems
• Regulators currently are requesting the
  capability to make emergency calls from
  Interconnected VoIP providers (only) i.e.
  POTSoIP providers
• This is not a good idea
• Any VoIP provider MUST be able to provide their
  customers the capability to make emergency calls
• But one cannot expect especially from global VoIP
  providers to interface with all national specific
  emergency systems
• So VoIP providers will need some assistance
• Proposal provide national default Emergency
  Service Routing Proxies (ESRP) feeding the calls
  to national or state default PSAPs
• This could be improved gradually and seamlessly
  to comply with future solutions

33
i2 i3 Combined
Martin Merka
34
Call Flow

• The device or the VoIP provider is querying the
  mapping database with the location available (e.g
  country only)
• It gets back a SIP URI to the ESRP (or to the SIP
  PSAP)
• The ESRP is querying a national (or the global)
  mapping DB, to retrieve the national routing
  information (e.g a TEL URI with national context)
• The ESRP is forwarding the call to the ESGW to
  reach the PSAP on the PSTN (in the above case the
  state default PSAP)
• The ESRP may provide a temporary pseudo-CLI for
  call back to callers without E.164 number (or
  e.g. with an international number)
• Gradually SIP PSAPs are introduced and the
  mapping database is updated accordingly

35
Add Access to National Location DB
Martin Merka
36
Call Flow

• In some countries a Location Database may exist
  (e.g. ALI or EISEC in UK)
• The ESRP may push the location information
  provided by the caller to this database
• The pseudo-CLI may serve as a temporary key to
  the location information in this database
• Only the national ESRP need to be aware of the
  national location DB

37
The End

• Thank you

Richard Stastny ÖFEG 43 664 420
4100 richard.stastny_at_oefeg.at http//voipandenum.b
logspot.com