200407_tris_emergency_services_stastny.ppt
TRANSCRIPT
![Page 1: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/1.jpg)
1July 2004 Richard Stastny
Emergency ServicesECC TRIS
Vienna, July 2004
Richard Stastny, ÖFEG*
* The opinions expressed here may or may not be that of my company
![Page 2: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/2.jpg)
July 2004 Richard Stastny 2
Introduction
• The discussion in Europe on the treatment of Emergency Services with VoIP started:– with the Analysys Report to the EC, regarding access to ES
and PATS– the activities in the US between IETF, NENA and the VON
Coalition• One of the major issues is the provision of location
information of the caller to be used for call routing and also to be displayed at the PSAP.
• On the other hand a lot has been undertaken already in Europe, US and Japan to provide enhanced location information to PSAPs for calls from mobile phones
• Many solutions proposed and implemented could be re-used also for calls from VoIP.
![Page 3: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/3.jpg)
July 2004 Richard Stastny 3
Content
• Regulatory Status in Europe• Basic Emergency Call Problems• Work at IETF• Major topics• Emergency Services Obligations• Proposal for a staged approach
![Page 4: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/4.jpg)
July 2004 Richard Stastny 4
EU Position on Emergency Services*
• Access to Emergency services is extremely important for citizens, irrespective of how a telephone service may be classified for legal and regulatory purposes.
• The Universal Service Directive has an explicit requirement that access to emergency services has to be offered by providers of PATS, but there is no similarly explicit obligation for providers of ECS who may be offering a telephone service.
• From a public policy point of view it is desirable that access to emergency services is available from as wide a range of electronic communications services as possible.
• This calls for an evolutionary approach in cooperation with the emergency authorities.
• In principle, National Regulatory Authorities could impose an obligation on certain ‘non-PATS’ service providers to offer emergency service access, under Condition (8) of Annex A of the Authorisation Directive on “Consumer Protection Rules specific to the electronic communications sector”.
* The Treatment of VoIP under the EU Regulatory Frameworkhttp://europa.eu.int/information_society/topics/ecomm/doc/useful_information/library/commiss_serv_doc/406_14_voip_consult_paper_v2_1.pdf
![Page 5: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/5.jpg)
July 2004 Richard Stastny 5
Proposal of consulation paper
• However the practicalities of call routing and handling have not yet been resolved by the market, and until they are, such an obligation may not be technically feasible and could be disproportionate.
• It is proposed that:– NRAs could require suppliers of VoIP services that include
access to the public telephone network to give precise information to customers on how the VoIP supplier deals with access to emergency services and caller location.
– Such information should be provided in the customer contract drawn up in accordance with Article 20 of the Universal Service Directive.
• The Commission will regularly review evolution in this area.
![Page 6: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/6.jpg)
July 2004 Richard Stastny 6
… on Routing of Emergency Calls
• The possibility to route a call to the nearest Emergency Service centre implies that the service provider (either publicly available ECS or PATS) has sufficient information to allow the call to be correctly routed.
• This is only possible if the location of the user making the emergency call is known in some way or another, and the service provider knows the nearest emergency service centre to which the call should be routed.
• Currently, with some VoIP based services, in particular ‘nomadic’ services, the VoIP service provider has no knowledge of the physical location of the caller nor of the nearest emergency service centre.
• It would be disproportionate at the present stage of market development to impose such routing obligations on all VoIP providers.
![Page 7: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/7.jpg)
July 2004 Richard Stastny 7
… on PATS and PAECS
• in the case of PATS, – the actual making of an emergency call, and the
provision of caller location information to emergency services, should be possible without the user having to input any location information either before making the emergency call or when initially installing the terminal device.
– This probably means that the provider of such service needs to conclude some agreement with the provider of the underlying transport infrastructure (!)
• in the case of publicly available ECS, – NRAs could require that the making of a call to the
emergency services happens without the user having to provide any location information.
– The user may be invited to provide location information when initially installing the terminal device at a particular location.
![Page 8: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/8.jpg)
July 2004 Richard Stastny 8
… expects solutions from market players
• At the current state of the market, it is advisable not to present an undue burden on market players, but it will be necessary to follow developments in this area closely as the market evolves.
• In the case of those ECS and PATS services where users have the possibility to move their terminal, and where this causes a problem for the undertaking to determine the users’ location, users need to be warned that when moving their terminals from agreed fixed location, they can not be guaranteed to be provided with emergency services.
• Market players offering VoIP based services are encouraged to devise and rapidly implement operational solutions for the effective handling of calls to emergency services (ok, will do).
![Page 9: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/9.jpg)
July 2004 Richard Stastny 9
… on Caller Location
• In the context of PATS, Member States are to ensure that undertakings that operate public telephone networks make caller location information available to authorities handling emergencies for calls to the European Emergency call number ‘112’.
• In the Directives the provision of this location information is made dependant of the technical feasibility.
• Considering the importance of providing location information it is proposed that:– NRAs encourage all undertakings offering PATS at fixed
locations to provide location information.– This may imply some form of agreement between the
operator offering the PATS service and the underlying provider of the transport infrastructure.
• The Privacy Directive foresees that, where Calling-Line Identification is offered, an undertaking may override a users’ elimination of the presentation of this CLI, for calls to organisations dealing with emergency calls.
![Page 10: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/10.jpg)
July 2004 Richard Stastny 10
… on Caller Location (cont.)
• Given the importance for emergency services of both the location and CLI information, Member States should encourage the provision of this information, both for PATS and for publicly available ECS.
• Market players offering VoIP based services are encouraged to devise and rapidly implement operational solutions for the effective transmission of caller ID and the provision of location information for calls to emergency services
• The Commission will regularly review evolution in this area.
![Page 11: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/11.jpg)
July 2004 Richard Stastny 11
Or in other words
• a flawed (best-effort) access to emergency services is better than none
• new technologies should be given some time to evolve– e.g. mobile services took more than 10 years*
• because they may finally provide better services then currently available and possible
• much of the work done already for providing caller location to PSAPs for E112 could also be used for VoIP (databases, interfaces, …)
![Page 12: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/12.jpg)
July 2004 Richard Stastny 12
Status of mobile networks
• Mobile phones have no power supply
• Reachability of emergency services is not guarantied
• Ok, could route the call to the correct ECC, but:
• No location information for 10 years
• No identification for SIM-less calls (on the contrary, this is a requirement)
• 200.000.000 pre-paid cards out in Europe without identification
![Page 13: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/13.jpg)
July 2004 Richard Stastny 13
Statements
• “The ability to call for help in times of an emergency is not ‘voluntary’ – it’s mandatory.” – David F. Jones, VP NENA (Testimony at the
FCC Hearing)
• “The use of IP protocols could provide the emergency systems with … expanded services, more resilient networks and faster response times“– Henning Schulzrinne
![Page 14: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/14.jpg)
July 2004 Richard Stastny 14
The basic Emergency Call Problems
• Determine a call is an emergency call
• 4 basic requirements:– Locate the caller
– 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
• In addition:– Provide caller identity
– Guaranty ECC (PSAP) reachability
![Page 15: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/15.jpg)
July 2004 Richard Stastny 15
Some work has already be done
• IETF• US
– E911 (NENA, APCO, VON Coalition, …)
• Europe– E112 (CGALIES, LOCUS, ETSI, LIF, …)– UK (EISEC)– …
![Page 16: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/16.jpg)
July 2004 Richard Stastny 16
Current IETF drafts
• draft-taylor-sipping-emerg-scen-01– scenarios, e.g., hybrid VoIP-PSTN
• draft-schulzrinne-sipping-emergency-arch-00– overall architecture for emergency calling
• draft-ietf-sipping-sos-00– describes ‘sos’ SIP URI
• draft-rosen-dns-sos-00– new DNS resource records for location mapping
![Page 17: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/17.jpg)
July 2004 Richard Stastny 17
Major topics
• Common URI for emergency calls sip:[email protected] (and 112 and 911)
• Use the global DNS to store information on emergency numbers, ESRP, ECC service areas
• Use different means to retrieve location information (DHCP, GPS, RFID, GSM, …)
• Push location information to ECC or let ECC subscribe to location information
• Use authentication and TLS during call setup• For more info see presentations of Brian Rosen
and the current work of IETF
![Page 18: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/18.jpg)
July 2004 Richard Stastny 18
Architectural assumptions and goals by IETF
• SIP-based for interchange • International (global)
– devices bought anywhere can make emergency calls anywhere
– limit biases in address formats, languages, …– avoid built-in bias for “911” or “112” (mostly)
• Support other communications modes– IM, SMS, MMS, video, email
• Support access for callers with disabilities– real-time text– video for sign language
![Page 19: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/19.jpg)
July 2004 Richard Stastny 19
Common URL for emergency services
• Emergency numbers may be dialed from many different places– about 60 (national) different emergency service numbers in the
world– many are used for other services elsewhere (e.g., directory
assistance)• IETF draft suggests “sip:sos@home-domain”
– home-domain: domain of caller• Can be recognized by proxies along the way
– short cut to emergency infrastructure• If not, it reaches home proxy of subscriber• Call can be routed from there easily
– global access to routing information (see later)• allows also service identification “sip:sos.fire@home-domain”• 112 and 911 should always be available (VoIP dialing plans
needed)• Default configuration if no other information available:
– 000, 08, 110, 999, 118 and 119– needs definitely further study
![Page 20: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/20.jpg)
July 2004 Richard Stastny 20
Using the global DNS
• Emergency number configuration• Determining the PSAP/ECC where the
call should be routed to• service area of PSAP/ECC• new infrastructure domain sos.arpa
proposed
![Page 21: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/21.jpg)
July 2004 Richard Stastny 21
Determining locations
• Either network-provided or terminal-provided• Conveyed via DHCP from IP-level provider
– Formats:• geospatial (longitude, latitude, altitude or floor)• civil (country, administrative units, street)
– Provider usually knows– Does not depend on being a voice service provider
• 802.11 triangulation• GPS (for ALL mobile devices)• RFID tags in rooms• Via configuration protocol (XCAP)
– relies on VSP having accurate service location information
• User-configured (last resort)
![Page 22: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/22.jpg)
July 2004 Richard Stastny 22
How does the ECC find the caller’s location?
• Largest difference to existing E911 system• In-band, as part of call setup
– carried in body of setup message– rather than by reference into external database
• May be updated during call– moving vehicles– late availability of information (GPS acquisition delay)
• Also possible: subscribe to location information (proposed method – see below)
![Page 23: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/23.jpg)
July 2004 Richard Stastny 23
Privacy and authentication
• Want to ensure privacy of call setup information
• prevent spoofing of call origins– but can’t enforce call authentication
• need to authenticate call destination– ideally, certificate for ECCs– but initially just verify that reached DNS-indicated
destination
• use TLS (SSL), as in https://• host certificates widely available
– just need a domain name and a credit card
![Page 24: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/24.jpg)
July 2004 Richard Stastny 24
Testing emergency calls
• Current E911 system has no good way to test 911 reachability without interfering with emergency services
• With VoIP, more distributed systems more need for testing
• Use SIP OPTIONS request route request, but don’t reach call taker
• Also, DNS model allows external consistency checking– e.g., nationwide 911 testing agency
![Page 25: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/25.jpg)
July 2004 Richard Stastny 25
How does VoIP (IPC) differ from landline and wireless PSTN?
• Telephone companies are no longer needed– there are still carriers for DSL and
cable “IP dial tone”– but unaware of type of data carried– IPCSP may be in another state or
country– Corporations and universities don’t
have email carriers, either– even residential users may have
servers• Addresses (Names) may be non-
numeric (not E.164)• Media is not necessarily voice
voice service provider
(RTP)
Backbone(IP)
Access(WiFi
Yahoo
MC
ISta
rbuck
s
User
![Page 26: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/26.jpg)
July 2004 Richard Stastny 26
Take away messages
• Phones (terminals) must change– Learn location (GPS, DHCP,..)– Learn local emergency number from DNS– Recognize emergency call– Include location on the emergency call
• Proxy servers must change– Recognize emergency call– Route to ECC based on location (using DNS)
• All elements must implement sips: (TLS)• ISPs must implement DHCP location
![Page 27: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/27.jpg)
July 2004 Richard Stastny 27
Emergency Services Obligations
• Currently telephony service providers have obligations regarding emergency services
• This should be reconsidered with VoIP (IP Communications in general) and especially if Broadband may be considered as the Universal Service of the future– In this case contact to emergency services could also
be multimedia and made in addition to voice also by messaging, video and even via a web browser
– depending on terminal capabilities
![Page 28: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/28.jpg)
July 2004 Richard Stastny 28
There will be obligations to
• terminal providers: – to receive, store and forward location information (GPS)
• access providers, ISPs and enterprises: – to provide location information via DHCP and/or other
means (mobile)• operating systems and application SW:
– to provide minimum set of capabilities and recognize emergency requests (sos in browser?)
• building infrastructure: – to provide RFIDs in rooms
• DNS infrastructure (sos.arpa.):– to provide ECC/PSAP locations and emergency numbers
• communications service providers: – to handle and route emergency calls properly
• emergency routing proxies– to feed location databases, provide pseudo CLIs, route calls
to ECC/PSAPs or other ESRP.• ECC/PSAPs:
– be able to use information provided
![Page 29: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/29.jpg)
July 2004 Richard Stastny 29
How location information is retrieved
• All location information is gathered by the terminal
• either network provided– DHCP– Mobile triangulation– WiFi triangulation
• or by the terminal itself– From the user– Via GPS– Via RFID
• and transmitted in an emergency call at call setup (INVITE) or during the call (NOTIFY)
• together with the location information also the source is transmitted, multiple information is possible.
![Page 30: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/30.jpg)
July 2004 Richard Stastny 30
Proposal for a staged approach
0. the existing situation1. from the Internet via VoIP to PSAPs/ECCs on
the PSTN/ISDN with enhancements2. from the Internet to PSAPs/ECCs also
connected to the Internet using IPC3. both PSAP/ECC and User are using NGN
to access emergency services from IP-based networks
![Page 31: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/31.jpg)
July 2004 Richard Stastny 31
Stage 0
• No problem for VoIP provided at a fixed location using geographic numbers or for users with FXO life-line
• For nomadic users:– Emergency calls always routed to home PSAP/ECC for a
given subscriber or– emergency calls only possible if location is provided to
VoIP SP manually, but• how can this information be provided to PSAP/ECC in time?
– recognition by PSAP/ECC via CLI of non-geographic number
• better then nothing• but problem of call routing to correct PSAP/ECC still exists
• No access to emergency services for IP-only providers with no E.164 number?
![Page 32: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/32.jpg)
July 2004 Richard Stastny 32
Stage 0
Internet PSTN
DNS
IPCSPs
Gateway Operator
PSAPs/ECCs
Terminal Adapter with FXO life-line
IPCSP need access to local gateway operators
fixed users nomadic users
![Page 33: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/33.jpg)
July 2004 Richard Stastny 33
Proposed Architecture Stage 1
• PSAPs/ECC still on PSTN, using existing technology• All emergency calls are routed via the (Home)
Emergency Service Routing Proxy (ESRP)• Users may subscribe directly, giving his
preferences – in this case the ESRP is also a SIP- and presence server
• Subscriber needs to identify himself at subscription time
• ESRP guaranties the subscriber to disclose identity and location information only to emergency services (or on user push)
• ESRP implements the local (national) policy
![Page 34: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/34.jpg)
July 2004 Richard Stastny 34
Stage 1 (cont.)
• Location information is either entered manually by user or transmitted from the device
• ESRP is able to map location information to routing information to proper PSAP/ECC by using local databases or the DNS
• ESRP is able to provide PSAP/ECC with screened CLI• For calls from users without E.164 number a pseudo number
(CLI) may be set up• PSAPs/ECCs need only to have narrow-band Internet access to
retrieve the presence information indexed by CLI (watcher)• If location of user is out-side of ESRP boundary, the call may be
routed easily (and trusted) to other ESRPs• These ESRP may be found via sos.arpa• Devices or applications need to be able to support more then
one line – indication of availability of ES recommended
![Page 35: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/35.jpg)
July 2004 Richard Stastny 35
Stage 1 direct
Internet PSTN
DNSIPCSP
Gateway Operator
PSAPs/ECCs
Terminal Adapter with FXO life-line
ECC looks up name and location informationESRP
CLI presented to ECC
location
lookup ECC
![Page 36: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/36.jpg)
July 2004 Richard Stastny 36
Usage of existing databases
• If a database for providing location information for fixed and mobile calls is already existing
• this database and the related interfaces may be used for VoIP too
• e.g. in UK– Enhanced Information Service for
Emergency Calls (EISEC SIN 278) and – Emergency Location Information Interface
ND1013:2002/11
![Page 37: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/37.jpg)
July 2004 Richard Stastny 37
Stage 1 via IPCSP
Internet PSTN
DNSIPCSP
Gateway Operator
PSAPs/ECCs
Terminal Adapter with FXO life-line
ECC looks up name and location information
ESRP
CLI presented to ECC
location
lookup ECC
location and identity
![Page 38: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/38.jpg)
July 2004 Richard Stastny 38
Forward to foreign ESRP
Internet PSTN
DNS
home ESRP
Gateway Operator
PSAPs/ECCs
Terminal Adapter with FXO life-line
ECC looks up name and location informationforeign ESRP
CLI presented to ECC
location
lookup ECC
![Page 39: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/39.jpg)
July 2004 Richard Stastny 39
Advantages of this approach
• IPCSP need not to be involved in emergency services
• Users may not trust IPCSP regarding identity and location information
• Reachability of ES may be better guarantied• No E.164 number required• Identity also possible with prepaid services• Global connectivity achieved more easily• Implementation of local policies possible• Call back to contact address possible
![Page 40: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/40.jpg)
July 2004 Richard Stastny 40
Migration to Stage 2
• No or minor changes required in ESRP
• If PSAP/ECC decides to migrate to VoIP, calls are not routed via the gateway, but directly to the SIP-server of the PSAP/ECC
• Name and location information will be transmitted directly
• Location information may be dispatched directly to emergency vehicles
![Page 41: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/41.jpg)
July 2004 Richard Stastny 41
Stage 3
• Left to ETSI and EMTEL
• Stage 3 would be the full support of emergency services in NGN environments for which various work items have been opened. ETSI needs to ensure that they are aligned with NENA for this future network scenario.
![Page 42: 200407_TRIS_Emergency_Services_Stastny.ppt](https://reader036.vdocuments.us/reader036/viewer/2022062515/55d522eebb61eb5d7d8b465e/html5/thumbnails/42.jpg)
July 2004 Richard Stastny 42
The End
Thank you
Richard StastnyÖFEG
+43 664 420 4100