NENA Interim VoIP Architecture For E-911 I2

NENA Interim VoIP Architecture for
Enhanced 9-1-1 Services (i2)
NENA Interim VoIP Architecture for Enhanced 9-1-1 Services (i2)

NENA 08-001, Version 2
Standards Advisory Board approval date, June 18, 2010
NENA Executive Board approval date, August 11, 2010
Prepared by:
National Emergency Number Association (NENA) VoIP/Packet Technical Committee
Published by NENA
Printed in USA

NENA 08-001 v2, August 11, 2010
NENA
TECHNICAL STANDARD DOCUMENT
NOTICE
The National Emergency Number Association (NENA) publishes this document as a guide for the
designers and manufacturers of systems to utilize for the purpose of processing emergency calls. It
is not intended to provide complete design specifications or to assure the quality of performance of
such equipment.
NENA reserves the right to revise this TSD for any reason including, but not limited to:
conformity with criteria or standards promulgated by various agencies

utilization of advances in the state of the technical arts
or to reflect changes in the design of equipment or services described herein.
It is possible that certain advances in technology will precede these revisions. Therefore, this NENA
TSD should not be the only source of information used. NENA recommends that readers contact
their Telecommunications Carrier representative to ensure compatibility with the 9-1-1 network.
Patents may cover the specifications, techniques, or network interface/system characteristics
disclosed herein. No license expressed or implied is hereby granted. This document shall not be
construed as a suggestion to any manufacturer to modify or change any of its products, nor does this
document represent any commitment by NENA or any affiliate thereof to purchase any product
whether or not it provides the described characteristics.
This document has been prepared solely for the use of E9-1-1 Service System Providers, network
interface and system vendors, participating telephone companies, etc.
By using this document, the user agrees that NENA will have no liability for any consequential,
incidental, special, or punitive damages arising from use of the document.
NENAs Technical Committee has developed this document. Recommendations for change to this
document may be submitted to:
National Emergency Number Association
4350 N Fairfax Dr, Suite 750
Arlington, VA 22203-1695
800-332-3911
or: techdoccomments@nena.org
Version 2, August 11, 2010
Page 2 of 247

NENA 08-001 v2, August 11, 2010
Acknowledgments:
The National Emergency Number Association (NENA) VoIP/Packet Technical Committee
developed this document.
NENA recognizes the following industry experts and their companies for their contributions in
development of this document.
Version 2, Approval Date, August 11, 2010
Members
Company
Nate Wilcox Technical Committee Chair
Microdata
Roger Marshall Technical Committee
TCS
Vice-Chair
Anand Akundi, WG Leader and Technical Telcordia Technologies
Editor
Michael Armstrong
Verizon
Delaine Arnold
Arnold 9-1-1 Consulting
Eric Arolick
Telcordia Technologies
Tim Barry
AT&T
Marc Berryman
Greater Harris County 9-1-1
Patty Bluhm
Intrado
Tom Breen
AT&T
Guy Caron
Bell Canada
Randall Gellens
Qualcomm
Ken Maynard
Bexar Metro 9-1-1 Metro District
Theresa Reese
Brian Rosen
Neustar
Robert Sherry
Intrado
Maureen Stork
Verizon Business
Hannes Tschofenig
Nokia Siemens Network
James Winterbottom
Andrew Corporation
This committee would also thank Tom Breen, Tony Busam and Roger Hixson for their support and
assistance.
Page 3 of 247

NENA 08-001 v2, August 11, 2010
TABLE OF CONTENTS
1
EXECUTIVE OVERVIEW .............................................................................................................................. 9
1.1 PURPOSE AND SCOPE OF DOCUMENT .................................................................................................................... 9

1.2 REASON TO IMPLEMENT........................................................................................................................................ 9
1.3 BENEFITS .............................................................................................................................................................. 9
2
INTRODUCTION ............................................................................................................................................ 10
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
OPERATIONAL IMPACTS SUMMARY .................................................................................................................... 10

SECURITY IMPACTS SUMMARY ........................................................................................................................... 10
DOCUMENT TERMINOLOGY ................................................................................................................................ 10
REASON FOR ISSUE/REISSUE ............................................................................................................................... 11
RECOMMENDATION FOR ADDITIONAL DEVELOPMENT WORK ............................................................................ 12
DATE COMPLIANCE ............................................................................................................................................ 12
ANTICIPATED TIMELINE...................................................................................................................................... 12
COSTS FACTORS ................................................................................................................................................. 12
FUTURE PATH PLAN CRITERIA FOR TECHNICAL EVOLUTION .............................................................................. 12
COST RECOVERY CONSIDERATIONS ............................................................................................................... 13
ADDITIONAL IMPACTS (NON COST RELATED) ................................................................................................. 13
INTELLECTUAL PROPERTY RIGHTS POLICY .................................................................................................... 13
ACRONYMS/ABBREVIATIONS ......................................................................................................................... 13
TECHNICAL DESCRIPTION ....................................................................................................................... 15
3.1 GENERAL ASSUMPTIONS ..................................................................................................................................... 15

3.2 OVERVIEW OF INTERCONNECTION TO CONVENTIONAL E9-1-1 SYSTEMS ........................................................... 17
3.3 DESCRIPTION OF FUNCTIONAL ELEMENTS .......................................................................................................... 19
3.3.1 User Agent (UA) ....................................................................................................................................... 19
3.3.2 VoIP Endpoint (VEP) ............................................................................................................................... 19
3.3.3 Server........................................................................................................................................................ 20
3.3.4 Call Server ................................................................................................................................................ 20
3.3.5 Proxy or Proxy Server/Policy and Routing Server ................................................................................... 20
3.3.6 Redirect Server/Call Relay Server ............................................................................................................ 20
3.3.7 Emergency Services Gateway (ESGW)..................................................................................................... 20
3.3.8 Emergency Service Zone Routing Data Base (ERDB) ............................................................................. 21
3.3.9 VoIP Positioning Center (VPC)................................................................................................................ 21
3.3.10
Validation Data Base (VDB) ............................................................................................................... 22
3.3.11
Location Information Server (LIS)....................................................................................................... 23
3.3.12
Root Discovery Service (RDS) ............................................................................................................. 23
3.4 DESCRIPTION OF 9-1-1 DATA OBJECTS ............................................................................................................... 23
3.5 INTERFACE DEFINITIONS..................................................................................................................................... 26
3.5.1 v0 LIS to VoIP Endpoint ........................................................................................................................ 26
3.5.2 v1 VoIP Endpoint to Call Server/Proxy................................................................................................. 27
3.5.3 v2 Call Server or Routing Proxy or Redirect Server to VPC................................................................. 27
3.5.4 v3 VPC to LIS ......................................................................................................................................... 27
3.5.5 v4 Call Server/Routing Proxy to ESGW ................................................................................................ 28
3.5.6 v5 Call Server/Proxy to Redirect Server................................................................................................ 28
3.5.7 v6 Call Server to Routing Proxy ............................................................................................................ 28
3.5.8 v7 LIS to VDB ........................................................................................................................................ 28
3.5.9 v8 VPC to ERDB ................................................................................................................................... 29
Page 4 of 247

NENA 08-001 v2, August 11, 2010
3.5.10
v9 LIS/VPC to Root Discovery Operator .......................................................................................... 29
3.5.11
v-E2 VPC to ALI DB ......................................................................................................................... 29
3.6 LOCATION INFORMATION SCENARIOS................................................................................................................. 29
3.6.1 Endpoint Stores Location ......................................................................................................................... 30
3.6.2 LIS Stored Location Key ........................................................................................................................ 30
3.7 CALL ROUTING SCENARIOS ................................................................................................................................ 30
3.7.1 Basic Call Routing of VoIP Emergency Calls to ESGW........................................................................... 32
3.7.2 Proxy Redirect Server............................................................................................................................... 34
3.7.3 Routing Proxy Routing Scenario .............................................................................................................. 36
3.7.4 ESGWRI-based Routing Translations ...................................................................................................... 37
3.8 CALL ROUTING FAILURE SCENARIOS ................................................................................................................. 38
3.8.1 Abnormal Conditions Detected at the Call Server/Proxy ......................................................................... 38
3.8.2 Abnormal Conditions Detected at the VPC .............................................................................................. 39
3.8.3 Abnormal Conditions Detected at the ESGW ........................................................................................... 41
3.8.4 Default Routing at the Selective Router.................................................................................................... 41
3.8.5 Summary of Contingency/Default Routing ............................................................................................... 41
3.9 LOCATION VALIDATION...................................................................................................................................... 44
3.10
ROOT DISCOVERY SERVICE (RDS) ................................................................................................................ 45
3.10.1
Root Discovery Assumptions................................................................................................................ 45
3.10.2
Root Discovery..................................................................................................................................... 46
3.10.3
VDB Directory File Format ................................................................................................................. 50
3.10.4
ERDB directory file format .................................................................................................................. 53
3.10.5
ERDB Directory File Format Geodetic Coverage............................................................................ 56
3.11
PSAP CALL CONTROL FEATURES .................................................................................................................. 59
3.11.1
Requirements ....................................................................................................................................... 61
3.11.2
ESGW Interworking Requirements ...................................................................................................... 62
4
SECURITY ....................................................................................................................................................... 63
4.1
4.2
4.3
4.4
4.5
4.6
4.7
AUTHENTICATION ............................................................................................................................................... 63
MESSAGE INTEGRITY .......................................................................................................................................... 64
MESSAGE ENCRYPTION....................................................................................................................................... 64
NETWORK ELEMENT SECURITY .......................................................................................................................... 64
NETWORK LAYER SECURITY .............................................................................................................................. 64
APPLICATION LAYER SECURITY ......................................................................................................................... 65
LOCATION DATA SECURITY ................................................................................................................................ 65
FUNCTIONAL REQUIREMENTS ............................................................................................................... 67
5.1 VSP CALL SERVER/PROXY ................................................................................................................................. 67

5.1.1 Authentication and Authorization ............................................................................................................. 68
5.1.2 Performance ............................................................................................................................................. 68
5.1.3 Reliability and Availability ....................................................................................................................... 68
5.2 ROUTING PROXY SERVER ................................................................................................................................... 69
5.2.2 Performance ............................................................................................................................................. 69
5.3 REDIRECT SERVER .............................................................................................................................................. 69
5.3.2 Performance ............................................................................................................................................. 70
5.4 EMERGENCY SERVICES GATEWAY (ESGW) ....................................................................................................... 70
Page 5 of 247

NENA 08-001 v2, August 11, 2010
5.4.2 Performance ............................................................................................................................................. 72
5.5 ESZ ROUTING DATABASE (ERDB) .................................................................................................................... 72
5.5.1 Receiving and Storing Routing Information ............................................................................................. 72
5.5.2 Processing Routing Queries ..................................................................................................................... 73
5.5.4 Performance ............................................................................................................................................. 81
5.6 VOIP POSITION CENTER (VPC) .......................................................................................................................... 81
5.6.1 Support for Emergency Call Routing ....................................................................................................... 81
5.6.2 Delivery of Location Information ............................................................................................................. 87
5.6.4 Performance ............................................................................................................................................. 90
5.7 VALIDATION DATA BASE (VDB) ........................................................................................................................ 90
5.7.1 Storage of MSAG Validation .................................................................................................................... 90
5.7.2 Perform Validation ................................................................................................................................... 91
5.7.4 Performance ............................................................................................................................................. 93
5.8 LOCATION INFORMATION SERVER (LIS)............................................................................................................. 93
5.8.1 Detailed LIS Requirements ....................................................................................................................... 94
5.8.2 LIS Query Protocol and Location Information Format ............................................................................ 95
5.8.3 Validated Address to PIDF-LO Mapping ................................................................................................. 95
5.8.5 Performance ............................................................................................................................................. 96
5.9 AUTOMATIC LOCATION IDENTIFICATION (ALI) DATABASE................................................................................ 97
5.9.2 Performance ............................................................................................................................................. 97
6
DETAILED INTERFACE SPECIFICATIONS............................................................................................ 98
6.1 V0 LIS TO VOIP ENDPOINT .............................................................................................................................. 98

6.2 V1 VOIP ENDPOINT TO CALL SERVER .............................................................................................................. 98
6.3 V2 CALL SERVER/ROUTING PROXY/REDIRECT SERVER TO VPC ..................................................................... 99
6.3.1 v2 Message Definitions ............................................................................................................................. 99
6.3.2 v2 Message Call Flows, Key Scenarios and Semantics .......................................................................... 115
6.3.3 v2 Interface Security ............................................................................................................................... 121
6.4 V3 VPC TO LIS .............................................................................................................................................. 121
6.5 V4 - CALL SERVER/ROUTING PROXY TO ESGW ............................................................................................... 122
6.5.1 v4 Interface Architecture ........................................................................................................................ 122
6.5.2 v4 Interface Call Flow ............................................................................................................................ 123
6.5.3 v4 Message Parameters .......................................................................................................................... 125
6.5.4 Specification of the v4 interface ............................................................................................................. 126
6.5.5 v4 SIP Messages Examples..................................................................................................................... 128
6.5.6 Assumptions ............................................................................................................................................ 131
6.6 V5 CALL SERVER/PROXY TO REDIRECT SERVER ............................................................................................ 131
Page 6 of 247

NENA 08-001 v2, August 11, 2010
6.6.1 Technical Description............................................................................................................................. 131
6.6.4 Specification of the v5 Interface ............................................................................................................. 140
6.6.5 SIP Exchange Example........................................................................................................................... 144
6.6.6 v5 Security Requirements ....................................................................................................................... 149
6.7 V6 CALL SERVER TO ROUTING PROXY INTERFACE ........................................................................................ 149
6.7.1 v6 Interface Architecture ........................................................................................................................ 149
6.7.4 Specification of the v6 interface ............................................................................................................. 154
6.7.5 v6 SIP Message Examples ...................................................................................................................... 155
6.7.7 v6 Interface Assumptions ........................................................................................................................ 158
6.8 V7 LIS TO VDB ............................................................................................................................................. 158
6.8.1 v7 Message Definitions ........................................................................................................................... 158
6.8.2 v7 Message Flows, Key Scenarios and Semantics .................................................................................. 166
6.9 V8 INTERFACE - VPC TO ERDB........................................................................................................................ 169
6.9.1 v8 Message Definition ............................................................................................................................ 170
6.9.2 v8 Message Flows, Key Scenarios and Semantics .................................................................................. 181
6.9.3 Security ................................................................................................................................................... 185
6.10
V9 INTERFACE LIS/VPC TO RDS .............................................................................................................. 185
6.10.1
v9 Messages Definitions .................................................................................................................... 185
6.10.2
v9 Message Flows, Key Scenarios and Semantics ............................................................................. 191
6.10.3
v9 Interface Security .......................................................................................................................... 193
6.11
V-E2 INTERFACE ALI TO VPC .................................................................................................................. 193
6.11.1
v-E2 Message Definitions .................................................................................................................. 194
6.11.2
Emergency Services Protocol (ESP) Parameters .............................................................................. 198
6.11.3
v-E2 Message flows, Key Scenarios and Semantics........................................................................... 203
6.11.4
v-E2 Interface Security ...................................................................................................................... 207
7
ROLES AND RESPONSIBILITIES ............................................................................................................ 208
7.1 RESPONSIBILITIES ............................................................................................................................................. 210

7.1.1 Caller ...................................................................................................................................................... 210
7.1.2 VoIP Service Provider ........................................................................................................................... 210
7.1.3 Redirect Operator ................................................................................................................................... 211
7.1.4 Routing Proxy Operator ......................................................................................................................... 211
7.1.5 LIS Operator........................................................................................................................................... 211
7.1.6 ESGW Operator...................................................................................................................................... 211
7.1.7 Selective Router (SR) Operators ............................................................................................................. 212
7.1.8 PSAP Operators ..................................................................................................................................... 212
7.1.9 ALI Operator .......................................................................................................................................... 212
7.1.10
VPC Operator .................................................................................................................................... 213
7.1.11
Credential Authority .......................................................................................................................... 214
7.1.12
Routing Number Authority (RNA) ...................................................................................................... 215
7.1.13
Master Street Address Guide (MSAG) Source ................................................................................... 216
7.1.14
Validation Database (VDB) Operator ............................................................................................... 217
7.1.15
Emergency Routing Database (ERDB) Operator .............................................................................. 217
7.1.16
Root Discovery Operator (RDO) ....................................................................................................... 218
Page 7 of 247

NENA 08-001 v2, August 11, 2010
7.1.17
9-1-1 Administrator ........................................................................................................................... 218
RECOMMENDED READING AND REFERENCES................................................................................ 220
EXHIBITS (INFORMATIVE) ..................................................................................................................... 223
9.1 POTENTIAL ALI CHANGES ................................................................................................................................ 223

9.1.1 Purpose ................................................................................................................................................... 223
9.1.2 Overview ................................................................................................................................................. 223
9.1.3 Potential Changes Required to Support i2 Solution ............................................................................... 223
9.2 RULES FOR ADDRESS ABBREVIATION ............................................................................................................... 225
9.2.1 Resources for Abbreviation Matching .................................................................................................... 225
9.3 MSAG TO POSTAL ADDRESS COMPARISON ...................................................................................................... 226
9.4 ERDB DISCOVERY USING GEODETIC INFORMATION ........................................................................................ 230
9.4.1 Polygon Definition.................................................................................................................................. 230
9.4.2 Endpoint (Subscriber) Location Representation .................................................................................... 231
9.4.3 ERDB Root Discovery Provisioning ....................................................................................................... 233
9.4.4 ERDB Root Discovery Operation ........................................................................................................... 235
9.5 WEB SERVICES ................................................................................................................................................. 237
9.5.1 Standards used........................................................................................................................................ 237
9.5.2 Key Points regarding Web Services ....................................................................................................... 237
9.5.3 Substitution of Special Characters ......................................................................................................... 238
9.6 V7 CLIENT CONSIDERATIONS/RECOMMENDATIONS .......................................................................................... 239
9.6.1 Overview ................................................................................................................................................. 239
9.6.2 Wiremap LIS ........................................................................................................................................... 239
9.7 CALL ROUTING PERFORMANCE GUIDELINES .................................................................................................... 241
9.8 ISSUES UNDER INVESTIGATION ......................................................................................................................... 245
10
PREVIOUS ACKNOWLEDGMENTS ........................................................................................................ 246
Page 8 of 247

NENA 08-001 v2, August 11, 2010
Executive Overview
Voice over Internet Protocol (VoIP) is poised to become the predominant technology used in the
telecommunications industry. As the public adopts VoIP, E9-1-1 calls will increasingly originate
from VoIP users. Some VoIP telecommunications service provider networks, however, are not
natively compatible with the existing E9-1-1 infrastructure. This document outlines an architecture
to connect emergency callers in the IP domain with Public Safety Answering Points (PSAPs)
supported by the existing E9-1-1 network infrastructure. This interim step in the migration towards
end-to-end IP networks is referred to as i2.
1.1
Purpose and Scope of Document
This document is the NENA recommended standard for the i2 architecture to support the
interconnection of VoIP domains with the existing Emergency Services Network infrastructure in
support of the migration toward end-to-end emergency calling over the VoIP networks between
callers and PSAPs.
This document provides an overview of the VoIP architecture, functional elements, and interfaces, as
well as the interface specifications necessary for interconnection with the existing Emergency
Services Network infrastructure.
This issue of the i2 standard supports E9-1-1 for fixed and nomadic VoIP services. Support for
mobile VoIP services will be covered in a future release of this document.
This document does not include specifications for the methods used to determine location nor how
the endpoint actually receives location. The document does provide pointers to other specifications
that could be used to provide location to the endpoint.
1.2
Reason to Implement
VoIP is being introduced into the North American environment by VoIP Service Providers (VSPs).
NENA and a number of the VSPs acting through the Voice on the Net (VON) Coalition reached
agreement to support current NENA and industry work towards long-term solutions that include (a)
delivery of 9-1-1 calls to the proper PSAP; (b) providing callback number/contact information to the
PSAP; (c) providing the location of the caller; and (d) PSAPs having direct IP connectivity. The
initial standards development work of the NENA VoIP/Packet Committee was completed by the end
of 2005. The architecture described in this standard reflects that initial work as well as the evolution
of the i2 Solution architecture definition since that time.
This recommended standard is being provided to facilitate the development and implementation of
interoperable, standard equipment and processes to support VoIP emergency services calling
throughout North America.
1.3
Benefits
Use of this document will:

Page 9 of 247

NENA 08-001 v2, August 11, 2010
Ensure that equipment and service providers that conform to these recommendations will
have a solution that is interoperable,
Foster development of network elements and processes that can be reused in the architecture that
supports end-to-end IP calling to the PSAP.
Introduction
2.1
Operational Impacts Summary
Operational impacts include:
2.2
Additional data provided to the PSAP. In order to differentiate VoIP emergency calling,
VoIP calls will be distinguishable and new data elements pertinent to VoIP calls will be
provided to call takers. This may impact both call taking procedures and training of call
takers.
New processes required. Call routing will be based on the callers location which will be
matched to routing information contained in routing databases. With this architecture, VoIP
caller addresses may not be stored in Automatic Location Identification (ALI) databases, but
must still be Master Street Address Guide (MSAG) valid. This will require comparison with
information contained in new validation databases. New processes to populate and maintain
these routing and validation databases must be developed and implemented.
Default Routing. Some calls will be placed without location information available, making
location-based routing virtually impossible. Some form of default routing for those calls will
have to be implemented. Handling of those calls will have operational implications for the
PSAPs receiving the calls.
Security Impacts Summary
The critical nature of the E9-1-1 Emergency Services Network makes it essential to ensure that the
E9-1-1 network is properly protected. The i2 solution introduces new network elements, new
underlying transport networks and protocols to the E9-1-1 Emergency Services network. Note that a
number of protocol interfaces are outside the scope of the 9-1-1 system (v0/v1) and several are
between elements that are considered to be within the 9-1-1 system (v2, v3, v4, v5, v6, v7, v8, v9
and v-E2). The former are specified by other standards organizations, such as the IETF. The latter
are defined in this document. For the interfaces within the scope of this document, the security
mechanisms are dependent on the specifics of the underlying network joining the various i2 solution
network elements.
2.3
Document Terminology
The terms "shall", "must" and "required" are used throughout this document to indicate required
parameters and to differentiate from those parameters that are recommendations. Recommendations
are identified by the words "desirable" or "preferably".
Page 10 of 247

NENA 08-001 v2, August 11, 2010
2.4
Reason for Issue/Reissue
NENA reserves the right to modify this document. Upon revision, the reason(s) will be provided in
the table below.
Version
Original
2
Approval Date
12/06/2005
8/11/2010
Reason For Changes

Initial Document
Reasons Listed Below
Version 2: This document was originally issued to identify the minimum requirements and desirable
network elements for VSP interconnection with the E9-1-1 Service Provider infrastructure for
delivery of emergency calls and associated callback, location, and service provider information,
equivalent to conventional wireline and wireless callers.
Version 2 of this document is published for the following reasons:
Clarify the status of E9-1-1 services on mobile VoIP;

Further define requirements for ERDB/VDB Root Discovery mechanisms;
Further define ERDB discovery mechanism using geodetic information;
Add the v9 Interface specification;
Specify supported geodetic shapes;
Specify VDB/ERDB data synchronization solution;
Specify mechanisms to convey the callback number in the signaling path in both the IP
domain and the Emergency Services Network;
Specify an ESQK guard timer value;
Normalize i2 message names;
Specify Default ESQK pools mechanism;
Specify the UA behavior in regard to supplementary services during emergency calls;
Specify a solution to support call delivery to non-E9-1-1-enabled PSAPs;
Specify a method to convey the subscriber name in the signaling path of the IP domain;
Replace the ESRN solution with a new concept: ERT & ESGWRI;
Specify a solution for the ERDB to provide default routing data;
Specify a solution to signal geodetic information from the IP domain into the Emergency
Services Network;
Specify support for PSAP call control features;
Editorial modifications for overall document coherence & consistency including various
updates to reflect progress is other SDO work.
Depreciation of the v3 interface
NOTE Due to the above changes, this issue of the Standard is not backwards compatible with
Issue 1 of this document
Page 11 of 247

NENA 08-001 v2, August 11, 2010
2.5
Recommendation for Additional Development Work
No additional external Standards development work has been identified in support of this Standard.
2.6
Date Compliance
All systems that are associated with the 9-1-1 process shall be designed and engineered to ensure
that no detrimental, or other noticeable impact of any kind, will occur as a result of a date/time
change up to 30 years subsequent to the manufacture of the system. This shall include embedded
application, computer based or any other type application.
To ensure true compliance, the manufacturer shall upon request, provide verifiable test results to an
industry acceptable test plan such as Telcordia GR-2945 or equivalent.
2.7
Anticipated Timeline
This architecture is intended to be implemented in the near term. It provides the technological
approach required to meet the objectives agreed to by NENA and the VON Coalition. Prior to
implementation, further agreement must be reached on roles and responsibilities for developing,
operating and maintaining the network elements called for in the architecture.
2.8
Costs Factors
Implementation of the architecture outlined in this document will require the deployment of a
number of new network elements. Each of the new elements must be provisioned, operated, and
maintained. In addition new databases are required, which will further require the development and
maintenance of new supporting processes.
2.9
Future Path Plan Criteria for Technical Evolution
In present and future applications of all technologies used for 9-1-1 call and data delivery, it is a
requirement to maintain the same level or improve on the reliability and service characteristics
inherent in present 9-1-1 system design.
New methods or solutions for current and future service needs and options should meet the criteria
below. This inherently requires knowledge of current 9-1-1 system design factors and concepts, in
order to evaluate new proposed methods or solutions against the Path Plan criteria.
Criteria to meet the Definition/Requirement:
1. Reliability/dependability as governed by NENAs technical standards and other generally
accepted base characteristics of E9-1-1 service
2. Service parity for all potential 9-1-1 callers
3. Least complicated system design that results in fewest components to achieve needs
(simplicity, maintainable)
4. Maximum probabilities for call and data delivery with least cost approach
Page 12 of 247

NENA 08-001 v2, August 11, 2010
5. Documented procedures, practices, and processes to ensure adequate implementation and
ongoing maintenance for 9-1-1 systems
This basic technical policy is a guideline to focus technical development work on maintaining
fundamental characteristics of E9-1-1 service by anyone providing equipment, software, or services.
2.10 Cost Recovery Considerations
Traditionally, much of the cost of the existing E9-1-1 Service Provider infrastructure has been
supported through the collection of fees and surcharges on wireline and wireless telephone service.
New network elements in the IP Domain will need to be paid for in some manner. Additionally, as
VoIP service replaces traditional voice services that currently support the E9-1-1 Service Provider
infrastructure, existing fee collections will decline and must be replaced.
2.11 Additional Impacts (non cost related)
The information or requirements contained in this NENA document are known to have both
technical and operational impacts, based on the analysis of the authoring group, and development
has been started.
2.12 Intellectual Property Rights Policy
NENA takes no position regarding the validity or scope of any Intellectual Property Rights or other
rights that might be claimed to pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights might or might not be available;
nor does it represent that it has made any independent effort to identify any such rights.
NENA invites any interested party to bring to its attention any copyrights, patents or patent
applications, or other proprietary rights that may cover technology that may be required to
implement this standard.
Please address the information to:
National Emergency Number Association
4350 N Fairfax Dr, Suite 750
Arlington, VA 22203-1695
800-332-3911
or: techdoccomments@nena.org
2.13 Acronyms/Abbreviations
Some acronyms/abbreviations used in this document have not yet been included in the master
glossary. After initial approval of this document, they will be included. See NENA 00-001 [39] NENA Master Glossary of 9-1-1 Terminology located on the NENA web site for a complete listing
of terms used in NENA documents.
Page 13 of 247

NENA 08-001 v2, August 11, 2010
The following Acronyms are used in this document:
Acronym
Description
ERT
ESGWRI
Emergency Route Tuple

Emergency Services Gateway Route Identifier
** N)ew
(U)pdate
N
N
Page 14 of 247

NENA 08-001 v2, August 11, 2010
Technical Description
This section provides an overview of the i2 migratory solution architecture recommended by NENA
for supporting emergency calls originated in the IP domain and terminated using the Public Switched
Telephone Network (PSTN) emergency services infrastructure.
3.1
General Assumptions
It is assumed that one goal of the i2 solution architecture is to make no changes that will
affect the PSAP.
It is assumed that one goal of the i2 solution architecture is to minimize changes in the
existing providers of 9-1-1 infrastructure (e.g. SR provider, ALI provider, etc.), although
the i2 architecture does not preclude providers of 9-1-1 infrastructure from providing
additional services in the IP domain.
It is assumed that existing processes used for wireless carriers can be used to cause the
Selective Routing Databases (SRDBs) and ALI DBs to be populated with the appropriate
shell records for the Emergency Services Query Keys (ESQKs) used in this architecture.
The i2 solution supports the receipt of both civic and geodetic location information as
input to emergency call routing decisions. This enables the solution to route calls
regardless of the format of the location provided by the source. It is expected that the
location provided by the originating network and chosen for routing purposes by the
VoIP Positioning Center (VPC) will be included in the location information that is
provided to the PSAP. The location provided to the PSAP will be in the same form (civic
or geodetic) that was received by the VPC.
The call setup signaling in the IP domain described in this document uses Session
Initiation Protocol (SIP) as specified in Internet Engineering Task Force (IETF) Request
For Comments (RFC) 3261[5] (plus other supporting work in IETF), and additional
requirements described or identified in this standard. Where IP domains use other
protocols (e.g., ITU-T H.323), it is assumed that they will support emergency parameters
(e.g. location) for inter-working with various interfaces and with SIP when required.
A Valid Emergency Services Authority (VESA) registry will be used to provide
certification of entities that are authorized to query for and view location information for
any given emergency call instance it is requested to process.
The various agencies that are needed to play a role for this solution to work will step up
to their roles and responsibilities.
Location information may, in general, be presented by the VoIP end point by one of two
methods: Civic or geodetic. However, civic location is required for non-wireless fixed
and nomadic types of service, with geodetic location optionally sent as supplemental
information in addition to the civic location for these service types. Civic location
presented to the PSAP is expected to be MSAG Validated.
Page 15 of 247

NENA 08-001 v2, August 11, 2010
The ERDB and VDB service must be provided by the same operating entity.
The 9-1-1 authority will determine the single ERDB/VDB provider that will service a
specific geographic area. For example, a State 9-1-1 Authority may choose one provider
for its state or designate separate providers for different regions of the state. This will
ensure that the data in the ERDB and VDB is consistent. See Section 6 for further
discussion.
The Internet architecture provides for, and promotes a model that separates connectivity
and access mechanisms from applications and services. This is in contrast to traditional
telephony and communication networks where access infrastructure is provided by the
service provider as a necessity to service connectivity. This document describes an
interim solution for providing emergency services connectivity to VoIP callers. This
architecture places no requirements on any access network provider having to have a predefined relationship with any application service provider in order to enable emergency
services support.
Although this document focuses on VoIP emergency calls routed via SRs and dedicated
trunks to E9-1-1-enabled PSAPs, this solution also supports the routing of VoIP
emergency calls to non-E9-1-1-enabled PSAPs using a 7x24 (E.164) number to route via
the PSTN. The 7x24 number must be obtained from the PSAP coordinator.
The feature interaction behavior specified in NENA 08-502, NENA E9-1-1 Generic
Requirements, is supported by the i2 Solution.
It is assumed silence suppression will be disabled for emergency calls.
When reusing an ESQK due to ESQK exhaust, there will be no expectation that location
will be provided.
It is expected that a VoIP Endpoint (VEP) operating in an i2 environment is capable of
recognizing an emergency call in order to adapt its behavior specifically for processing
emergency calls. For example, special emergency services logic is required to attach
location, or a reference to it, to an originating emergency call, as well as to adapt feature
interactions and silence suppression behaviors. If the VEP is incapable of recognizing an
emergency call, the fall back is to have the VSP Call Server/Proxy always perform this
task.
It is expected that location, or a reference to it, will be presented with each emergency
call, when available. In special circumstances, it may be possible that explicit userdefined usage rules present in the PIDF-LO document be overridden by regulatory-driven
rules.
For VEPs and VSP Call Servers/Proxies destined for the North American market, it is
expected that, at a minimum, the dialed digits 9-1-1 will be recognized as emergency
dialed digits. The VEP and the VSP Call Server/Proxy may be able to recognize other
well known emergency dialed digits (1-1-2 for the EU, 9-9-9 for the UK, etc.).
Page 16 of 247

NENA 08-001 v2, August 11, 2010
Refer to next section for additional assumptions about the i2 solution architecture and relationships
between entities in the architecture.
3.2
Overview of Interconnection to Conventional E9-1-1 Systems
This section provides an overview of the interconnection between the IP domains and the existing
E9-1-1 Emergency Services Provider infrastructure.
Figure 3-1 illustrates the functional elements and signaling interfaces used to support the i2 solution.
The acronyms used to label elements in the diagram are defined in the NENA Master Glossary and
in Section 2.13 of this standard. On the left of the figure are the functional elements of the IP
domain. Some of these represent functional elements used in the SIP architecture and are defined in
IETF RFC 3261[5].
Several new functions are introduced in the i2 solution that assist in:
validation of location information,

routing emergency calls to the appropriate interconnection point with the existing
infrastructure,
providing the interconnection for the IP domain with the existing network elements and
databases needed to support delivery of location information to the PSAP.
Brief descriptions of these new functional elements are provided in Section 3.3, along with
definitions of some of the SIP elements from RFC 3261[5] for convenience.
The IP domain cloud in the figure represents the collective set of IP domains, including multiple
private and public service provider domains, from which emergency calls might originate, and
through which emergency calls are interconnected with the existing emergency services
infrastructure that is shown on the right-hand side of the diagram.
In this document, all the call control interfaces are described using SIP as the example protocol. This
does not preclude providers from using other call control protocols as long as the functionality
described in this document is provided by the other protocol. For example, H.323 [29] is a protocol
that could be used instead of SIP. If other protocols have to be used then it is important that the same
functionality be provided
The logical SIP signaling interfaces between functional elements used for call setup signaling in the
IP domain are represented by dashed lines in the figure. The logical interfaces for the exchange of
location-related data between and among functional elements in the IP domain are represented by
solid lines. The interfaces defined in this standard are labeled (vX) for convenience in referencing
individual interface descriptions. The physical and logical signaling and data exchange interfaces
among existing E9-1-1 network and database elements are defined in other documents.
Page 17 of 247

NENA 08-001 v2, August 11, 2010
Emergency Services
Provider Network
IP domain
PSTN
Routing Proxy &
Redirect Server(s)
PSTN
Gateway
Used for contingency routing

and non-E9-1-1-enabled PSAP
v6
Call Server/
Proxy
ESGW(s)
v5
v4
E9-1-1
Selective
Router(s)
v4
v1
PSAP
v2
VoIP
End
Point
v2
v0
VPC
VPC
VPC
v3
SRDB
v-E2
v8
LIS
ERDB
v9
v7
v9
ALI
VDB
DBMS
MSAG
RDS
Figure 3-1 VoIP Domain Interconnection with Emergency Services Provider Network
This figure is simplified for illustrative purposes, not showing all the interconnection of multiple
entities or mirrored E9-1-1 Selective Routers (SRs), ALI DBs, or new MSAG-based databases used
for VoIP emergency call routing or validation of location. The PSTN cloud is part of the diagram
because the i2 solution allows for the routing of VoIP emergency calls to non-E9-1-1-enabled
PSAPs using E.164 numbers [53] and contingency routing using the PSTN. In cases of failures, it
may be possible for emergency calls to be routed to the appropriate PSAP using the PSTN. It should
be noted that:
There may be multiple VoIP Positioning Centers (VPCs) in any given serving area. The Call
Server/Proxy Server/Redirect Server hosting the v2 interface chooses the VPC for
interconnection.
Page 18 of 247

NENA 08-001 v2, August 11, 2010
A given VPC may have interfaces to one or more ALI DBs. One or more VPCs may have
interfaces to any given ALI DB.
The Emergency Service Zone (ESZ) Routing Database (ERDB) may be distributed across
multiple database repositories in North America, but there is one authoritative source for the
routing data for any given geographic serving area. When the ERDB is implemented apart
from the VPC, it may support routing queries from VESA-certified VPCs in the i2 solution.
The Validation Database (VDB) may be distributed across multiple database repositories in
North America, but there is one authoritative source for the location validation data for any
given geographic serving area.
There will be at least one Emergency Services Gateway (ESGW) interconnected with any
given E9-1-1 SR.
Any given ESGW may be interconnected with one or more E9-1-1 SRs.
At any given time, each VoIP endpoint (VEP)/User Agent (UA) will interact with only one
Location Information Server (LIS) yielding a single unambiguous location or location
reference.
A Call Server (CS) is operated by a VSP. A CS is typically configured to contact contracted
VPC(s) for emergency calls or alternatively, can contract a Redirect Server or Routing Proxy
for this task.
ESGW operators can be regional, similar to SR operators today.
Each VSP operator may contract with one or multiple ESGW operators and a single ESGW
can be reached from multiple VSP operators.
The interfaces shown in Figure 3-1 are described in greater detail in subsequent sections of this
document.
3.3
Description of Functional Elements
This section provides brief high-level descriptions of the functional elements in the IP domain used
to support validation and management of location information, routing of emergency calls, and
delivery of location-related information to network elements and databases in the existing E9-1-1
service provider infrastructure.
3.3.1
User Agent (UA)
As defined for SIP in IETF RFC 3261[5], the User Agent represents an endpoint in the IP domain, a
logical entity that can act as both a user agent client (UAC) that sends requests, and as user agent
server (UAS) responding to requests.
3.3.2
VoIP Endpoint (VEP)
In this document, the term VoIP endpoint is used to refer to the endpoint IP device that is used to
originate an emergency call. It can take the form of a VoIP phone device, a VoIP Analog Terminal
Adaptor (ATA) or a VoIP soft-client application running over a Personal Computer (PC).
Page 19 of 247

NENA 08-001 v2, August 11, 2010
3.3.3
Server
A server is a network element that receives requests in order to service them and sends back
responses to those requests. Examples of servers used in SIP domains are proxies, user agent servers,
redirect servers, and registrars.
3.3.4
Call Server
The term Call Server in this document is used to refer to the entity in a private or public IP domain
that provides service to endpoints in an emergency callers home domain and that interworks with
the SIP servers and other elements in the IP domain used to support emergency services call routing
in the i2 solution. The CS may use SIP or some other VoIP signaling protocol within its own serving
domain.
Functional requirements for the CS in the context of the i2 architecture are described in Section 5.1.
3.3.5
Proxy or Proxy Server/Policy and Routing Server
A policy and routing server in the context of SIP is a proxy server, an intermediary entity that acts
as both a server and a client for the purpose of making requests on behalf of other clients. A proxy
server primarily plays the role of routing, which means its job is to ensure that a request is sent to
another entity closer to the targeted user. Proxies are also useful for enforcing policy (for example,
making sure a user is allowed to make a call). A proxy interprets, and, if necessary, rewrites specific
parts of a request message before forwarding it. (Refer to IETF RFC 3261[5].) It can be a
policy/routing element in other protocols.
Functional requirements for the Routing Proxy (RP) in the context of the i2 architecture are
described in Section 5.2.
3.3.6
Redirect Server/Call Relay Server
In the context of SIP, a call relay server is a redirect server that generates (3xx) redirect responses to
requests it receives, redirecting the client to contact an alternate set of Uniform Resource Identifiers
(URIs). (Refer to IETF RFC 3261[5].) This may be an H.323 Gatekeeper for implementations that
use ITU-T H.323 architectures [29].
Functional requirements for the Redirect Server in the context of the i2 architecture are described in
Section 5.3.
3.3.7
Emergency Services Gateway (ESGW)
The ESGW is the signaling and media inter working point between the IP domain and conventional
trunks to the E9-1-1 SR. It uses either Multi-Frequency (MF) or Signaling System #7 (SS7)
signaling. The ESGW uses the routing information provided in the received call setup signaling (the
ESGWRI) to select the appropriate trunk (group) and proceeds to signal call setup toward the SR
including the ESQK in outgoing signaling. The ESGW may signal only the 10-digit ESQK or, both
the ESQK and callback number to the SR.
Page 20 of 247

NENA 08-001 v2, August 11, 2010
Functional requirements for the ESGW in the context of the i2 architecture are described in Section
5.4.
3.3.8
Emergency Service Zone Routing Data Base (ERDB)
The ERDB contains the routing information associated with ESZs. It supports the boundary
definitions for ESZs and the mapping of civic address or geo-spatial coordinate location information
to a particular ESZ.
For each ESZ, the ERDB contains an Emergency Route Tuple (ERT) consisting of a Selective
Routing Identifier, a routing Emergency Services Number (ESN) that uniquely identifies the ESZ in
the context of that SR, and an NPA that is associated with the outgoing route to the SR. The ERDB
may contain a Contingency Routing Number (CRN) (i.e., a 10-digit 24x7 PSAP number) associated
with the ESZ. The ERDB may also contain an Administrative ESN for the ESZ, when applicable.
Section 5.5.1 provides more details on Administrative ESNs. There is a one-to-many relationship
between an ERT and ESZs.
When an emergency call is originated and location information is received from the VPC, the ERDB
will identify the ESZ and routing information associated with the location information. It will return
the ERT, CRN (if available) and optionally, the administrative ESN to the VPC.
The ERDB supports an interface from one or more VESA-certified VPCs in the i2 solution. The
ERDB may be distributed across multiple database repositories, but there is one authoritative source
for the routing data for any given geographic serving area. Civic location-based routing data in the
ERDB is expected to be based on the same MSAG data used to provide location validation in the
VDB, and also from existing SR network configuration information. The ERDB may support an
interface to the Database Management Systems that manage the MSAG data (to receive updates),
but this interface is not specified in this document.
Functional requirements for the ERDB in the context of the i2 architecture are described in Section
5.5.
3.3.9
VoIP Positioning Center (VPC)
The VPC is the element that provides routing information to support the routing of VoIP emergency
calls. It also cooperates in delivering location information to the PSAP using the existing ALI DB
infrastructure.
The VPC interfaces to the ERDB to obtain routing data.
The VPC receives queries from the CS or RP/RS over the v2 interface.
The information provided in a query over the v2 interface includes callback and subscriber name
information, when available (to be provided to the PSAP so that a call taker can call back an
emergency caller), and a Presence Information Data Format-Location Object (PIDF-LO) [8][37] or
Location Key. The VPC may also receive other information about the call, such as VSP
identification information.
Page 21 of 247

NENA 08-001 v2, August 11, 2010
If the VPC receives a Location Key, the VPC obtains the location information from the identified
LIS.
The VPC uses the received location information to determine the appropriate ERDB to query for the
routing instructions using the Root Discovery mechanisms described in Section 3.9.
The VPC uses the received location information to request routing information from the ERDB that
is associated with the callers location. The VPC may also obtain information from the ERDB to
assist in contingency routing.
Using the routing data received from the ERDB, the VPC temporarily allocates an ESQK to a
particular call instance and stores information associated with that call with the ESQK pending a
subsequent query from an ALI DB.
The VPC may, optionally, be responsible for translating the ERT information received from an
ERDB to an Emergency Services Gateway Route Identifier (ESGWRI). The ESGWRI is used by the
CS/RP to route an emergency call to the correct ESGW, and by the ESGW to select the desired trunk
group path(s) to the appropriate SR for the call.
If the VPC is responsible for translating the ERT to an ESGWRI, it will pass the ESGWRI, ESQK,
and the Last Routing Option (LRO) to the CS/RP/RS in the response to a request for routing
information associated with the emergency call. If the VPC is not responsible for translating the ERT
to an ESGWRI, the VPC will pass the ERT, ESQK, and LRO to the CS/RP/RS in the routing
response.
The VPC de-allocates the ESQK when it receives an indication that the call has ended or when the
guard timer associated with the ESQK assignment expires, whichever occurs first.
Functional requirements for the VPC are described in Section 5.6.
3.3.10 Validation Data Base (VDB)
The VDB contains information that describes the current, valid civic address space defined by the
Emergency Services Network Providers MSAG. The structure of the database is beyond the scope
of this standard. However, the VDB should have the capability to receive a validation request
containing a civic address consisting of data elements included in the civic Location Object (LO)
defined in RFC 4119 [8][37] and as described in NENA 02-010 [11], and be able to determine if
this civic address is a valid address. The VDB will return a response indicating that a given location
is a valid address or an error response. This process ensures that the address is a real address (i.e., the
address exists) but does not ensure that it is the location of the caller.
The VDB may be distributed across multiple databases, for example, with different VDBs serving
different regional areas; however, there will be one primary source of validation data for any given
geographic area or address. NENA 02-013 [38] defines the provisioning and maintenance of the
VDB data.
Page 22 of 247

NENA 08-001 v2, August 11, 2010
Functional requirements for the VDB in the context of the i2 architecture are described in Section
5.7.
3.3.11 Location Information Server (LIS)
A Location Information Server (LIS) is a functional entity that provides locations of endpoints. A
LIS can provide Location-by-Reference, or Location-by-Value, and, if the latter, in geo or civic
forms. A LIS can be queried by an endpoint for its own location, or by another entity for the location
of an endpoint. In either case, the LIS receives a unique identifier that represents the endpoint, for
example an IP address, circuit-ID or Media Access Control (MAC) address, and returns the location
(value or reference) associated with that identifier. The LIS is also the entity that provides the
dereferencing service.
Location information is in the form of civic address or geo-spatial location attributes associated with
a particular physical location. A location reference or location key is an identifier assigned by the
LIS that can be used by an entity that receives it to obtain location information from the LIS, as
described in Section 3.5.12.2.
The LIS is configured with mappings between individual location information and a logical
representation of the physical locations with which they are associated.
For wireline implementations, the wiremap in the LIS is assumed to be configured and maintained
by the entity that provides/maintains the physical or logical access facility for endpoint equipment.
For example, this might be an IT administrator for an enterprise, or an Internet Service Provider
(ISP) or Access Infrastructure Provider (AIP) in non-enterprise/residential VoIP markets. The
administrator/owner of the LIS is responsible for creating and maintaining this wiremap, and for
ensuring that the civic location data is MSAG-validated.
A given endpoint can be associated with a physical location that is mapped to a particular civic
address or geodetic coordinates, and this information is downloaded from the LIS to the endpoint as
described in Section 3.5.12.1.
Functional requirements for the LIS in the context of the i2 architecture are described in Section 5.8.
3.3.12 Root Discovery Service (RDS)
The RDS is the entity that stores the serving areas of ERDBs and VDBs. It accepts queries that
contain geo-spatial or civic location information over the v9 interface. When queried with location
information, it returns a list of URIs for ERDBs or VDBs serving that area.
3.4
Description of 9-1-1 Data Objects
This section identifies 9-1-1 data objects defined in the i2 solution architecture. These data objects
are needed to support routing of emergency calls and delivery of location information to PSAPs. The
use of the data objects and the protocols defined to carry them are described in detail in the
specification of the various interfaces in the i2 solution architecture.
Page 23 of 247

NENA 08-001 v2, August 11, 2010
Emergency Services Gateway Route Identifier (ESGWRI) The ESGWRI is used by the Call
Server/Routing Proxy to route an emergency call to the correct ESGW, and by the ESGW to select
the desired path to the appropriate SR for the call. The ESGWRI format is as follows: sip: +1
numberstring@esgwprovider.domain;user=phone where the numberstring is 10 numeric
characters (e.g., nnnnnnnnnn).
Emergency Route Tuple (ERT) The ERT consists of the elements from the Emergency Services
Zone Routing Database that are used to select an ESGWRI. The ERT is communicated via the v2
and v8 interfaces and represents a route through a Selective Router for a collection of ESNs that are
associated with a Selective Router. The components of the ERT are:
a Selective Routing Identifier consisting of a Common Language Location Identifier (CLLI)

code of the form AAAABBCCDDD, where
o AAAA represents the city/county
o BB represents the State/Province
o CC represents the building or location
o DDD represents the network,
a 3- to 5-digit routing Emergency Services Number (ESN) that uniquely identifies the ESZ in
the context of that SR,
an NPA that is associated with the outgoing route to the SR.
Emergency Services Query Key (ESQK) The ESQK identifies a call instance at a VPC, and is
associated with a particular SR/ESN combination. The ESQK is delivered to the E9-1-1 SR and may
be delivered as the calling number/ANI for the call to the PSAP. The ESQK is used by the SR as the
key to the Selective Routing data associated with the call. The ESQK may be delivered by the SR to
the PSAP as the calling number/ANI for the call, and subsequently used by the PSAP to request ALI
information for the call. The ALI database includes the ESQK in location requests sent to the VPC.
The ESQK is used by the VPC as a key to look up the location object and other call information
associated with an emergency call instance. The ESQK is expected to be a ten-digit North American
Numbering Plan (NANP) Number.
Last Routing Option (LRO) The LRO is sent by the VPC to the Call Server/Routing Proxy and
provides the Call Server/Routing Proxy with a "last chance" destination for the call. The LRO may
be the Contingency Routing Number (CRN), which is a 24x7 PSAP emergency number, or it may
contain a routing number associated with a national or default call center. The content of the LRO
will depend on the condition that resulted in the providing of the LRO. Ultimately the usage of LRO
routing data for call delivery is based on logic internal to the Call Server/Routing Proxy.
Contingency Routing Number (CRN) A 10-digit 24x7 number that could be used, when
available, to route emergency calls to the PSAP in scenarios where a network (i.e., trunk or SR)
failure results in the ESGW being unable to route the emergency call over the desired path to the SR.
The CRN is expected to be a 10-digit NANP number.
Page 24 of 247

NENA 08-001 v2, August 11, 2010
Location Object (LO) In the context of this document, the LO is used to refer to the current
position of a VEP that originates an emergency call. The LO is expected to be formatted as a
Presence Information Data Format Location Object (PIDF-LO) as defined by the IETF in RFC
4119 [8] and RFC 5139 [37] document. The PIDF-LO may be:
Geodetic location latitude, longitude, elevation, and the datum which identifies the
coordinate system used. For the i2 solution it is expected that geodetic location information
will be formatted using the World Geodetic System 1984 [35] (WGS84 1) datum.
Civic location a set of elements that describe detailed street address information.
Location Key (LK) an object that uniquely identifies an instance of a LO that is stored/managed
by a LIS on behalf of a VoIP endpoint. The Location Key may contain a unique LIS identifier and a
unique identifier for the end point. For example, in SIP this is represented as a URI and the term
used is "Location by Reference. Details on the Location Key are for further study.
Location Information Element (LIE) a protocol container for either or both of:
one LK.
one PIDF document.
Callback Number an identifier for an emergency caller that can be used by the PSAP to reach an
emergency caller subsequent to the release of an emergency call. In the i2 solution, the Callback
Number is an E.164 number, and is represented in VoIP signaling by a tel-Uniform Resource
Identifier (URI) [41]. The callback number, when available, must be sourced from the VSPs
subscription data which shall not be directly modifiable by the user.
Customer Name The Customer Name represents the name of the VSPs customer who subscribed
to the VoIP service and is typically billed for it. The Customer Name, when available, must be
sourced from the VSPs subscription data which shall not be directly modifiable by the user.
Postal Address - A Postal Address includes the following data elements in the VDB validation
request and response:
HouseNum
PrefixDirectional (not included in all addresses e.g. N 7TH)
StreetName
StreetSuffix (not included in all addresses e.g. CONGRESS AVE)
PostDirectional (not included in all addresses e.g. ACADEMY DR E)
PostalCommunity
CountyName
StateProvince
PostalCode
Country
1 The i2 solutions uses Internet standards for location representation as described in RFC-5491[18]. Locations expressed
as points and shapes are specified using the WGS-84 datum in either 2 or 3 dimensions.
Page 25 of 247

NENA 08-001 v2, August 11, 2010
An address is considered Postal valid if it exists in the countrys Postal Service authority data. For
example, a valid Postal Address will conform to USPS abbreviations as specified in USPS Standard
Publication No. 28 or the Canadian Postal Guide. The VDB may use a database or service based on
USPS data to determine whether an address is a valid postal address.
MSAG Address - An MSAG Address includes the following data elements in the VDB validation
request and response:
HouseNum
HouseNumSuffix
PrefixDirectional (not included in all addresses e.g. N 7TH)
StreetName
StreetSuffix (not included in all addresses e.g. CONGRESS AVE)
PostDirectional (not included in all addresses e.g. ACADEMY DR E)
MSAGCommunity
CountyID (not used by all MSAG addresses)
StateProvince
An address is considered MSAG valid if it exists in the MSAG database. The MSAG database is
created by the Addressing Authority for a region. It contains entries for valid Address Ranges for the
Streets (within the Communities, Counties, and State/Province) for which the Addressing Authority
is responsible. The Abbreviations, Street Names and Community Names may not be the same as the
valid Postal Address for the same address (in fact they will most probably be different see
Appendix C). An MSAG address may also require a County ID to be specified. The County ID may
be an abbreviation of the County Name or it may be the Tax Area Rate (TAR) Code for the County.
3.5
Interface Definitions
This section provides brief definitions of the VoIP and data exchange interfaces included in the i2
Solution.
The v2, v7, v8 and v9 interfaces specifications are based on web services. A short tutorial on this
technology is provided in Exibhit 8.5 for convenience.
3.5.1
v0 LIS to VoIP Endpoint
The v0 interface is used to provide a means for a VoIP endpoint to receive information
corresponding to a pre-determined location. The information provided may be in the form of a LK,
or it can be a PIDF-LO containing the actual location, as described in Section 3.5.2. In the i2
timeframe, it is expected that the PIDF-LO may include either or both Geodetic and Civic
information, to enable routing of the emergency call, and a Civic Location, e.g. addresses for nonmobile IP devices (mobile IP endpoints are not specifically addressed), for display to the PSAP.
How the IP network actually determines the location and the protocol between the LIS and IP device
is outside the scope of this document.
Page 26 of 247

NENA 08-001 v2, August 11, 2010
This interface should be defined by standards organizations such as TIA/IETF. Additional details
can be found in Section 6.1.
3.5.2
v1 VoIP Endpoint to Call Server/Proxy
The v1 interface is between the VoIP Endpoint and the Call Server within the VSPs network. It is
used to initiate an emergency call which will ultimately be answered by the correct PSAP and is also
used to communicate the location information to the Call Server when an emergency call is initiated.
The interfaces must:
a. Transport emergency call notifications
b. Support transport of the location information (containing either or both of a PIDF-LO and
LK)
c. Support the other requirements listed in this document.
This interface should be defined by standards organizations such as TIA/IETF. Additional details
can be found in Section 6.2.
3.5.3
v2 Call Server or Routing Proxy or Redirect Server to VPC
The v2 interface is used to request emergency call routing information. The Call Server can invoke
the v2 interface directly or utilize a Routing Proxy/Redirect Server, which requires forwarding the
LIE, or sufficient information to construct the LIE to the Routing Proxy/Redirect Server. It is
expected that the VSP/Routing Proxy Operator will have a business relationship in place which
would allow the Call Server/Proxy to send requests for routing information to the appropriate VPC.
The v2 interface is an eXtensible Markup Language (XML) query/response interface. It provides a
means for the Call Server/Routing Proxy/Redirect Server to request emergency services routing
information from the VPC based on the location of the caller. The Call Server/Routing
Proxy/Redirect Server sends a request containing location information (LO or LK), subscriber name
and callback information, and if available, a VSP identifier to the VPC. The VPC uses the location
information to interact with an ERDB to determine an ERT for routing. The ERT is also used to
determine a pool of ESQKs from which an ESQK can be allocated for the call. The ERT and ESQK
are returned over the v2 interface in the response to a request for routing information associated with
an emergency call. As an alternative to the v2 interface returning the ERT, the VPC may translate
the ERT into an ESGWRI which is returned instead of the ERT. The VPC will return an LRO, if
one is available. Additional details can be found in Section 6.3.
3.5.4
v3 VPC to LIS
The v3 interface provides a means for the VPC to obtain the emergency callers location. This is
used when the LIE, provided to the VPC via the v2 interface, contains an LK. The LK is used in
obtaining the location from the LIS. The VPC uses the returned location information to obtain
routing information from the ERDB. Additional details can be found in Section 6.4.
Page 27 of 247

NENA 08-001 v2, August 11, 2010
3.5.5
v4 Call Server/Routing Proxy to ESGW
The v4 interface is used to forward the call to the appropriate ESGW. The Call Server/Routing
Proxy uses the ESGWRI returned from the VPC, or derived based on the ERT returned by the VPC,
to forward calls to the appropriate ESGW, and inserts the ESGWRI and ESQK into the signaling
message. Additional details can be found in Section 6.5.
3.5.6
v5 Call Server/Proxy to Redirect Server
The v5 interface is defined as a SIP interface to a Redirect Server so it supports a subset of the SIP
specification. The Call Server sends a SIP INVITE containing callback information, the subscriber
name, the LO and/or LK, and the VSP identifier to the Redirect Server. The Redirect Server
interfaces to the VPC over v2 to obtain routing instructions for the emergency call based on the
location of the caller. The VPC provides the Selective Routing Identifier, Routing ESN and NPA
(referred to as an ERT) or ESGWRI along with the ESQK to the Redirect Server. The Redirect
Server responds to the Call Server with a 300 response with a Contact header containing the
ERT/ESGWRI and a P-Asserted-Identity (PAI) [40] containing the ESQK. The Redirect Server will
also include a Contact header including the LRO, if a LRO was included in the response from the
VPC. The Call Server then selects an ESGW based on the ERT/ESGWRI and forwards the call to it
via the v4 interface.
To facilitate release of the ESQK allocated to the call, the Redirect Server will need to inform the
VPC when the call has terminated. To enable termination reporting using existing SIP methods, the
Redirect Server will need to send a SUBSCRIBE method to the Call Server via the v5 interface to
make the Call Server aware that notification should be sent upon termination of the call. When the
Call Server detects that the call has terminated, the Call Server will send a SIP NOTIFY method via
the v5 interface to the Redirect Server. Upon receiving the NOTIFY method, the Redirect Server
will inform the VPC over the v2 interface so that it can release the ESQK.
Additional details can be found in Section 6.6.
3.5.7
v6 Call Server to Routing Proxy
The v6 interface is defined as a SIP interface to a Routing Proxy. The Routing Proxy supports the
full SIP specification. The CS sends a SIP INVITE containing the callback information, the
subscriber name, the LO and/or LK, and the VSP identifier to the RP. This interface is used when
the CS (unconditionally) routes all emergency calls to a Routing Proxy.
3.5.8
v7 LIS to VDB
The v7 interface is used by the LIS provider to request validation of a given Civic Location as
compared with the MSAG-based data stored in the VDB. The VSP may also use this interface from
its LIS, when acting on behalf of its customers in the function of location provider/verifier.
Page 28 of 247

NENA 08-001 v2, August 11, 2010
A location validation request includes at least the civic location. The response includes an indication
of whether or not the Civic Location is a valid address recognized by the MSAG, and may include
error/diagnostic information to assist in resolving problems.
The interface should be able to support individual location validation requests sent one at a time for
validation processing.
3.5.9
v8 VPC to ERDB
The v8 interface supports queries from the VPC to the ERDB. The VPC sends location information
for the emergency caller to the ERDB to obtain routing information (ERT), and other information to
help in selection of an appropriate ESQK for the call and to support the delivery of call/location
information in response to ALI database requests.
Additional details on this interface can be found in Section 6.9.
3.5.10 v9 LIS/VPC to Root Discovery Operator
The v9 interface allows a LIS/VPC to discover the appropriate VDB/ERDB. Several mechanisms
have been defined to allow for the discovery of the VDB/ERDB and these mechanisms are described
in Section 3.9.
Additional details on this interface can be found in Section 6.10.
3.5.11 v-E2 VPC to ALI DB
The v-E2 interface uses the E2+ protocol as defined in NENA Standards 05-001[13], with
modifications required for support of i2. The ESQK is sent in a query by the ALI DB over the v-E2
interface. The VPC responds with the emergency callers location, callback number, and VoIP
Provider identifier/information it received in the VSP and/or source element.
The ALI DB will need to steer ESQK queries to the VPC provider. The ESQK may need to be
identified with a VoIP Class of Service to separate this processing from the logic that is in place for
Wireless.
Additional details on this interface can be found in Section 6.11
3.6
Location Information Scenarios
There may be a variety of technologies and solutions for determining the location of an individual
caller, but after the location has been determined and validated (refer to Section 3.8), location
information must be made available for routing an emergency call to the appropriate interconnection
point and for delivery to the PSAP. This section provides a high-level overview of two basic
scenarios for storing and conveying location information for support of emergency calling from the
IP domain.
Page 29 of 247

NENA 08-001 v2, August 11, 2010
3.6.1
Endpoint Stores Location
To convey geographical location information within an object that includes a user's privacy and
disclosure preferences and which is protected by strong cryptographic security, the IETF has defined
an XML-based Presence Information Data Format - Location Object (PIDF-LO) that allows for
encapsulation of location information within a presence document. The PIDF-LO defines an object
suitable for both identifying and encapsulating pre-existing location information formats and for
providing adequate security and policy controls to regulate the distribution of that location
information. To provide its location to another entity (e.g., for originating an emergency call among
many other potential applications), the VoIP endpoint constructs a PIDF-LO that encapsulates its
location, as well as policy documents that describe how and to what entities that location information
can be presented. Note that the emergency services architecture being developed in IETF allows the
UA Client to include location information on emergency calls. The PIDF-LO can be used
independently of any 'using protocol' (e.g., SIP); any protocol that can carry XML or MIME
document types can carry the PIDF-LO.
In the endpoint-stored location scenario, using SIP signaling, the UA includes this PIDF-LO in the
message body of the INVITE message over the v1 interface shown in Figure 3-1. The PIDF-LO may
be carried over the v5 or v6 interface to a redirect or routing proxy, depending on the call routing
scenario (refer to Section 3.6), and is carried in a LIE over the v2 interface to the VPC for routing
determination and for subsequent delivery to the PSAP. The IETF draft-ietf-sipcore-locationconveyance [12] describes location conveyance.
3.6.2
LIS Stored Location Key
An alternate approach to supporting location for emergency services calling is allowed in the i2
solution, where completely specified in other standards bodies 2. This method allows for the LIS to
store the location information for a given endpoint and to download to that VoIP endpoint a Location
Key, in addition to, or instead of, the location information itself. Then, the VoIP endpoint stores the
LK and provides it, instead of or in addition to the location information, over the v1 interface on
emergency call originations. The location information/Location Key may be carried in call setup
signaling over the v5 or v6 interface to a redirect or routing proxy, depending on the call routing
scenario (refer to Section 3.6), and it will be included over the v2 interface to the VPC. When the
VPC receives the LK in an LIE, it uses the LK to query the appropriate LIS over the v3 interface.
The LIS returns the PIDF-LO to the VPC for routing determination and for subsequent delivery to
the PSAP.
3.7
Call Routing Scenarios
The definition of Call Server, Redirect Server, and Routing Proxy permits a variety of business
relationships and responsibilities to be established. The variations considered in this document
include (but are not limited to):
2 The IETF has work started to define the Location Key (known as location-by-reference, LbyR) mechanism. At this time, the
working group is discussing the requirements in [43]. Location Conveyance is described in [12].
Page 30 of 247

NENA 08-001 v2, August 11, 2010
The VSP contracts for VPC and ESGW services from one or more providers, and retains
maximum control over the processing of emergency calls. The VSPs Call Server
implements the v2 interface, directly queries the VPC for routing information (i.e., ESQK,
LRO, and either the ERT or ESGWRI), selects the proper ESGW based on the ESGWRI, and
routes calls via the PSTN using the LRO if normal routing fails.
The VSP contracts separately for VPC and ESGW services but desires a SIP interface to
access routing data. The Redirect Server Operator implements a Redirect Server which
accepts 9-1-1 calls from the VSPs Call Server. The Redirect Server obtains the routing
information from the VPC. It returns the call to the VSPs Call Server with the ERT or
ESGWRI in the SIP Contact Header, and the ESQK in the SIP P-Asserted Identity header.
The Call Server selects the proper ESGW based on the ESGWRI. The Call Server handles
alternate routing using the LRO.
The VSP contracts for a single 9-1-1 call termination service from a Routing Proxy provider
and uses the v6 SIP interface to route emergency calls to the Routing Proxy provider. The
Routing Proxy Service Provider receives all 9-1-1 calls at its Routing Proxy. The Routing
Proxy provider implements the v2 interface, queries the VPC for ESQK, LRO, and either
ERT or ESGWRI, selects the proper ESGW based on the ESGWRI, and routes calls via the
PSTN using the LRO if normal routing fails.
The remainder of this section describes these three different example call routing scenarios which
will be able to be supported in the i2 solution. These solutions differ in terms of the element that is
responsible for interacting with the VPC to obtain the routing information and the query key for the
call, and in subsequently routing the call to the appropriate gateway (i.e., ESGW). In the first
scenario, it is assumed that a Call Server is responsible for detecting that an emergency call
origination has been requested, and interacting with a VPC to obtain the necessary routing
information and query key. The Call Server is then responsible for routing the call to the appropriate
ESGW. The second scenario includes a Redirect Proxy, which is responsible for accessing the VPC,
but subsequently returns control of the call back to the Call Server for subsequent
routing/processing. In the third scenario, a Routing Proxy Server in the call path is responsible for
querying the VPC and routing the call forward to the ESGW. Each of these scenarios is illustrated
with a diagram showing the relevant interfaces and a high-level description of the associated
information flow.
These scenarios also describe a contingency routing capability, to address scenarios in which the
ESGW is unable to route an emergency call to the E9-1-1 SR over the desired path because of a
failure condition associated with the interconnecting trunk group or SR.
Each scenario also includes delivery of an indication of call release to the VPC so that it can release
the allocated ESQK for use in routing other calls.
Performance in call routing is important so that VoIP-originated emergency calls reach the
appropriate PSAP as quickly as possible. This document does not provide normative requirements
on call routing performance however, informative guidelines are available in Section 9.7 to help
implementers in designing the best approach end-to-end.
Page 31 of 247

NENA 08-001 v2, August 11, 2010
3.7.1
Basic Call Routing of VoIP Emergency Calls to ESGW
Figure 3-2 illustrates a basic call routing scenario for a VoIP emergency call origination. In this
scenario, a Call Server queries the VPC for routing information, and routes the call directly to the
ESGW. Before the emergency call is originated, the civic location is validated in steps A and B
(refer to Section 3.8).
IP domain
Call Server/
Proxy
2. INVITE
(911@VSPdomain
{PIDF-LO} / {LK})
Emergency Services
Provider Network
7. INVITE
(ESGWRI, ESQK,
[Callback])
CAMA or SS7
v4
8. Call route
(ESQK, [Callback])
3. Query (Callback,
Customer, LIE)
6. Response (ERT or
ESGWRI, ESQK, [LRO])
v1
User
Agent
E9-1-1
Selective
Router
ESGW
VPC
v0
v3
LIS
4. Query (LK)
5. Response
(PIDF-LO)
v8
11. ESPOSREQ (ESQK)

12. esposreq (Callback,
Customer, location,
[provider info])
10. ALI query (ESQK)

13. ALI response
(Callback,
Customer, location,
[provider info])
ERDB
MSAG
MSAG
MSAG
v7
A. Validation query (civic location)
B. Validation response (valid or
error [with diagnostic])
NENA
02-010
ALI
v-E2
1. LO
and/or
LK
9. Deliver
Call (ESQK,
[Callback])
SRDB
v2
PSAP
MF, E-MF,
ISDN, CTX
VDB
DBMS
Figure 3-2 Basic Call Routing of VoIP Emergency Calls
Step 1. The endpoint is populated with a LO and/or LK. The figure illustrates the method whereby a
PIDF-LO/LK is downloaded from the LIS to the endpoint using the v0 interface.
Step 2. The VoIP endpoint originates an emergency call by sending a call initiation request,
designating 911@VSPdomain 3 as the target destination, and including the LO and/or LK. Using SIP
as the example, the User Agent would send an INVITE, including sip:911@VSPdomain in the
Request URI header, the Address of Record (AoR) associated with the User Agent (possibly in the
form of a tel- uri[41]) in the From header, and including the PIDF-LO member-body in the INVITE.
3 RFC 5031 [24]defines a URN scheme that could be used in the context of emergency services. It would replace the actual country-
specific dial string typically found in the user part of the URI of the INVITE. Please refer to [24] for a description of this mechanism.
Page 32 of 247

NENA 08-001 v2, August 11, 2010
Step 3. The Call Server receives the call initiation request and uses local procedures to determine
the provisioned callback number and subscriber name associated with the Address of Record
received in the incoming INVITE. The Call Server then sends a routing request to the VPC using
the information received in, and determined based on, the call request. The VPC receives the routing
request that includes the following key pieces of information:
A callback number associated with the emergency caller in the form of an E.164 telephony
number (e.g., a tel URI)
A subscriber name associated with the emergency caller
A LIE.
Step 4. If a LK is received, the VPC queries the identified LIS over the v3 interface, including the
LK.
Step 5. The LIS returns to the VPC the requested location over the v3 interface.
Step 6. The VPC uses the location (received from the Call Server or queried from the LIS) to obtain
the ESZ-related routing information from the ERDB over v8 (not shown). The ERDB identifies the
ERT and CRN that will facilitate routing via the appropriate ESGW to the SR that serves this ESZ.
The VPC uses the received routing information to allocate an available ESQK from the pool of
ESQKs appropriate for the SR/ESN associated with the callers location/ESZ and sends a response
to the routing request for this call. The routing response sent to the Call Server will contain the
allocated ESQK and the appropriate LRO. In addition, routing information will be included in the
response that consists of either the ERT (if the Call Server is responsible for performing the ERT-toESGWRI translation), or an ESGWRI (if the VPC is responsible for performing the ERT-toESGWRI translation.
The VPC also determines the VSP either from the routing request contents or from the originator of
the request. The VPC maps the callers Callback number, subscriber name, VSP, and the contents of
the location into the appropriate fields necessary to populate the response to an Emergency Services
Positioning Request (ESPOSREQ) and stores this information pending a subsequent query from the
ALI DB.
Step 7. If the Call Server receives an ERT in the routing response from the VPC, the Call Server
will use the ERT to determine the target ESGW and the appropriate ESGWRI value for the call. If
the Call Server receives an ESGWRI in the routing response from the VPC, the Call Server will take
the ESGWRI received in the response and use it as the basis for selecting the appropriate ESGW
toward which to route the emergency call. In either case, the Call Server routes the call to the
ESGW, including the ESGWRI, the ESQK, and the callback number in outgoing signaling.
The LRO will be retained at the Call Server and only used for emergency call routing if the ESGW
detects a failure condition that makes routing based on the ESGWRI impossible.
Step 8. The ESGW uses the received ESGWRI to select an outgoing route (i.e., trunk group) to the
appropriate E9-1-1 SR. If the trunk group is available, the ESGW seizes a trunk and signals an
Page 33 of 247

NENA 08-001 v2, August 11, 2010
emergency call origination to the E9-1-1 SR, using outgoing (SS7 or MF) 10 or 20-digit signaling as
specified in Section 5.3.1.
If the ESGW determines that it cannot route the call over a route associated with the ESGWRI due to
a failure condition, it shall inform the Call Server that a failure has occurred.
Step 9. The SR receives the emergency call, uses the ESQK to query the SRDB for the associated
Emergency Service Number (ESN), and uses the ESN to identify the appropriate PSAP for the call.
The SR then delivers the call to the appropriate PSAP, signaling the ESQK (as illustrated in Figure
3-2), the callback number (if available), or both the ESQK and the callback number, based on local
implementations.
Step 10. The PSAP ANI/ALI controller receives the call setup signaling, and sends an ALI query to
its serving ALI DB, using the ESQK (as illustrated in Figure 3-2) or callback number as the query
key, based on local implementations.
Step 11. The ALI DB sends an ESPOSREQ to the VPC (identified in the shell record for the ESQK
in the ALI DB), and includes the ESQK (as illustrated in Figure 3-2) or ESQK + callback number in
the request.
Step 12. The VPC receives the ESPOSREQ from the ALI DB, and uses the ESQK to retrieve the
ALI record information it stored previously (in Step 4). The VPC returns an Emergency Services
Positioning Request response (esposreq) to the ALI DB which includes the callback number, the
subscriber name, the location information, and the VSP provided information that can be supported
by the v-E2 interface.
Step 13. The ALI DB receives the esposreq from the VPC. It may also extract additional
information from the shell record for the ESQK. The ALI DB returns an ALI response to the PSAP,
following requirements in NENA 02-010[11].
Step 14. (not shown) When the VPC receives an indication that a particular instance of an
emergency call is being cleared, the VPC de-allocates the associated ESQK and makes it available
for subsequent emergency calls. Note that release of the ESQK may occur as a result of an
indication of call release over the v2 interface from the Call Server/Routing Proxy, or the expiration
of the ESQK guard timer, whichever occurs first.
3.7.2
Proxy Redirect Server
Figure 3-3 illustrates an example of an emergency call setup using SIP signaling to a Redirect
Server. In this scenario, the Call Server uses a Redirect Server to obtain routing information, and
then routes the call to the ESGW. The SIP Redirect Server performs a routing query to the VPC
over the v2 interface.
Before the emergency call is originated, the location is validated in steps A and B (refer to Section
3.8).
Steps 1 and 2 are the same as in the basic scenario described in Section 3.6.1.
Page 34 of 247

NENA 08-001 v2, August 11, 2010
Step 3. The Call Server/SIP Proxy Server sends an INVITE over the v5 interface to a SIP Redirect
Server. The INVITE includes the callback number, subscriber name, and PIDF-LO.
Step 4. The SIP Redirect Server queries the VPC over the v2 interface, including the following key
information:
LIE.
Emergency Services
Provider Network
IP domain
Call Server/
Proxy
9. INVITE
(ESGWRI, ESQK, [Callback])
ESGW
E9-1-1
Selective
Router
CAMA or SS7
v4
3. INVITE
8. REDIRECT
2. INVITE
(911@VSPdomain
{PIDF-LO} / {LK})
v5
Redirect
Server
v1
User
Agent
v2
10. Call route

(ESQK, [Callback])
4. Query (Callback,
Customer, LIE)
7. Response (ERT or
ESGWRI, ESQK,
[LRO])
LIS
5. Query (LK)
6. Response
(PIDF-LO)

15. ALI response
(Callback,
Customer, location,
[provider info])
ERDB
v7
VDB
11. Deliver
Call (ESQK,
[Callback])
ALI
v-E2
13. ESPOSREQ (ESQK)
Customer, location,
[provider info])
v8
v3
PSAP
NENA
02-010
VPC
v0
1. LO
and/or
LK
SRDB
MF, E-MF,
ISDN, CTX
DBMS
MSAG
MSAG
MSAG
Figure 3-3 Call Routing using SIP Redirect Server
Steps 5 through 7 are the same as Steps 4 through 6 in the basic scenario described in Section 3.6.1.
Step 8. The Redirect Server returns a SIP REDIRECT message to the SIP Proxy, including the
ESQK and either the ERT or the ESGWRI provided by the VPC. It may also include a LRO, if
provided by the VPC.
Page 35 of 247

NENA 08-001 v2, August 11, 2010
Step 9. The Call Server/SIP Proxy routes the call to the ESGW over the v4 interface, including the
ESGWRI provided by the VPC or determined by the Call Server, the ESQK, and the callback
number.
Steps 10-15 are the same as Steps 8-14 in the basic scenario described in Section 3.6.1.
3.7.3
Routing Proxy Routing Scenario
Figure 3-4 illustrates an example of emergency call routing via a routing proxy. In this scenario, the
emergency call is routed via a routing proxy which initiates the routing query to the VPC, and then
routes the call directly on to the appropriate ESGW.
Emergency Services
Provider Network
IP domain
Call Server/
Proxy
3. INVITE
(Callback, Customer,
{PIDF-LO} / {LK})
v6
Routing
Proxy
v1
8. INVITE
(ESGWRI,ESQK,
[Callback])
ESGW
CAMA or SS7
9. Call route
(ESQK, [Callback])
4. Query (LIE, Callback,

Customer)
7. Response (ESQK, ERT
or ESGWRI, [LRO])
User
Agent
v2
SRDB
LIS
v3
5. Query (LK)
6. Response
(PIDF-LO)
12. ESPOS REQ (ESQK)

Customer, location,
[provider info])
v8
10. Deliver
Call (ESQK,
[Callback])
NENA
02-010
ALI
v-E2
VPC
v0
1. LO
and/or
LK
PSAP
ISDN, CTX
v4
2. INVITE
(911@VSPdomain
{PIDF-LO} / {LK})
E9-1-1
Selective
Router MF, E-MF,

14. ALI response
(Callback, Customer,
location,
[provider info])
ERDB
MSAG
MSAG
MSAG
v7
VDB
DBMS
Figure 3-4 Call Routing using a SIP Routing Proxy
Before the emergency call is originated, the LO is validated in steps A and B (refer to Section 3.8).
Steps 1 and 2 are the same as in the basic scenario described in Section 3.6.1.
Step 3. The Call Server/SIP proxy sends an INVITE over the v6 interface to a SIP Routing Proxy.
The INVITE includes the callback number, subscriber name, and PIDF-LO.
Step 4. The SIP Routing Proxy queries the VPC over the v2 interface, including the following
information:
Page 36 of 247

NENA 08-001 v2, August 11, 2010
LIE.
Steps 5 and 6 are the same as Steps 4 and 5 in the basic scenario described in Section 3.6.1.
Step 7. The VPC uses the received PIDF-LO to request routing information from the ERDB over v8
(not shown). The ERDB uses the received location to determine the ERT and CRN for the call. The
VPC uses the ERT to determine the ESQK associated with the ESZ of the caller, and allocates an
available ESQK for the call. The VPC sends a response to the routing request for this call over the
v2 interface to the Routing Proxy, including the allocated ESQK and either an ERT (if the Routing
Proxy is responsible for performing the ERT-to-ESGWRI translation) or an ESGWRI (if the VPC is
responsible for performing the ERT-to-ESGWRI translation). An LRO is also expected to be
included in the routing response.
The VPC also determines the VSP either from the routing request contents or from the originator of
the request. The VPC maps the callers callback number, subscriber name, VSP, and the contents of
the location into the appropriate fields necessary to populate the response to a subsequent
ESPOSREQ from the ALI DB and stores this information pending a subsequent query.
Step 8. The SIP Routing Proxy routes the call to the ESGW over the v4 interface, including the
ESQK provided by the VPC, the ESGWRI determined by the Routing Proxy or provided by the
VPC, and the callback number.
Steps 9-15 in the Emergency Services Provider Network are the same as Steps 8-14 in the basic
routing scenario described in Section 3.6.1.
3.7.4
ESGWRI-based Routing Translations
To route calls to the correct ESGW, the routing entity must translate an ESGWRI to the URI of the
ESGW. One way this can be accomplished is by having the ESGW operator maintain a table that
maps an ESGWRI value to an ESGW. The routing data for this table can be provided in a
standardized form, and may be retrieved using HTTP [33]. An example of a table, expressed as an
XML representation is as follows:
Page 37 of 247

NENA 08-001 v2, August 11, 2010
<route-table xmlns="urn:nena:xml:ns:es:rt"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:nena:xml:ns:es:rt rt.xsd">
<ESGW>
<organizationName>Generic ESGW Service</organizationName>
<expiration>2006-12-01 09:28:43+10:00</expiration>
</ESGW>
<Routes>
<Route ESGWRI=2127113345 hostId=LowerManttanNY.example.com/>
<Route ESGWRI=2127113346 hostId=LowerManttanNY.example.com/>
...
<Route ESGWRI=4047113345 hostId=RaritanNJ.example.com/>
...
</Routes>
</route-table>
The exact implementation of the ESGWRI-to-ESGW translation will be determined by the provider
of the routing entity. However, to support this translation function, the ESGW Operator shall supply
the appropriate ESGW URI to the routing entity.
3.8
Call Routing Failure Scenarios
There are a number of errors or abnormal conditions (e.g., network failures) that may occur in the
process of routing emergency calls originated by VoIP users to the appropriate E9-1-1 SR in the
Emergency Service Providers network. This section identifies different error scenarios that may
occur in the course of routing an emergency call to the appropriate SR in an i2 environment, and
identifies the contingency/default routing mechanisms that should be invoked at the various VoIP
elements that are impacted by the abnormal condition or event.
3.8.1
Abnormal Conditions Detected at the Call Server/Proxy
There are several classes of error/failure conditions that may be detected at the CS. One class of
abnormal conditions is related to the request for routing information that the CS is expected to
generate for emergency calls and send to the appropriate VPC, and the processing of the associated
response message from the VPC. This class of error/failure scenarios includes the following:
The CS cannot identify the VPC (or its network address) to which the routing request
associated with the emergency call should be directed.
The CS has lost connectivity to the VPC.
The CS receives an error response containing no routing information from the VPC.
The CS does not receive any response from the VPC within a pre-determined period of time.
In all of these scenarios, the CS does not receive any routing data from the VPC. If the problem is a
loss of connectivity to the (primary) VPC, and the CS is connected to multiple VPCs, the CS may
attempt to send the routing request to a secondary VPC, provided that the appropriate agreements
exist between the VSP and the VPC providers. Should one of the other error scenarios described
Page 38 of 247

NENA 08-001 v2, August 11, 2010
above occur, the CS is expected to use a default routing number or URI that has been pre-defined by
the VSP to route the call to an agent at a 24x7 call center. The callback number will be treated as the
calling number/Automatic Number Identification (ANI) for the call. If the callback number cannot
be determined for the call, the CS should still route the call forward using the default routing number
or URI without a PAI header.
In another set of scenarios, the CS receives some routing information from the VPC, but this
information does not include an ERT/ESGWRI or ESQK. In this case, the CS receives a default
routing number in an LRO from the VPC, without an ERT/ESGWRI or an ESQK. This could occur
if the VPC does not successfully receive routing information from the ERDB in response to a routing
query.
If the CS receives routing information consisting of only an LRO, the CS will either use the LRO or
the default routing number provisioned at the CS, depending on the precedence pre-defined by the
VSP, as the routing number for the emergency call. The callback number will be signaled as the
calling number/ANI for the call, if it is available.
Likewise, if the CS receives routing information from the VPC that consists of an ERT, ESQK and
LRO, and the CS is unable to successfully translate the ERT to an ESGWRI, the CS will either use
the LRO or the default routing number provisioned at the CS, depending on the precedence predefined by the VSP, as the routing number for the emergency call, and will signal the callback
number as the calling number/ANI for the call, assuming it is available.
Another class of abnormal conditions results from network failures that make routing the emergency
call over the desired primary route impossible. These include the following scenarios:
The CS receives an ESGWRI (along with ESQK and LRO) from the VPC, but there is no
available outgoing route to an ESGW associated with the ESGWRI.
The CS receives a failure indication from the ESGW (as described in Section 3.7.3).
Under both of these scenarios, the Call Server/Proxy is expected to use the LRO received in the
routing response from the VPC, or the default routing number provisioned at the CS, depending on
the precedence pre-defined by the VSP, as the routing number for the call, and the callback number
as the calling number/ANI for the call.
3.8.2
Abnormal Conditions Detected at the VPC
One class of errors that might be detected at the VPC involves problems with the structure or content
of the routing request from the originating node (CS/RP/RS) to the VPC, or queries from the VPC to
the Emergency Service Zone (ESZ) Routing Database (ERDB) or Location Information Server
(LIS). This class includes the following scenarios:
The VPC receives a badly structured routing request (i.e., request message cannot be parsed
or is malformed.)
The routing request contains neither a Location Key nor a PIDF-LO.
Page 39 of 247

NENA 08-001 v2, August 11, 2010
The VPC receives a PIDF-LO in the routing request, but it cannot determine, based on the
received location, which ERDB to query for the routing data.
The VPC receives a PIDF-LO in the routing request, but when it uses it to query the ERDB
for routing data, it receives either an error response or no response from the ERDB.
The VPC receives a Location Key in the routing request, but it cannot determine where to
send the location query (i.e., it cannot determine the appropriate LIS).
The VPC receives a Location Key in the routing request, but has lost connectivity to the
desired LIS.
The VPC receives a Location Key in the routing request, and is unable to successfully
retrieve a PIDF-LO from the LIS (i.e., it receives an error response or no response from the
LIS).
In all of these scenarios, the VPC is unable to successfully obtain routing data from the ERDB and
provide it in a response to the originating node. The VPC shall then send a response message that
indicates the nature of the error that occurred. The message may also include a default routing
number (i.e., a 24x7 number associated with a call center), as determined based on prior agreements
between the VPC provider, the VSP, and the call center to which calls are to be default-routed. (The
default routing number will be populated in the Last Routing Option parameter of the response
message.).
If a VPC is responsible for performing the ERT-to-ESGWRI translation, but it is unable to
successfully perform this translation for a specific ERT provided by the ERDB, the VPC will be
expected to send a response message to the Call Server/Proxy that provides default routing
information (consisting of a CRN, if one was returned by the ERDB) in an LRO. It is not
recommended that the ESQK be included in the response to the Call Server since the VPC could not
determine an ESGWRI.
Another type of abnormal condition that might be encountered at the VPC is related to a lack of
resources at the VPC. Specifically, the VPC successfully receives routing data from the ERDB, but
there are no ESQKs available from the applicable pool to associate with the specific call instance. In
this case, the VPC is expected to return a default ESQK value in the response message to the Call
Server/Proxy along with an ERT or ESGWRI and an LRO containing a CRN, if available, or a
default routing number. Since the default ESQK may be used for several concurrent call instances it
may not yield a valid location when used by the ALI to query the VPC over the v-E2. If a VPC
receives an Emergency Services Call Termination (ESCT) message from a Call Server/Proxy that
includes a default ESQK value the VPC shall ignore the ESCT message.
Abnormal conditions associated with the release of ESQKs may also be detected at the VPC. For
example, if the VPC receives an Emergency Services Call Termination (ESCT) message from a Call
Server/Proxy that includes an ESQK value that is not currently assigned (e.g., an ESQK that has
already been released, possibly due to the expiry of the guard timer), the VPC should ignore the
message, log the event and increment the maintenance count.
Page 40 of 247

NENA 08-001 v2, August 11, 2010
3.8.3
Abnormal Conditions Detected at the ESGW
It is possible that an emergency call gets successfully routed to an ESGW, with the expected
information communicated in call setup signaling (i.e., the ESGWRI , ESQK, and callback number),
and that the ESGW can identify the appropriate outgoing trunk group to the SR associated with the
received ESGWRI, but a trunk failure or SR failure makes it impossible for the ESGW to deliver the
call to the desired SR over the primary route. In such a scenario, it is expected that the ESGW will
attempt to select a secondary route for the emergency call, assuming one has been provisioned.
However, if there is no way for the ESGW to route the call forward, it is expected that the ESGW
will inform the CS of the failure condition using the appropriate SIP signaling mechanism. The CS
will then follow the procedures described in Section 3.7.1.
If, based on provisioning, the ESGW is expected to deliver both a callback number and an ESQK to
the SR over a particular trunk group, and a callback number was not provided to the ESGW in the
received INVITE message, the ESGW shall generate a non-dialable callback number of the form
911-XXX-XXXX, where XXX-XXXX is the last seven digits of the received ESQK. The Class of
Service (CoS) will enable the PSAP to distinguish this non-dialable number from other non-dialable
numbers that are generated for wireless calls (911+7 digits of Electronic Serial Number (ESN)). The
ESGW shall deliver the call to the SR with the non-dialable callback number, and the ESQK.
3.8.4
Default Routing at the Selective Router
If the SR receives an emergency call from an ESGW, but the incoming call setup signaling
associated with that call does not include sufficient information to allow the SR to successfully
invoke the selective routing process, the SR will route the call to a pre-defined default PSAP based
on the incoming trunk group over which the call was delivered by the ESGW.
3.8.5
Summary of Contingency/Default Routing
The following table summarizes the contingency/default routing scenarios described above, and the
associated routing procedures.
Table 3-1 Contingency/Default Routing Summary
Element
Call Server/Proxy
Scenario
The Call Server/Proxy has lost

connectivity to the VPC (and is
not connected in
primary/secondary arrangement to
multiple VPCs).
The Call Server/Proxy receives an

error response (with no routing
information) from any of the
Procedure
Call Server/Proxy uses predefined default routing
number or URI to route call
to 24x7 call center with
which VSP has an
arrangement. Call
Server/Proxy signals
callback number as calling
Page 41 of 247

NENA 08-001 v2, August 11, 2010
VPCs.
VPC
number/ANI for the call (if

available).
The Call Server/Proxy does not

receive any response from the
VPC within a pre-defined period
of time.
The Call Server/Proxy cannot

determine which VPC to which to
send the routing request.
The Call Server/Proxy has lost

connectivity to the VPC, and the
Call Server/Proxy is connected to
multiple VPCs in
primary/secondary arrangement.
Call Server/Proxy may

attempt to send the routing
query to a secondary VPC,
if supported by agreements
between the VSP and VPC
providers.
Call Server/Proxy receives

ESGWRI (along with ESQK and
LRO) from VPC, but there is no
available outgoing route
associated with ESGWRI.
Call Server/Proxy receives failure

indication from ESGW.
Call Server/Proxy uses

LRO as routing number for
the call, and callback
number as calling
available).
Call Server/Proxy is responsible

for performing ERT-to-ESGWRI
translation, but the translation is
not successful.
Call Server/Proxy uses

Call Server/Proxy receives a
default routing number from VPC. default number provided by
VPC or pre-defined default routing
number/URI provisioned at
Call Server/Proxy as
routing number for the call,
depending on precedence
defined by VSP. Callback
number is calling
available).
VPC receives a badly structured

routing request from the Call
VPC sends a response

message to the Call
Page 42 of 247

NENA 08-001 v2, August 11, 2010
Server/Proxy.
ESGW
Server/Proxy that either

indicates the nature of the
error condition, or that
provides a default routing
number, depending on the
arrangements made
between the VPC provider
and the VSP.
Routing request contains neither a

Location Key nor a PIDF-LO.
VPC cannot determine which

ERDB to query based on received
location.
VPC receives either an error

response or no response from the
ERDB.
VPC receives Location Key in

routing request from Call
Server/Proxy but cannot
determine which LIS to query for
location.
VPC receives Location Key in

routing request, but has lost
connectivity to the desired LIS.
VPC receives an error response or

no response from LIS when
querying for location.
Lack of resources at VPC (i.e., no

ESQKs available for assignment
to specific emergency call.
VPC is responsible for performing VPC returns a response to

ERT-to-ESGWRI translation, but the Call Server/Proxy that
only contains an LRO.
translation is unsuccessful.
Callback number is calling
available).
Trunk failure or SR failure makes

routing call over primary route
associated with ESGWRI
impossible.
ESGW selects a secondary

route for the call, if one has
been provisioned.
No outgoing routes associated
ESGW returns a failure

indication to the Call
VPC returns a default

ESQK along with an
ERT/ESGWRI and LRO to
the Call Server/Proxy in
response to its routing
request.
Page 43 of 247

NENA 08-001 v2, August 11, 2010
Selective Router
3.9
with the received ESGWRI are

available.
Server/Proxy.
Provisioning dictates delivery of

ESQK and callback number to the
SR, but callback number is not
available.
ESGW generates a nondialable callback number of

the form 911 + last seven
digits of the ESQK, and
delivers call to the SR with
the non-dialable callback
number and the ESQK.
Incoming signaling associated

with emergency call does not
contain sufficient information to
allow SR to successfully invoke
selective routing process.
SR routes call to predefined default PSAP

associated with incoming
trunk group from ESGW.
Location Validation
It is important that civic location information be pre-validated by comparison with validation data
based on the MSAG data maintained by the Emergency Services Provider and/or their designated
E9-1-1 Database provider(s).
In the i2 Solution, location validation shall be performed by the LIS provider. The VDB provides a
mechanism to perform validation on civic location information. There is no validation for geodetic
location data.
Location validation must take place before a call is originated. The purpose of location validation is
to ensure that the location information can be used to properly route an emergency call to the desired
PSAP, and also that the location information provided to the PSAP can be used for dispatch of
responders.
The location validation architecture in the i2 Solution supports a mechanism for the entity seeking
validation of civic location information (e.g., the LIS) to discover the appropriate VDB for any given
serving area. This mechanism is described in Section 3.9.1.
After the appropriate VDB has been identified, the location validation request is sent using the v7
interface described in Section 6.9. The location validation request may include as input a postal or
jurisdictional address 4. The end result of location validation shall be location information that is
sufficient to support mapping to a specific record in the MSAG.
4 Jurisdictional Address: An MSAG valid address for the physical location of a subscriber access line, which has been assigned by
the jurisdictions local addressing authority; i.e., planning department, zoning department, etc. and is used for 9-1-1 emergency
dispatching purposes.
Page 44 of 247

NENA 08-001 v2, August 11, 2010
3.10 Root Discovery Service (RDS)
This section describes the Root Discovery Service as defined in the i2 architecture. It discusses
methods to populate the root discovery database as well as the v9 interface for discovering a VDB
and/or ERDB for a particular location. The v9 interface is detailed in 6.10.
The root discovery mechanism is defined to allow:
Location validation clients (i.e., LISs) to identify the appropriate serving VDB(s) for any
given civic location
VPCs to identify the appropriate serving ERDB(s) for any given civic or geodetic location.
3.10.1 Root Discovery Assumptions

The following assumptions relate to the two applications for the root discovery mechanism.
3.10.1.1 VDB Discovery Assumptions
The prescribed approach to VDB discovery is defined with the following criteria in mind:
There is no assumption that only one provider of validation services exists for a given
location. There may be competition for validation services in the future and the architecture
shall not preclude the ability for more than one VDB provider to validate a given civic
location. However, if there are competing providers, they must all have validation data that
is based on one authoritative source (the MSAG) designated by the local 9-1-1 jurisdictional
authorities.
A local 9-1-1 authority may certify VDB provider(s) to assure the quality of the data.
Discovery may occur fully automatically, or it may involve manual transcribing of location
information and/or network addresses.
There is no assumption made about whether the service will or will not be available to
members of the general public; this being a matter of individual provider policy and/or any
legislative or other constraints which may emerge in the future.
There is an assumption that a single well-known URL will be available to operate as the root
of discovery for VDB services. There is an assumption that the overall guidelines of
operation and technical information associated with the use of VoIP services to access E9-11 will be publicly available on an Internet accessible web site.
3.10.1.2 ERDB Discovery Assumptions

The prescribed approach to ERDB discovery is defined with the following criteria in mind:
There is no assumption that only one provider of ERDB services may identify itself as the
routing service provider for a given geographic coverage area. This is because the MSAGs
on which the routing data is based may have irregular boundaries that do not conform exactly
to jurisdictional boundaries. In addition where GIS data is used, overlaps of GeoShape
polygon data representing ERDB service coverage areas and the uncertainty associated with
Page 45 of 247

NENA 08-001 v2, August 11, 2010
mobile location processes may result in more than one provider being identified for a given
geographic location.
A local 9-1-1 authority may certify ERDB provider(s) to assure the quality of the data.
It is assumed that the ERDB will require authenticated access. It is assumed that discovery
of the ERDBs coverage areas will also require authenticated access.
Discovery may occur fully automatically, or it may involve manual transcribing of location
information and/or network addresses.
It is assumed that the ERDB will generally not be available to members of the general public;
although this may be a matter of individual provider or PSAP policy and/or any legislative or
other constraints which may emerge in the future.
There is an assumption that a single well-known URL will be available to operate as the root
of discovery for ERDB services. This may or may not be the same URL as used for VDB
location validation services. There is an assumption that the overall guidelines of operation
and technical information associated with the use of VoIP services to access E9-1-1 will be
publicly available on an Internet accessible web site.
3.10.2 Root Discovery

3.10.2.1 Service provider data consolidation
Providers of ERDB/VDB services shall be responsible for communicating the identity, URL, and
coverage of their service area(s) to the host of the root discovery service. It is expected that the root
discovery service operator will publish a mechanism by which such information may be
communicated to it. The host of the root discovery service shall also publish a mechanism by which
a 9-1-1 authority shall inform it of the certification status of the ERDB/VDB operator in its area. The
9-1-1 authority will provide written communication about the certification of the ERDB/VDB
provider in their area. The Root Discovery Operator (RDO) will provide a standard form for the
9-1-1 authority to fill out. One possible way to implement certification notification is for the RDO to
provide a web form for the 9-1-1 authority to fill out. No mechanism is defined to facilitate the root
discovery service operator being able to seek out and determine the identity of ERDB/VDB service
providers who do not make themselves known to them.
3.10.2.1.1 VDB Operator Reporting Coverage to Root Discovery Operator
For civic coverage, the VDB Operator shall prepare a file in the same format as the VDB directory
file format described in Section 3.9.3, including only coverage information for its VDB. The Root
Discovery Operator shall maintain a web page with a mechanism for uploading this file.
3.10.2.1.2 ERDB Operator Reporting Coverage to Root Discovery Operator
For civic coverage, the ERDB Operator shall prepare a file in the same format as the ERDB
directory file format described in Section 3.9.4, including only coverage information for its ERDB.
The Root Discovery Operator shall maintain a web page with a mechanism for uploading this file.
Page 46 of 247

NENA 08-001 v2, August 11, 2010
3.10.2.2 ERDB/VDB Discovery File Download
In its most basic form the root discovery URL shall consist of a human readable list of ERDB/VDB
service providers as a table keyed against jurisdictional descriptions of the area of coverage of their
validation service. The table should be presented in alphabetical order by state/province and, if
further breakdown is required, by county (if applicable) in alphabetical order and if necessary, by
municipality in alphabetical order. For each row in the table, a list of ERDB/VDB service provider
URLs shall be provided. A facility to download this table in CSV (Comma Separated Values) format
shall also be supported. The File Download method allows the root discovery server the ability to
download all its ERDB/VDB coverage area information to the requester. Both the initial request for
coverage data and the subsequent request for updates will result in the download of the entire
coverage area information contained in the root discovery server. This mechanism does not allow for
selective downloads, only the entire coverage information present in the root discovery server can be
retrieved using this mechanism. If selected coverage area information is required, the mechanisms
defined in Section 3.9.2.3 and Section 3.9.2.4 can be used.
3.10.2.3 ERDB/VDB Discovery Web Form Query 5
The root discovery service provider shall provide a database query mechanism to discover the ERDB
or VDB. VPC operators would use this mechanism to obtain information about ERDBs; location
validation clients (i.e., LIS operators) would use the same mechanism to obtain information about
VDBs. In this case, the user shall be able to key in a civic address, or fragment of a civic address
(e.g., using a form), including a USPS zip code, or a geographic location (i.e., lat/long coordinate
pair), and have those providers offering the appropriate services for this location returned as a list of
URLs associated with the ERDB/VDB providers.
For Web Form queries using civic location information, the response will return both URLs of the
appropriate VDB/ERDB and the civic location element that was used to determine the URLs. For
example, if the civic query contained State, County and city, but the root discovery used the county
to determine the URLs, the county name will be sent back in the response. This mechanism is used
for both normal and abnormal operation. If the civic query contained ambiguous entries, for
example, the state and city did not match; the root discovery server will send coverage information
for the State as this is the highest level that did not result in ambiguity. The response will contain
VDB/ERDB URLs for those ERDBs/VBDs that cover the entire state.
For Web Form queries using geodetic location information, the response will return the URLs of the
appropriate ERDB providers and the Percentage Overlap Confidence (POC) value associated with
the ERDB. The POC value describes the percentage of the initially provided caller-location that
overlaps with the corresponding ERDB service area. More information on how the POC value is
calculated is described in Section 8.4.4.
5 The Root Discover Operator will provide two HTTP based services, a web form and a web service. The former is used manually to
create a query by filling out a form on the RDO web server, and seeing the results presented in human readable form. The latter is
used by a computer system, submitting an XML based query and receiving an XML result.
Page 47 of 247

NENA 08-001 v2, August 11, 2010
This document provides no solution for synchronization if data is provided by different providers for
the same area.
3.10.2.4 ERDB/VDB Discovery Web Services
The root discovery service provider shall also support an automated discovery mechanism such that
the available ERDB or VDB service providers for a given location can be determined via an XMLbased web query. This interface is implemented using web services. For identifying the VDB, the
semantics of this query shall be as follows:
<v9:identityRequest xmlns:v9="urn:nena:xml:ns:es:v9"
xmlns:alins=http://www.nena9-1-1.org/schemas/2003/ali
xmlns:gml=http://www.opengis.net/gml
xmlns:gs=http://www.opengis.net/pidflo/1.0"
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation="urn:nena:xml:ns:es:v9 v9.xsd">
<v9:civiclocation>
<v9:HouseNum>700</v9:HouseNum>
<v9:PrefixDirectional>N</v9:PrefixDirectional>
<v9:StreetName>LAVACA</v9:StreetName>
<v9:StreetSuffix>ST</v9:StreetSuffix>
<v9:MSAGCommunity>AUSTIN</v9:MSAGCommunity>
<v9:CountyName>TRAVIS</v9:CountyName>
<v9:StateProvince>TX</v9:StateProvince>
<v9:PostalCode>78701</v9:PostalCode>
<v9:Country>US</v9:Country>
</v9:civiclocation>
</v9:identityRequest>
and the response shall be similarly formatted to provide a status of:

Found
NotFound, or
Ambiguous.
Similarly, for identifying the ERDB using a civic address, the semantics of the query shall be as
follows:
Page 48 of 247

NENA 08-001 v2, August 11, 2010
<erdb-identity-request
xmlns=urn:nena:xml:ns:es:erdbdiscover
xmlns:xsi=http://www.w3c.org/2001/XMLSchema-instance
xsi:schemaLocation=urn:nena:xml:ns:es:erdbdiscover erdbdiscover.xsd>
<vlocation>
<geopriv cl:civicAddress coded location>
</vlocation>
</erdb-identity-request>
For identifying the ERDB using geodetic location data, the semantics of the query shall be as
follows:
<v9:identityRequest xmlns:v9="urn:nena:xml:ns:es:v9"
<gml:Point srsName="urn:ogc:def:crs:EPSG:6.6:4326">
<gml:pos>37.775 -122.4194</gml:pos>
</gml:Point>
</v9:identityRequest>
The responses for both civic and geodetic requests shall be similarly formatted to provide a status of:
Found
NotFound, or
Ambiguous.
For a status of Found, depending on the type of query, the response shall include a list of URLs for
ERDB providers that offer routing determination for that location or a list of VDB providers who
offer validation services for that location. For NotFound, there are no other response parameters
provided. For Ambiguous, those cl:CivicAddress fields which need to be resolved before a definitive
list of providers can be returned shall be provided.
Input is made to the root discovery database containing either civic location, (Postal or MSAG) or
geographic location (lat/long). For a civic location, the query will only operate based on a general
set of input fields, such as community name, county, Zip code, and state. Specific civic location
elements, such as house number and street name will be ignored.
ERDB/VDB queries include both a postal and MSAG community name. For the root discovery
function, if the querier knows BOTH the community names, they will both be matched to determine
Page 49 of 247

NENA 08-001 v2, August 11, 2010
the ERDB/VDBs returned from a root discovery query. If only one is known, and it is known that it
is the MSAG community name, the postal community name should be sent empty, and a match on
MSAG community name will be made. If only one is known, and it is known that it is the Postal
community name, the MSAG community name should be sent empty, and a match on Postal
community name will be made. If the querier has only one community name, and it does not know
which type of community name it has, the postal community name should be used, with the MSAG
community name blank.
The root does not distinguish between MSAG community and Postal community in its database.
Therefore, a query supplying both, but reversed (postal community name in the msag community
name field and vice versa), will produce the same results as one with the community names correctly
supplied.
3.10.2.5 Load Balancing
Where a client is provided with multiple VDB/ERDB addresses the client may choose to round robin
the results to ensure even distribution.
3.10.3 VDB Directory File Format
The VDB directory file shall consist of a header identifying the following:
Special file identifier tag string including format version

Applicable country
URL of source of file
Date and time of creation of the file
Expiry date and time of the file (by which the source URL must have a new version of the
file with potential changes)
Each of the above pieces of information will be on a new line in the file and be provided in order.
Formats for each of the items will be as follows.
The special identifier string and version line shall be the first line of the file and shall have the form:
%!VDB-Directory-file V<version>
Where <version> is a decimal integer of one or more digits and is greater than or equal to one (1).
The applicable country is a string representing the country of coverage. The strings USA or Canada
shall be used for these countries. For example:
USA
The URL of the source file will be a standard dot delimited URL of the entity which generated the
data file. Nominally this is the VDB root discovery URL. For example:
vdbroot.nena.org
The date and time of creation of the file shall be in the form:
Created <time>
Page 50 of 247

NENA 08-001 v2, August 11, 2010
Where <time> indicates when the file content was generated by the source and is of the form
YYYY:MM:DD HH:mm:SSZ
Where YYYY is the four digits representing the year, MM is the zero leading two digits representing
the month, and DD is the zero leading two digits representing the day number of the month. HH is
the zero leading hour of day, from 00 to 23. mm is the zero leading integer minutes of the hour and
SS is the zero leading integer seconds of the minute, both from 00 to 59. Z specifies that the time is
Zulu time.. The date and time of file creation date shall be provided in the universal time coordinated
(UTC) and not be specific to a particular time zone. Since the root reports coverage over multiple
time zones, and the location of the requestor may not match that of the VDB/ERDB operator or the
RDO, a time-zone independent time is required.
The date and time of effect for the file shall be in the form
TakesEffect <time>
The RDO will ensure that TakesEffect <time> will be equal to or less than the Expires <time>.
The effect date and time of the file shall be expressed using the same specification, in UTS, as the
creation date and time. This will be a date and time at which the contents of the file may be regarded
as valid. It shall be no earlier than the creation time and will supersede the contents of any previous
file at that time even if the expiry time of the previous file is after the effect time.
The date and time of expiry for the file shall be in the form
Expires <time>
The expiry date and time of the file shall be expressed using the same specification, in UTS, as the
creation date and time. This will be a date and time no earlier than the effect time. The contents of
the file must be considered invalid at this time and a file with a later effect time than the effect time
of this file must have been retrieved and its contents available to replace the current contents at least
by the time of expiry.
The rest of the file shall consist of the data representing VDB URLs which service indicated
locations. It will be provided as an alphabetically ordered comma separated set of values (CSV) with
each data record commencing on a new line. Each line will have the following format:
<State>, <County>, <Municipality>, <Zip code>, <VDB URL list>
The <State> value will have any one of the standard country specific (e.g.,USPS) 2 character
state/province abbreviations (e.g. CA, WA, TX).
The <County> value will correspond to the country specific (e.g.,USPS) spelling of the county name
(e.g. Collin as in Collin County, Texas).
The <Municipality> value will correspond to the country specific (e.g., USPS) spelling of the
municipality name of interest (e.g. Plano, as in Plano, Collin County, Texas). Entries include ALL
of: postal, jurisdictional, MSAG community names.
Page 51 of 247

NENA 08-001 v2, August 11, 2010
The <postal code> value will correspond to the local Postal code (in the U.S. 5 digits only and in
Canada 6 characters only).
The VDB URL list shall be a semicolon separated list of URLs identifying the address of VDB
services that provide validation for the location indicated by the State-County-Municipality values
preceding this value. A URL list may be blank.
Records shall be provided in alphabetical order by row with each state/county grouping according to
the following convention.
State,
State,
State,
of zip
State,
*, *, *, <urls for all counties of this state not listed>

County, *, *, <urls for all municipalities of this county not listed>
County, Municipality, *, <urls for the specific municipality, regardless
code>
County, Municipality, zipcode, <urls for the specific zip code>
Note Where no record is provided for a particular state, this shall be equivalent to the situation
where a State, record is provided with an empty URL list. That is, it shall be interpreted that there
are no VDB facilities for that state.
Information in the file is order dependent by line. Lines may be blank and blank lines may be
ignored. End of line may be in DOS or UNIX format and indicated by either a carriage return/line
feed <CR><LF> or just a <CR>. All other whitespace characters may be ignored except where it
forms part of a state, county, or municipality name where they may be interpreted as a single space
character. State, county, and municipality names shall not include a comma or asterisk and should be
limited to alphabetical, space, and hyphen characters.
Page 52 of 247

NENA 08-001 v2, August 11, 2010
3.10.3.1 Example VDB Directory File
%!VDB-Directory-file V1
USA
vdbroot.nena.org
Created
TakesEffect
Expires
2005:06:22 14:35:26Z
2005:06:26 00:01:00Z
2005:07:27 00:00:00Z
AL, *, *, *, vdbse.sbc.com
AL, Autauga, *, *, vdbse.sbc.com
AL, Autauga, Montgomery, *, vdb.rnopco.com;vdbse.sbc.com
AL, Autauga, Pratville, 36067, vdb.rnopco.com
AK, *, *, *, vdbak.bpac.com
AS, *, *, *, americansamoa-territorialauthority-vdb.asta.gov
:
: denotes actual contents not shown for brevity
:
FM, *, *, * [comment example of blank list; e.g. no VDB for Federated States
of Micronesia at this stage]
:
:
TX, *, *, *, vdbsw.sbc.com
:
:
WY, *, *, *, vdbwy.bigsky911.com;vdbnc.bpac.com
<eof>
3.10.4 ERDB directory file format

The ERDB directory file shall consist of a header identifying the following:
Special file identifier tag string including format version

Applicable country
file with potential changes).
Each of the above pieces of information will be on a new line in the file and be provided in order.
Formats for each of the items will be as follows.
The special identifier string and version line shall be the first line of the file and shall have the form:
Page 53 of 247

NENA 08-001 v2, August 11, 2010
%!ERDB-Directory-file V<version>
where <version> is a decimal integer of one or more digits and is greater than or equal to one (1).
The applicable country is a string representing the country of coverage. The strings USA or Canada
shall be used for these countries. For example:
Canada
data file. Nominally this is the ERDB root discovery URL. For example:
vdbroot.nena.org
Created <time>
Where <time> indicates when the file content was generated by the source and is of the form
YYYY:MM:DD HH:mm:SSZ
Where YYYY is the four digits representing the year, MM is the zero leading two digits representing
the month, and DD is the zero leading two digits representing the day number of the month. HH is
the zero leading hour of day, from 00 to 23. mm is the zero leading integer minutes of the hour and
SS is the zero leading integer seconds of the minute, both from 00 to 59. Z specifies that the time is
Zulu time The date and time of file creation date shall be provided in the universal time system
(UTS) and not be specific to a particular time zone as the root reports coverage over multiple time
zones, and the location of the requestor may not match that of the VDB/ERDB operator or the RDO.
The date and time of effect for the file shall be in the form
TakesEffect <time>
The effect date and time of the file shall be expressed using the same specification, in UTC, as the
The date and time of expiry for the file shall be in the form
Expires <time>
The expiry date and time of the file shall be expressed using the same specification, in UTC, as the
The rest of the file shall consist of the data representing ERDB URLs which service indicated
locations. It will be provided as an alphabetically ordered comma separated set of values which each
data record commencing on a new line. Each line will have the following format:
<State>, <County>, <Municipality>, <zip code>, <ERDB URL list>
Page 54 of 247

NENA 08-001 v2, August 11, 2010
The <State> value will have any one of the standard country specific (e.g., USPS) 2 character
state/province abbreviations (e.g. CA, WA, TX).
The <County> value will correspond to the country specific (e.g.,USPS) spelling of the county name
(e.g. Collin as in Collin County, Texas).
The <Municipality> value will correspond to the country specific (e.g., USPS) spelling of the
municipality name of interest (e.g. Plano, as in Plano, Collin County, Texas). Entries include ALL
of: postal, jurisdictional, and MSAG community names.
The <zipcode> value will correspond to the local Postal Code (e.g. 5 digits in the U.S., 6 characters
in Canada).
The ERDB URL list shall be a semicolon separated list of URLs identifying the address of ERDB
services that provide routing and translation for the location indicated by the State-CountyMunicipality values preceding this value. A URL list may be blank.
Records shall be provided in alphabetical order by row with each state/county grouping according to
the following convention.
State,
State,
State,
code>
State,
*, *, *, <urls for all counties of this state not listed>

County, *, *, <urls for all municipalities of this county not listed>
County, Municipality, *, <urls for the specific municipality, any zip
County, Municipality, zipcode, <urls for the specific zip code>
Note Where no record is provided for a particular state, this shall be equivalent to the situation
where a State, record is provided with an empty URL list. That is, it shall be interpreted that there
are no ERDB facilities for that state.
Information in the file is order dependent by line. Lines may be blank and blank lines may be
ignored. End of line may be DOS or UNIX format and indicated by either a <CR><LF> or just a
<CR>. All other whitespace characters may be ignored except where it forms part of a state, county,
or municipality name where they may be interpreted as a single space character. State, county, and
municipality names shall not include a comma or asterisk and should be limited to alphabetical,
space, and hyphen characters.
3.10.4.1 Example Directory File Format Civic Coverage
Below is an example ERDB Directory file in civic format.
Page 55 of 247

NENA 08-001 v2, August 11, 2010
%!ERDB-Directory-file V1
USA
erdbroot.nena.org
Created
TakesEffect
Expires
2005:06:22 14:35:26Z
2005:06:26 00:01:00Z
2005:07:27 00:00:00Z
AL, *, *, *, erdbse.sbc.com
AL, Autauga, *, *, erdbse.sbc.com
AL, Autauga, Montgomery, *, erdb.rnopco.com; erdbse.sbc.com
AL, Autauga, Pratville, 36067, erdb.rnopco.com
AK, *, *, *, erdbak.bpac.com
AS,*, *, *, americansamoa-territorialauthrty-erdb.asta.gov
:
:
FM, *, *, * [comment example of blank list; e.g. no ERDB for Federated States
of Micronesia at this stage]
:
:
TX, *, *, *, erdbsw.sbc.com
:
:
WY, *, *, *, erdbwy.bigsky911.com; erdbnc.bpac.com
<eof>
3.10.5 ERDB Directory File Format Geodetic Coverage

The ERDB geodetic directory file when sent from the ERDB operator to the RDO shall be an XML
file with a header containing the following:
The ERDB URI (e.g., htpps://www.erdb.harriscounty.tx.gov/erdb.html)

The ERDB common name (Harris County Texas ERDB)
The date and time the file becomes effective
file with potential changes)
data file. Nominally this is the ERDB root discovery URL.
<erdbURI>https://www.erdb.harriscounty.tx.gov/erdb.html</erdbURI>
The ERDB common name will be represented in a human-readable and recognizable format.
Page 56 of 247

NENA 08-001 v2, August 11, 2010
<erdbCommonname>Harris County Texas ERDB</erdbCommonname>
<createDate>yyyy-MM-ddThh:mm:ssZ</createDate>
Where [yyyy] is the four digits representing the year, [MM] is the zero leading two digits
representing the month, and [dd] is the zero leading two digits representing the day number of the
month. [hh] is the zero leading hour of day, from 00 to 23. [mm] is the zero leading integer minutes
of the hour and [ss] is the zero leading integer seconds of the minute, both from 00 to 59. The date
and time of file creation shall be provided in the Universal Time Coordinated (UTC) using the ISO
8601 [44] format and not be specific to a particular time zone. Since the root reports coverage over
multiple time zones, and the location of the requestor may not match that of the VDB/ERDB
operator or the RDO, a time-zone independent time is required.
The date and time of effect for the file shall be in the form:
<effectDate>yyyy-MM-ddThh:mm:ssZ</effectDate>
The effect date and time of the file shall be expressed using the same specification, in UTC, as the
The date and time of expiry for the file shall be in the form:
<expiryDate>yyyy-MM-ddThh:mm:ssZ</expiryDate>
The expiry date and time of the file shall be expressed using the same specification, in UTC, as the
Following the header shall be the definition of the GeoShape polygon representing the ERDB
coverage boundary expressed as a series of polygon points similar to those shown in Figure 3-5,
Page 57 of 247

NENA 08-001 v2, August 11, 2010
Figure 3-5 ERDB Coverage Polygon
A complete ERDB geo directory will consist of the above definitions for all ERDBs served by the
RDO.
An example of an ERDB geodetic directory file is presented below.
3.10.5.1 Example ERDB Geodetic Directory File
Below is an example of an ERDB Geodetic Directory File:
Page 58 of 247

NENA 08-001 v2, August 11, 2010
<?xml version="1.0"?>
<erdbBoundaryDefinition xmlns="urn:nena:xml:ns:es:geoErdbRdo"
xsi:schemaLocation="urn:nena:xml:ns:es:geoErdbRdo.xsd">
<erdbID>
<createDate>2006-10-01T13:00:00Z</createDate>
<effectDate>2006-10-05T17:00:00Z</effectDate>
<expiryDate>2006-11-01T13:00:00Z</expiryDate>
</erdbID>
<gml:Polygon srsName="urn:ogc:def:crs:EPSG:4326"
xmlns:gml="http://www.opengis.net/gml">
<gml:exterior>
<gml:LinearRing>
<gml:pos>42.556844 -73.248157</gml:pos>
<gml:pos>42.549631 -73.237283</gml:pos>
<gml:pos>42.539087 -73.240328</gml:pos>
<gml:pos>42.535756 -73.254242</gml:pos>
<gml:pos>42.542969 -73.265115</gml:pos>
<gml:pos>42.553513 -73.262075</gml:pos>
<gml:pos>42.556844 -73.248157</gml:pos>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</erdbBoundaryDefinition>
3.10.5.2 RDO Directory File Format

When the RDO constructs a file for distribution, it will contain multiple instances of this XML
structure, one for each ERDB coverage area.
3.11 PSAP Call Control Features
Many PSTN emergency services deployments in North America and around the world, implemented
specific call control features that fulfill particular needs in handling emergency situations, beyond
the core Enhanced 9-1-1 feature set (selective routing, selective transfer, ANI and address display).
In fact, some jurisdictions even mandate the availability of some of these features. NENA-03005[45] provides descriptions of some of the PSAP Call Control Features covered herein. This
feature set allows PSAP attendants to keep control over emergency calls and their disposition.
Not all jurisdictions have implemented PSAP Call Control features. This section is applicable solely
to jurisdictions that currently support or are planning to support those features and who want to
extend these capabilities into the IP domain. It is up to the 9-1-1 Authorities to determine if PSAP
Call Control features shall be supported for their respective 9-1-1 jurisdictions.
Page 59 of 247

NENA 08-001 v2, August 11, 2010
This section describes how PSAP Call Control Features will be supported in the i2 architecture for
jurisdictions requiring them.
While the VEP and the v1 interface are out-of-scope of this document, specific references to those
are required to ensure proper end-to-end functionality. Further, the following assumptions are
considered:
The VEP is compliant with IETF best current practices as defined in draft-ietf-ecritphonebcp;
The VEP has knowledge of the emergency session occurring;
The VEP has knowledge of PSAP Call Control features being enforced;
The VEP supports the PSAP Call Control features as defined herein.
Traditionally PSAP Call Control features include:
Called Party Hold

Enhanced Called Party Hold
Switch Hook Status
Ringback (On and Off-Hook)
The Called Party Hold feature, also known as Connection Hold, Bureau Hold, Network Hold and
Originator Hold, allows the voice path and other resources associated with a 9-1-1 call to remain,
even if the caller hangs up (goes on-hook). This "disconnect pending" state is sustained until the
PSAP attendant hangs up or some specific timer expires. While in the "disconnect pending" state, if
the caller picks up again, the caller will find themselves connected to the attendant. The Called
Party Hold feature is the parent of Enhanced Called Party Hold, Switch Hook Status, and Ringback.
As a complement to the Called Party Hold feature, Enhanced Called Party Hold allows the voice
circuit to be established even though the PSAP attendant hasn't yet answered when the caller hangs
up. Once the attendant picks up, regular connection hold capabilities apply. Therefore, if the caller
picks up again, his conversation with the attendant will resume.
The Switch Hook Status feature, also known as Disconnect Signal, allows the PSAP attendant to
detect that the caller has either hung up (on-hook) or picked up the phone (off-hook). A particular
tone is generated to signal the PSAP attendant of the change in the "hook status" of the caller. In an
i2 implementation that supports PSAP Call Control features, additional signaling must be sent from
the VEP to the ESGW whenever the caller goes on-hook or off-hook. Note that the ability for the
PSAP attendant to hear the switch hook status tone is dependant on the ability of the SR and/or
PSAP CPE to generate it. If either the VEP or the PSAP do not support Switch-hook Status on top
of Called Party Hold as described above, the feature will not be enforced end-to-end. As such, a
caller going on-hook may go unnoticed.
The Ringback feature enables the PSAP attendant to invite back an emergency caller, or someone in
the vicinity of the phone, into the conversation. This feature has different behaviors depending on
Page 60 of 247

NENA 08-001 v2, August 11, 2010
the state of the device (on-hook or off-hook). First, while a conversation between caller and PSAP
attendant is occurring, it allows the attendant to request that a special audible tone (for example
receiver off-hook tone) be played at the caller's device. Second, as a complement to the Called Party
Hold feature, it allows the attendant to request that the caller's device rings, if it has been hung up.
Note that Ringback is different from call back as the former occurs during an emergency session
while the latter does not.
3.11.1 Requirements
This section describes the PSAP Call Control requirements.
3.11.1.1 Requirements for Called Party Hold, Switch-Hook Status and Ringback
Industry discussion is currently taking place to define detailed call flows to support Called Party
Hold and the associated features described above. It is expected that some modifications to the SIP
protocol will be necessary to support Called Party Hold feature functionality. In an effort to
progress the work, the following requirements for Called Party Hold, Switch-Hook Status and
Ringback have been identified.
1. It must be possible to have the PSAP rapidly re-establish communications with a caller that
attempts to prematurely disconnect from the call.
Rationale: Time is paramount when handling emergency calls. Keeping resources active and
available until the call taker determines the call can be terminated saves valuable time.
2. It must be possible for the PSAP to know when the user has attempted to prematurely
disconnect (switch-hook status).
Rationale: Knowledge of the device state (and caller action) gives valuable information to
the call taker which may influence how the call will be managed going forward.
3. It must be possible for the PSAP to know when a user that has previously attempted to
prematurely disconnect attempts to reconnect (switch-hook status).
Rationale: Knowledge of the device state (and caller action) gives valuable information to
the call taker which may influence how the call will be managed going forward.
4. Reconnecting the caller must work reasonably reliably under congestion conditions.
Rationale: PSAPs require robust mechanisms to perform their tasks.
5. When CPH is enforced, the PSAP must be able to cause alerting at an endpoint which has
attempted to prematurely disconnect from the emergency call, or when the caller has gone
silent without having disconnected (Ringback).
Rationale: The user believes they have disconnected, or is unable to communicate. The
ability to alert is needed to encourage the user or someone in the surroundings to reconnect
with the call taker.
6. While CPH is enforced, the caller must not be able to place another call until the call is
released either by the PSAP or by other mechanisms.
Rationale: Priority must be given to the PSAP until such time the call taker determines the
call can be terminated.
Page 61 of 247

NENA 08-001 v2, August 11, 2010
7. A rapid resumption of communication, between the caller and the PSAP, following a
premature disconnection attempt will be supported.
Rationale: Premature disconnection will leave the PSAP unable to obtain important
information. Rapid resumption mitigates this issue.
8. Called Party Hold is not needed in all jurisdictions. It must be possible to not invoke the
function and allow premature disconnect to terminate the call as if no special features were
present.
Rationale: This reflects the current situation.
3.11.1.2 Requirements for Enhanced Called Party Hold
In addition to the requirements for Called Party Hold, Switch Hook Status, and Ringback identified
above, the following requirements apply to the Enhanced Called Party Hold feature:
1. It must be possible to complete an emergency call (once it has been recognized as an
emergency call) to a PSAP even if the caller hangs up before the call is presented to the
PSAP.
Rationale: PSAPs cannot distinguish between calls which are appropriately disconnected
and calls that need response but were cut short. This feature allows PSAPs to respond to
calls that a user has attempted to disconnect.
2. Enhanced Called Party Hold shall be applied at the earliest possible time in the call
establishment process.
Rationale: Disallowing call abandonment early minimizes the chances of abandoned calls.
3. Enhanced Called Party Hold is not needed in all jurisdictions. It must be possible to not
invoke the function and allow calls to be abandoned as if no special features were present.
Enabling or disabling must be dynamic, so that it can be enforced or not depending on
requirements at the PSAP.
Rationale: This reflects the current situation.
3.11.2 ESGW Interworking Requirements
Due to the hybrid nature of the i2 architecture, the ESGW plays a determining role in supporting the
PSAP Call Control Features. In fact, the ESGW being the entity that sits on the edge of both the IP
domain and the Emergency Services Provider Network, it is responsible for all signaling and media
protocol mediation. It is recommended that the ESGW implement Connection Hold network
capabilities on the SS7 protocol as specified in ANSI T1.666 [50] (Section 4 - Connection Hold
Network Capability) and ANSI T1.628a [49], where SS7 interconnection is implemented to the SR.
ESGW interworking requirements associated with MF interconnection to the SR are left for future
study. The specifics of the protocol interworking between SIP and SS7 ISUP that must be supported
by the ESGW will depend on industry agreement being reached with respect to modifications of the
SIP protocol to support Called Party Hold, Switch Hook Status, and Ringback.
It is expected that PSAP Call Control features support at the ESGW will be requested through the
SR operator by 9-1-1 Authorities. As such, it will be up to the SR and ESGW operators to properly
Page 62 of 247

NENA 08-001 v2, August 11, 2010
configure the trunking arrangement between the SR and the ESGW to allow such support for the
targeted 9-1-1 jurisdictions.
Security
The critical nature of the E9-1-1 Emergency Services Network makes it essential to ensure that the
E9-1-1 network is properly protected. The i2 solution introduces new network elements, new
underlying transport networks and protocols to the E9-1-1 Emergency Services network. Note that a
number of protocol interfaces are outside the scope of the 9-1-1 system (v0/v1) and several that are
between elements that are considered to be within the 9-1-1 system (v2, v3, v4, v5, v6, v7, v8, v9
and v-E2). The former are specified by other standards organizations, such as the IETF. The latter
are defined in this document. For the interfaces within the scope of this document, the security
mechanisms are dependent on the specifics of the underlying network joining the various i2 solution
network elements.
Specifically, if the network that joins the network elements is private, secured, and managed such
that there is no reasonable possibility that anyone not specifically authorized to see E9-1-1 data (and
specifically location data) has access to any systems on that network, it will not be required to
deploy additional security measures. It should be noted that it is extremely difficult to guarantee that
a network is completely private, secured and managed with no reasonable possibility of unauthorized
access, therefore it is not recommended that such walled gardens be the only security provided. It
is recommended that even if private networks are used to implement the i2 interfaces, additional
security mechanisms described in this section be used.
The following sections provide recommendations on the steps that can be taken to minimize the risk
of compromise to the E9-1-1 network.
4.1
Authentication
Authentication is the process of verifying the claimed identity of a session requester. Mutual
authentication is important to ensure that both the originator of the session and the recipient of the
request are both satisfied with the credential information being provided. Authentication
mechanisms are needed in the i2 solution to ensure that only trusted entities with existing
relationships will be provided access to E9-1-1 data and services.
Authentication in the i2 solution is provided by using certificates. A certificate is a data object that
includes the servers identity and its public key. The certificate is signed by computing its hash value
and encrypting it using a certificate authoritys private key. A certificate authority is a trusted third
party that issues digital certificates. The certificate authority guarantees that the holder of the digital
certificate is who they claim to be. NENA shall create (or contract for) a Valid Emergency Services
Authority (VESA) to operate as a certificate authority, and to be the root of all certificates issued to
entities participating in an i2 call.
Page 63 of 247

NENA 08-001 v2, August 11, 2010
It is recommended that elements involved in the i2 solution deploy strong authentication methods
such as RSA-1024 [20]or better, as documented in RFC2313[14] using X.509 certificates [21] and
Certificate Revocations Lists as profiled in RFC 3280[15] and best current practices.
4.2
Message Integrity
Message integrity mechanisms provide protection against unauthorized message modifications. One
of the ways this is accomplished is by using one-way hash functions. Hashing is the transformation
of a string of characters into a usually shorter, fixed-length value that represents the original string. If
the original message is tampered with, the message hash will not match the original message. This
helps to detect that the message was tampered with.
It is recommended that elements involved in the i2 solution deploy message integrity using Secure
Hashing Algorithm-1 (SHA-1), as defined in RFC 3174 [19] or better.
4.3
Message Encryption
Message encryption is a process of disguising a message in such a way as to hide its substance. The
need for encryption of messages is a function of the level of confidence in the network being used to
implement the i2 solution interfaces. If the network being used to implement an i2 solution interface
is vulnerable, then encryption techniques should be implemented to protect the messages.
If encryption is needed, Advanced Encryption Standard (AES), Federal Information Processing
Standards Publications (FIPS) PUB 197[16] or better will be used as the means to encrypt the
messages.
4.4
Network Element Security
An important aspect of maintaining security in a network is ensuring that the network elements that
constitute the network are secure. This includes physical security of the equipment and ensuring that
data contained in the network elements are accessed by only those personnel that have a need to
access the data.
It is recommended that network elements involved in the i2 solution employ authorization and
privacy mechanisms to protect E9-1-1 data.
The network elements should support the ability to authenticate users, control user access privileges,
initiate audit trails, report security alarms, recover from intrusions, and monitor data and system
integrity.
4.5
Network Layer Security
If the i2 solution interfaces are implemented on a network that is not private, secure and managed,
tunneling is an alternative that could be used to implement the interfaces. One acceptable mechanism
is to use IPsec [17] tunnels with strong authorization, integrity protection and privacy, at least
equivalent or stronger than RSA-1024/SHA-1/AES joining network elements which are secured, and
managed such that there is no reasonable possibility that anyone not specifically authorized to see
Page 64 of 247

NENA 08-001 v2, August 11, 2010
E9-1-1 data (and specifically location data) has access to any system within the networks defined by
such tunnels. Note that this usually implies that the tunnels are established between the actual
network elements running the protocols, rather than the local area network on which such elements
reside.
If tunneling is used to implement the i2 solution interfaces, it is recommended that IPsec, RFC 4301
[17], be used with strong authentication using RSA-1024 or stronger, integrity protection using
SHA-1 or better and ensuring privacy using AES or better.
4.6
Application Layer Security
The applications themselves can be secured using, for example, Transport Layer Security (TLS),
RFC 4346 [22], with strong authorization, integrity protection and privacy, at least equivalent or
stronger than RSA-1024/SHA-1/AES (RFC5246[23]) as long as the systems the protocols are
running on are reasonably protected against unauthorized persons being able to modify the
applications.
It is recommended that TLS be used to secure the following vX interfaces: v2, v3, v4, v5, v6, v7, v8,
and v9.
4.7
Location Data Security
The existing Emergency Services Network provides a relatively high degree of security for
correctness of information, integrity, and authorization of access, authenticity/secrecy, and accuracy
of information. The intent of the NENA i2 solution is to provide functional equivalency to the
existing network services in an IP-based environment, and this includes ensuring that the location
information is valid and secure.
Voice over IP presents new challenges and security issues as it breaks the bond between access and
service provider characteristic of legacy networks, and at this time, lacks the legislative and
regulatory requirements that apply to more conventional telephony services. These security threats
present themselves in a number of forms and have varying degrees of severity, should they be
exploited to their full potential. This section attempts to outline the key security concerns related to
location data, and where in the i2 solution these concerns are best addressed. This section does not in
itself provide solutions to these concerns.
Current networks use location information to route calls to the local PSAP, and to provide a location
to which emergency responders may be dispatched. Three important characteristics of existing
networks contribute to the security of these functions:
1. The source of the location is attributable to a specific trusted source. Location is provided by
the access/voice service provider.
2. The location information is applicable to a specific point in time. The location information is
either used to directly route the call (as may be the case for wireless), or indirectly via the
calling number/ANI (as for wireline). It is always retrieved at the time of call receipt.
Page 65 of 247

NENA 08-001 v2, August 11, 2010
3. The location information can be identified as belonging to a specific end-point. This may be
a direct association as is the case with wireline, or it may be an indirect association, as is the
case with Emergency Services Routing Keys (ESRKs) in wireless. The location information
is known to apply specifically to the calling device; another devices location cannot be
misrepresented as the calling devices location.
In order to provide service equivalence therefore, the location information obtained and used in the
delivery of VoIP emergency calls must satisfy these three requirements.
The i2 solution proposes a Location Information Server (LIS) be the source for distributing location
information within an access network. Furthermore the validity, integrity and authenticity of this
information are directly attributed to the LIS operator. The i2 solution therefore should provide:
1. A mechanism to ensure that location data has been provided by a LIS with a known
responsible operator and that it has not been changed, forged, tampered with, spoofed or
replayed by any other party, including the user, since that LIS provided the data.
2. A mechanism to ensure that a location object (PIDF-LO document) cannot be applied to
more than one calling device.
3. A mechanism to ensure that the location information is still true and applicable to the calling
device at the time it is provided to the emergency network.
The majority of security concerns for the i2 solution are therefore focused on ensuring that location
information is accurate, valid, authentic and associated with a specific call instance. While secrecy
and privacy of location information may be of some importance, these are deemed secondary to
routing and PSAP requirements. Sections defining the individual i2 element interfaces will provide
requirements addressing specific security aspects of each interface.
Location configuration and conveyance requirements are described in NENA 08-752[27], but
guidance is offered here on what should be considered when designing mechanisms to report
location:
1. The location object should be digitally signed.
2. The certificate for the signer (LIS operator) should be rooted in VESA. For this purpose,
VPC and ERDB operators should issue certificates to LIS operators.
3. The signature should include a timestamp.
4. Where possible, the Location Object should be refreshed periodically, with the signature (and
thus the timestamp) being refreshed as a consequence.
5. Antispoofing mechanisms should be applied to the Location Reporting method.
Page 66 of 247

NENA 08-001 v2, August 11, 2010
Functional Requirements
This section provides high-level functional requirements for the new elements in the i2 solution
architecture that are described briefly in Section 3.3. For elements defined in other standards (e.g.,
Call Server, Routing Proxy, Redirect Server), this document identifies only incremental functional
requirements to support the i2 solution.
5.1
VSP Call Server/Proxy
This element is owned by the VSP and is always present, and always in the signaling path of a call.
If the signaling protocol is SIP, this element is a proxy server as defined in RFC3261. The VSP Call
Server receives a call from one of its subscribers on the v1 interface and must recognize that it is an
emergency call. Procedures for this vary depending on protocol and end device capability. For SIPbased systems, VSPs must be capable of recognizing an emergency call (e.g., based on the tel-URI
with digits 911, a SIP-URI with a dial string of 911 in the user part, and eventually recognizing
<urn:service:sos> ).
Upon determining that a call is an emergency call, the VSP must determine the location of the caller.
Location information may accompany the call (in SIP, this would be in the form of a PIDF-LO body
in the INVITE message), may be requested of the endpoint, or the VSP may have access to a LIS
which has the location of the caller. 6 In addition, upon determining that a call is an emergency call,
the VSP Call Server must determine, using local procedures, the provisioned callback number and
subscriber name associated with the address of record for the subscriber.
The VSP CS may be implemented in one of several ways:
1. It may operate or contract with a VPC.
2. It may operate or contract with a RP.
3. It may operate or contract with a RS.
In case 1, the VSP CS maintains a v2 interface. It queries the VPC for Routing Information/ESQK
by sending information on the v2 interface. The VSP CS may be required to translate an ERT to an
ESGWRI, based on business arrangements between the VSP and VPC provider. The VSP CS
maintains routing data which maps an ESGWRI to the URI of the appropriate ESGW. It uses this
data to obtain the URI, and forwards the call on the v4 interface, with the ESGWRI, ESQK, callback
number, and optionally subscriber name to the ESGW. At the end of the call, the Call Server/Proxy
is responsible for sending a call termination message to the VPC which includes the identity of the
ESGW that was used for the call.
In case 2, the VSP CS unconditionally forwards all emergency calls (along with the associated
callback number, subscriber name information and LO and/or LK) to the RP on the v6 interface. The
RP is expected to interact with the VPC to obtain call routing information and to forward the call to
6 The ability for the VSP call server or other proxies in the call path to retrieve location when it is not available from the endpoint has
been included in Section 8.8 as a potential item for investigation in a future issue of this document.
Page 67 of 247

NENA 08-001 v2, August 11, 2010
the correct ESGW. The RP may be required to translate an ERT to an ESGWRI, based on business
arrangements between the VSP and VPC provider.
In case 3, the VSP CS unconditionally forwards all emergency calls (along with the associated
callback number, subscriber name information, and LO and/or LK) to the RS on the v5 interface. It
should receive the call back from the RS with an ESQK and either an ESGWRI or an ERT. The VSP
CS may be required to translate an ERT to an ESGWRI, based on business arrangements between
the VSP and VPC provider .The VSP CS maintains routing data which maps an ESGWRI to the URI
of the appropriate ESGW. It uses this data to obtain the URI, and forwards the call on the v4
interface, with the ESGWRI, ESQK, PIDF-LO, callback number, and optionally subscriber name to
the ESGW. The CS notifies the RS when the call has terminated and this indication contains the
identity of the ESGW that was used for the call.
In cases of failure, the CS shall be capable of providing contingency routing based on the last routing
option that it receives.
For a SIP-based CS, the Record Route header should be specified to keep the server in the signaling
path of the call.
The CS shall keep call event records for trouble shooting purposes.
It is recommended that the CS shall save (subject to local regulations/restrictions), for trouble
shooting purposes, the following information, if available, associated with a call:
5.1.1
The call history;

The contents of the esrRequest message;
The contents of the esrResponse message;
The disposition of the call (e.g., ESGWRI or LRO used).
Authentication and Authorization
No incremental authentication and authorization requirements are specified for the VSP CS in this
document. However, authentication is advisable such that the CS can assert the subscriber name and
callback number to be supplied with the emergency call. Details on how a VSP can implement
authentication are out of scope of this document.
5.1.2
Performance
No normative performance requirements are specified in this document. Guidelines are provided in
Section 9.7.
5.1.3
Reliability and Availability
No incremental reliability and availability requirements are specified for the VSP CS in this
document.
Page 68 of 247

NENA 08-001 v2, August 11, 2010
5.2
Routing Proxy Server
This element is optionally present in the call path. If the signaling protocol is SIP, this element is a
proxy server as defined in RFC 3261 [5]. When deployed, the RP receives emergency calls (only,
i.e., dedicated to emergency services) forwarded from the VSP CS on the v6 interface. It maintains a
v2 interface to query the VPC for routing information/ESQK. The RP may be required to translate
an ERT to an ESGWRI, based on business arrangements between the Routing Proxy service
provider and VPC provider. The RP maintains routing data which maps an ESGWRI to the URI of
the appropriate ESGW. It uses this data to obtain the URI, and forward the call on the v4 interface,
with the ESGWRI, ESQK, PIDF-LO, subscriber name and callback number, to the ESGW.
For Routing Proxies using SIP, the Record Route header should be specified to keep the proxy in the
call signaling path.
In cases of failure, the Routing Proxy shall be capable of providing contingency routing based on the
LRO that it receives.
Routing Proxies shall keep call event records for troubleshooting purposes.
It is recommended that the Routing Proxy shall save (subject to local regulations/restrictions), for
troubleshooting purposes, the following information associated with a call:
5.2.1

The disposition of the call (e.g., ESGWRI or LRO used);
The Call History.
The RP should implement authentication mechanisms and may enforce authorization policies.
5.2.2
Performance
Section 9.7.
5.2.3
An RP dedicated to emergency services shall be highly reliable and available. It is an objective that
the RP be available to the CS at a service availability level of 99.999%.
5.3
Redirect Server
This element is optionally present. If the signaling protocol is SIP, this element is a proxy server as
defined in RFC 3261 [5]. When deployed, the RS receives emergency calls (only) forwarded from
the VSP CS on the v5 interface. It maintains a v2 interface. It queries the VPC for ERT/ESQK or
ESGWRI/ESQK by sending information, including location, callback number, and subscriber name,
on the v2 interface. It then unconditionally forwards the SIP 300 Message on the v5 interface, with
Page 69 of 247

NENA 08-001 v2, August 11, 2010
the ESQK, ERT/ESGWRI and the LRO back to the VSP CS. The VSP CS then routes the call, based
on the ESGWRI, to the correct ESGW over v4.
The RS shall support a mechanism to allow it to receive a call termination notification.
The RS shall support the capability to indicate to the VPC that a call has terminated.
It is recommended that the RS shall save (subject to local regulations/restrictions), for
troubleshooting purposes, the following information associated with a call:
5.3.1

The disposition of the call (e.g., ESGWRI or LRO used);
The Call History.
The RS should implement authentication mechanisms and may enforce authorization policies.
5.3.2
Performance
Section 9.7.
5.3.3
An RS dedicated to emergency services shall be highly reliable and available. It is an objective that
the RS be available to the CS at a service availability level of 99.999%.
5.4
Emergency Services Gateway (ESGW)
The ESGW takes VoIP delivered calls and converts them to circuit-switched signaling and media for
delivery into the E9-1-1 Selective Routing Network.
The ESGW implements the v4 interface. It accepts a call with an ESGWRI, ESQK, callback number
and, optionally subscriber name and uses the ESGWRI to select an outgoing trunk group to the E91-1 network. The ESGW maintains mapping data that associates the ESGWRI with the appropriate
outgoing trunk group. It is expected that the ESGW will implement dedicated 9-1-1 trunks to the SR.
The ESGW provider and the VSP are expected to negotiate the codecs that are to be supported.
These trunk groups or routes use traditional telephony signaling schemes to deliver the emergency
call over dedicated voice channels between the gateway and the E9-1-1 network. These trunks
originate at the ESGW and terminate at the SR, as designed to meet the needs and constraints of the
particular E9-1-1 network for the callers location.
In general, the trunking protocol, and the trunk design will be determined based on the capabilities
(and requirements) of the destination E9-1-1 network.
Likely candidates for these circuits are:
Page 70 of 247

NENA 08-001 v2, August 11, 2010
SS7 signaling, which can be used to signal either just the ESQK or both the ESQK and
callback number, depending on the way the trunks are provisioned at the ESGW.
- If only an ESQK is signaled to the SR, the IAM includes a Called Party Number (CdPN)
of 911, (or 11, or 1) and the ESQK in the Calling Party (CgPN) and/or Charge
Number parameter(s). The 10 digit ESQK is used to represent the call key.
If both the ESQK and the callback number are to be signaled to the SR, the IAM includes
a Called Party Number (CdPN) of 911 (or 11, or 1), the callback number in the
Calling Party (CgPN) and/or Charge Number parameter(s), and the ESQK in the Generic
Digits Parameter 7 (GDP). Note that if both the ESQK and callback number are expected
to be signaled over a particular trunk group, but the callback number is not available, the
ESGW is expected to generate a non-dialable callback number of the form 911 + the last
seven digits of the ESQK, and deliver the call to the SR with the non-dialable callback
number signaled as the Calling Party Number (CgPN) and/or Charge Number, and the
ESQK signaled in the Generic Digits Parameter (GDP).
Traditional CAMA signaling, which can be used to signal either just the ESQK or both the
ESQK and callback number, depending on trunk provisioning.
If only an ESQK is to be signaled to the SR, a called number of the form 911, 11, or
1 , and an ANI of the form I [single info digit] plus a 7-digit ESQK value, shall be
outpulsed, with both digit streams contained between the KP and ST pulses. Note that
since the ESGW will be receiving a 10-digit ESQK value, this assumes that the ESGW
will convert the received 10-digit ESQK value to a 7-digit ESQK value.
If both the ESQK and the callback number are to be signaled to the SR, the ESQK will be
outpulsed as the called number, and the ANI stream will consist of a single ANI I digit
plus the last 7 digits of the callback number 8.
These trunk groups may not be used to originate traffic back into the ESGW, but once the call is
established, provide for two way voice communication.
In general, the 9-1-1 service provider will have technical standards, or accessibility letters that define
the allowable signaling schemes to be used within their network. In many cases, the ESGW operator
may also need to negotiate with the individual Public Safety Operators within a given geographic
area before these circuits can be ordered to, or through the SR Operator.
Sizing of trunk groups between ESGWs and SRs is a subject for a future study. This is a complicated
issue because, unlike wireline call delivery where an end office serves a fixed population, the
population served by a VSP is expected to be variable. Further complicating this issue is the fact that
a VSP is probably connected to multiple ESGWs and ESGWs are expected to be connected to
multiple VSPs. This many-to-many relationship makes determination of VoIP 9-1-1 traffic loads at
ESGWs an issue that needs further study.
7 NENA 03-503 [32] also allows the ESQK to be signaled as the called number in some implementations.
8 Not all implementations support signaling of 20-digits over MF trunk groups.
Page 71 of 247

NENA 08-001 v2, August 11, 2010
5.4.1
The ESGW should implement authentication mechanisms and may enforce authorization policies.
5.4.2
Performance
Section 9.7.
5.4.3
An ESGW dedicated to emergency services shall be highly reliable and available. It is an objective
that the ESGW be available to the CS/RP at a service availability level of 99.999%.
5.5
ESZ Routing Database (ERDB)
This section provides the high-level functional requirements for the ERDB.
The ERDB has two main functions:
5.5.1
the ERDB is responsible for storing boundary definitions for each ESZ in its service area,
along with associated routing information;
the ERDB is responsible for delivery of routing information to the VPC.
Receiving and Storing Routing Information
The ERDB shall support storage of the boundary definitions for ESZs and the mapping of civic
address or geo-spatial coordinate location information to a particular ESZ. The ERDB shall be able
to identify the ESZ associated with any given civic address in its serving area, where the civic
address can be uniquely mapped to an MSAG-valid address. The ERDB shall be able to identify the
ESZ associated with any given pair of coordinates that are within its serving area.
The ERDB also stores attributes for each ESZ. For each ESZ, the ERDB shall be able to store the
following information needed for routing:
a Selective Routing Identifier associated with the primary SR that serves the ESZ in the i2
solution;
the routing ESN within that primary SR that is associated with the ESZ;
an NPA that is associated with the outgoing route to the Selective Router.
Some PSAPs use administrative ESNs, different from the routing ESN associated with the ESZ. This
administrative ESN is also used in the ALI DB to identify a particular set of Police, Fire, and
Medical English Language Translations. The ERDB shall also be able to store an administrative
ESN for an ESZ, if applicable.
CRNs are 10-digit 24x7 PSAP numbers that are used for routing emergency calls under network
failure conditions. A CRN must be associated with each SR/routing ESN combination.
Page 72 of 247

NENA 08-001 v2, August 11, 2010
As specified in Section 3.4, Selective Routing Identifiers are in the form of CLLI codes. ESNs shall
be defined as at least 5 digits in length (including leading zeros), in order to assure compatibility
with MSAG values.
NOTE: If the PSAP does not receive emergency calls via dedicated trunks and E9-1-1 facilities from
SRs, it may instead receive them via the PSTN using a 24x7 E.164 number. In that case, the ERDB
will store the PSAP E.164 number in the CRN attribute and there will not be other routing
information attributes populated for the ESZ (i.e., no Selective Routing Identifier, routing ESN,
NPA) associated with that callers location.
The ERDB is not aware of the trunk group arrangements at the ESGW. The arrangements may differ
between ESGW networks.
5.5.1.1 Data Management
The ERDB shall support a database structure that will allow for additional attributes to be easily
associated with an ESZ.
The ERDB database management system shall allow for multiple agents to simultaneously perform
database maintenance (data object creation, update, deletion) on the routing data.
The database structure shall be capable of supporting real-time queries.
5.5.1.2 Authentication and Authorization
The ERDB shall be able to authenticate the sources from which it receives source data for inclusion
in the ERDB. Based on the credentials of the source, the ERDB shall control the sources access to
view, enter, and modify information in the ERDB.
5.5.1.3 Data Integrity
The ERDB database management system shall enforce consistency of routing information whether a
given location is defined as a civic address or as geo-spatial coordinate information.
The ERDB shall provide for automatic as well as manually initiated audits of the integrity and
consistency of the routing data.
For ERDB data consistency requirements please refer to NENA 02-013[38].
5.5.2
Processing Routing Queries
The ERDB shall be able to receive either or both civic and geodetic location information in a routing
query.
Whenever the ERDB receives a routing query containing valid location information from an
authorized VPC, the ERDB shall attempt to map the location information to the applicable ESZ and
its associated routing information.
Page 73 of 247

NENA 08-001 v2, August 11, 2010
If both civic location and geodetic location information are included in a routing query, the ERDB
shall be configurable to support using either element or both, in a specified search order, in the
attempt to determine the routing information. The ERDB shall signify which one was used in the
response.
5.5.2.1 Authentication and Authorization of Routing Queries
The ERDB shall support the capability to authenticate the entities from which it is allowed to receive
routing queries.
Based on the credentials of the entity from which a routing query is received, the ERDB shall
support the capability to control the access of the entity to routing information in the ERDB.
5.5.2.2 Civic Location Information (Street Address) Received in Routing Query
The ERDB shall be able to receive the components of a civic address that are defined for the
Presence Information Data Format Location Object (PIDF-LO) defined in RFC-4119 [8][37]:
State/Province
County Name
MSAG Community Name
Postal Community Name
Postal/Zip Code
Prefix Directional
Street Name
Street Suffix
Post Directional
House Number
House Number Suffix (if applicable)
The ERDB shall be able to recognize an alphanumeric County Name. In the USA, the ERDB shall
also be able to recognize a numeric Federal Information Processing Standard 9 (FIPS) County ID in
the County Name. In the USA, the ERDB shall support the capability to convert a County Name to a
Federal Information Processing Standard (FIPS) County ID value for the county, if County ID is
used within the ERDB for determining routing in a given area.
The ERDB shall be able to recognize either Postal Addresses or MSAG Addresses, as defined in
Section 3.4, received in the civic address information. If a valid address (i.e., one that can be
uniquely mapped to an MSAG-valid address) is received, then the ERDB shall be able to use it to
determine routing information and to identify MSAG-valid formats.
If the civic location information contains a valid address within the ERDBs serving area, the ERDB
shall use this information to determine the ERT, the routing ESN, and the CRN associated with the
9 Federal Information Processing Standard (FIPS), PUB 6-4.
Page 74 of 247

NENA 08-001 v2, August 11, 2010
identified ESZ. If there is a separate administrative ESN associated with the ESZ, the ERDB shall
also be able to determine the administrative ESN.
In addition, for postal civic addresses, the ERDB shall be able to transform a valid postal civic
address to the MSAG-valid format for that address.
5.5.2.3 Geodetic Location Information Received in Routing Query
If the routing query contains geodetic location information (latitude and longitude) that identifies a
location within the serving area of the ERDB, the ERDB shall be able to determine the ERT, the
routing ESN and the CRN associated with the identified ESZ in response to the routing query. If
there is a separate administrative ESN associated with the ESZ, the ERDB shall also be able to
determine the administrative ESN.
The geodetic location information must be in the form of decimal degrees, using the WGS84
coordinate system.
5.5.2.4 Responding to Routing Queries
If the ERDB is able to successfully use the received location information to determine the routing
information, the ERDB shall follow the requirements in Section 6.10 to send a response to the VPC,
including the following routing information:
An ERT comprising:
- A Selective Routing Identifier, if available.
- A routing ESN, if available.
- An NPA, if available.
A CRN, if available.
An Administrative ESN, if applicable.
An indication of whether civic or geo location information was used to determine routing (if
both civic and geo location information were received).
NOTE: If the PSAP does not support dedicated trunks and E9-1-1 facilities, emergency calls will be
routed to the PSAP via the PSTN, using a 24x7 E.164 number. In that case, the ERDB response will
indicate success, but the only routing information provided will be the CRN (i.e., ERT will not be in
the response).
If civic location information was received in the routing query, the ERDB shall also include the
transformed address information in its response to the VPC. The MSAG-valid address includes the
following data elements, as applicable:
State/MSAG Community Name

Prefix Directional (if applicable)
Street Name
Street Suffix (if applicable)
Post Directional (if applicable)
Page 75 of 247

NENA 08-001 v2, August 11, 2010
House Number
House Number Suffix (if applicable)
5.5.2.5 Steering of Routing Queries

If the ERDB receives a routing query from a VPC, and the received location information is not
within the ERDBs serving coverage area, the ERDB may support one of the following:
The ERDB may steer the routing query to the appropriate ERDB and then pass the received
response from that remote ERDB toward the requesting VPC.
NOTE: The steering procedures are incomplete at this time. Further work will be required to fully
define steering procedures. This may be a topic for a future issue of this Standard.
5.5.2.6 Error Handling
If the ERDB receives civic or geodetic location information that identifies a location within its
serving area for which it cannot determine any routing information, the ERDB shall return a
response to the VPC indicating that routing information is not available, also including the reason for
the failure.
If the ERDB receives civic or geodetic location information that identifies a location which is not
within its serving area and it cannot determine the ERDB to which the civic or geodetic location
information should be steered, the ERDB shall return an error response to the VPC indicating that
routing information is not available and indicating the reason for failure.
If the ERDB receives an error message in response to a routing query steered to another remote
ERDB, the ERDB shall pass the received error response received from the remote ERDB to the
VPC, including the reason for failure.
5.5.2.7 Default Routing
Default Routing may be invoked when a received civic address does not resolve to a single MSAG
address. For example, the location received matches at the state level but not at the municipality
level.
ERDB providers are encouraged to provide the default routing options described in this section. If
any default routing is to be provided, it is critical that the 9-1-1 Authorities work with the ERDB
provider to determine which of the default routing options described here should be offered for their
area. The 9-1-1 Authority must also work with the ERDB provider to build, approve and maintain
routing data. The ERDB shall not provide any default routing without the 9-1-1 Authoritys explicit
approval.
The 9-1-1 Authority can designate any ESN as a default ESN. Because there is currently no explicit
way for the VPC to communicate to the ALI system that a call has been default routed, it is
preferable that the 9-1-1 Authority specify distinct ESNs to be used as defaults so that the ESN itself
Page 76 of 247

NENA 08-001 v2, August 11, 2010
alerts the PSAP that a call has been default routed 10. These ESNs could be new ones designated for
the purpose, they could be the reused ESNs which were previously assigned by some PSAPs for prei2 (one per PSAP) use, or they could be the same ESN associated with wireless default routing. As
with all ESNs in the ERDB, the default ESNs must be associated with a specific ERT.
This section describes two types of default routing. The 9-1-1 Authority must decide which types of
default routing they would like provided. If they decide that they wish to use both types of default
routes, they must determine the order in which they are applied for invalid addresses. The two types
of default routing are:
Default Geodetic Routing. This type of routing has the potential to closely match how a call
would be routed if the location was MSAG valid. In order for this type of default routing to
be done all of these conditions must be met:
o The ERDB must have street-level GIS information (either commercial 11, or provided
by the 9-1-1 Authority).
o The ERDB must maintain correct ESN polygon boundaries (which are ideally
provided by the 9-1-1 Authority).
o The address presented must be successfully geo-coded (i.e. when looking up the
submitted address in the street-level information, a successful result is returned).
Geo-coding is not a required function of the ERDB.
Default Tabular Routing. This type of routing is less likely to match how a call would be
routed if the location was MSAG valid. It requires that the 9-1-1 Authority determine ESNs
for default routes at the Postal Zone, Community, County and State level.
When default route ESNs are used, the MSAG-valid civic address parameter returned by the ERDB
should have the address fields set to Verify in any fields not determined to be accurate. The VPC
should set the Class of Service to V (especially in the case of reuse of the wireless default ESNs)
in the data returned by the VPC over the v-E2 interface.
If the 9-1-1 Authority does not make any choices in regards to handling invalid addresses, the ERDB
shall return a 400 Result Code (ErrorBadLocation) to the VPC. The VPC will then be responsible
for determining how to handle the call.
5.5.2.7.1 Default Geodetic Routing Requirements
The ERDB may provide the ability to default route based on a geo-coded civic location. If a nonMSAG valid civic location is presented and that location can be successfully geo-coded, the ERDB
may use the same routing methodology used for calls where lat/long is the only information
provided in the erdbRequest message. The ERDB should include the geocoded location in the
erdbResponse message. The 9-1-1 Authority should approve the GIS data used for geo-coding.
10 Some PSAP representatives have suggested that using pre-i2 VoIP ESNs as the default routes would help the call-taker identify
which VoIP calls were default routed using this mechanism.

11 Commercial databases should not be used without the express approval of the 9-1-1 Authority.
Page 77 of 247

NENA 08-001 v2, August 11, 2010
If a civic location cant be geo-coded and the 9-1-1 Authority specifies that Tabular Default Routing
should not be used, the ERDB will not attempt to determine a default route and return a 400 Result
Code (ErrorBadLocation).
If a geo-route can be determined, the following return code will be returned to the VPC:
210 = Default Route based on Geodetic match of complete civic location.
5.5.2.7.2 Tabular Routing Requirements
The ERDB shall have the ability to maintain default routing ERTs and ESNs for Postal Zone,
Community, County and State. The ERDB operator will coordinate with the 9-1-1 Authority to
build these default routes. If default routes are not built for certain areas, the ERDB shall return
Result Code 400 (ErrorBadLocation) to the VPC.
If the 9-1-1 Authority has chosen to tabular default route, the ERDB will match postal zone,
community, county and state from the civic location to default table entries for postal zone,
community, county, and state. The following table describes how the data elements from the civic
location are used to determine the default route.
Table 5-1 Tabular Routing using Civic Elements
Civic Location Data Elements
Postal
Zone
Postal
Community
County
State
Found 12
found
found 13
found
Found
not found
found
found
Found
Found
not found
not found
not found
not found
found
found
not
found
found
found
found
not
found
found
or empty
not
not found
found or
Tabular Routing Record

Used for Routing
Return
Code
Postal Zone + City +

County + State
Postal Zone + County +
State
Postal Zone + State
Return Error
211
213
400
City + County + State
214
County + State
215
212
12 Data specified as found means that an entry has been found in the Tabular Routing tables that matches the value from the Civic
Location.
13 If county is not supplied as part of the Civic Location it should be looked up using Postal Zone (if supplied) or Postal Community
and State.
Page 78 of 247

NENA 08-001 v2, August 11, 2010
Civic Location Data Elements

Postal
Zone
empty
not
found or
empty
not
found or
empty
Postal
Community
County
State
Tabular Routing Record

Used for Routing
Return
Code
not found
not found
found
State
216
not found
not found
not
found
Return Error
400
5.5.2.7.3 Example Tabular Default Routing Records

The following table presents a few example entries of tabular default routing records.
Table 5-2 Tabular Default Routing Records
Postal Zone
76148
76148
76148
76148
76148
City
County
Fort Worth
Haltom City
Watauga
Tarrant
Tarrant
Tarrant
Tarrant
Fort Worth
Tarrant
Tarrant
Denton
Denton
State
TX
TX
TX
TX
TX
TX
TX
TX
TX
ESN
00002
00003
00004
00001
00099
00007
00001
00900
00101
Note there are no zip codes that cross counties in the USPS data
5.5.2.7.4 Example Addresses and Routing Decisions

Table 5-3 Example Addresses and Routing Decisions
Civic Location
Routed On
Return
Code
ESN
333 Bad Street

Watauga, TX 76148
333 Bad Street
Keller, TX 76148
333 Bad Street
Bad City, TX 76148
333 Bad Street
Postal Zone, City, County and

State
211
00004
Postal Zone, County and State
212
00001
Postal Zone and State
213
00099
City, County and State
214
00101
Page 79 of 247

NENA 08-001 v2, August 11, 2010
Denton, TX 76148
333 Bad Street
Ardmore, OK 76148
333 Bad Street
Fort Worth, TX
333 Bad Street
Keller, TX
333 Bad Street
Austin, TX
400
City, County and State
214
00007
County and State
215
00001
State
216
00900
The following table illustrates all of the ways that the ERDB can determine routing based on the data
submitted in the erdbRequest:
Table 5-4 ERDB Routing
Data in Request
Data in Response
ERDB Processing
MSAG
found
GeoCode
found
Routing
Method
Civic
Geo
n/a
MSAG
Default Geo
Default Tabular
Y
Y
N
N
Y
Y
Y
N
Y
N
n/a
n/a
n/a
n/a
n/a
n/a
MSAG
Geo
Geo
Error Returned
Result
Code
201
210
211, 212,
213, 214,
215, 216*
201
200
200
401
MSAG
GeoCoded
Location
Y
N
N
N
N
N
N
N
Note: The order of items in this table does not imply that the ERDB will always attempt to geo-route
before attempting to tabular-route. The 9-1-1 Authority may choose to do tabular routing instead of
(or before) Geo-routing when a Civic Address that is not MSAG-valid is presented.
* Note an address may also be determined to be not in the serving area in which case the ERDB
will return 562.
Page 80 of 247

NENA 08-001 v2, August 11, 2010
5.5.3

The ERDB shall be able to authenticate the sources from which it receives source data for inclusion
in the ERDB. Based on the credentials of the source, the ERDB shall control the sources access to
view, enter, and modify information in the ERDB.
5.5.3.2 Routing Queries
The ERDB shall support the capability to authenticate the entities from which it is allowed to receive
routing queries. Based on the credentials of the entity from which a routing query is received, the
ERDB shall support the capability to control the access of the entity to routing information in the
ERDB.
5.5.4
Performance
Section 9.7.
5.5.5
The ERDB shall be available to support routing queries with a reliability of 99.999%.
5.6
VoIP Position Center (VPC)
This section provides the high-level functional requirements for the VPC. The main functions of the
VPC are to:
5.6.1
Support the routing of emergency calls originated by VoIP customers to the appropriate
PSAP by providing critical routing information to the Call Server/Proxy;
Deliver caller location, callback number, and subscriber name information in response to
queries from ALI databases.
Support for Emergency Call Routing
There are a number of capabilities required of the VPC to support its role in providing routing
information to the Call Server/Proxy to support the routing of VoIP emergency calls. The VPC must
be able to process routing requests from a Call Server/Proxy, and if necessary, interact with a LIS to
obtain the callers location information. The VPC must use the location information, obtained from
the routing request or from the LIS, to generate a routing query to an ERDB to obtain routing
information associated with the callers location information. The VPC must then use this
information to generate a response to the Call Server/Proxys routing request. In addition, the VPC
will have to support contingency/default routing under certain failure scenarios. The following
subsections describe the functionality required of the VPC to support each of these aspects of VoIP
emergency call routing.
Page 81 of 247

NENA 08-001 v2, August 11, 2010
5.6.1.1 Processing of Routing Requests from the Call Server/Proxy
The VPC shall be capable of receiving and processing a routing request from a Call Server/Proxy,
over a v2 interface that contains the following information:
Identification of the entity that is requesting emergency call routing, including a 24x7
number/address that can be used to reach that entity and the host ID associated with that
entity;
An identifier that can be used to uniquely identify the call/transaction at the Call
Server/Proxy;
An E.164 callback number that can be used by the PSAP to reach the call originator, if
available;
Customer Name information, if available;
A Location Information Element (LIE) containing either a PIDF-LO or a Location Key to
support interactions with an LIS to obtain the PIDF-LO.
An identifier for the callers Voice Service Provider, if available
In addition, the VPC shall be capable of processing the following optional information in a routing
request from a Call Server/Proxy:
A Date Time Stamp indicating the UTC date and time the message was sent;
An identifier for the destination VPC;
An identifier inserted by the originating network that may be used by a LIS to validate that
the received Location Key belongs to the originating network.
The VPC shall support the capability to authenticate the entities from which it is allowed to receive
routing requests.
Based on the credentials of the entity from which a routing request is received, the VPC shall
support the capability to control the access of the entity to routing information accessible by the
VPC.
5.6.1.2 Generation of Queries to LIS to Obtain Location Information
If the VPC does not receive a PIDF-LO in the LIE of the routing request from the Call Server/Proxy,
the VPC may query an LIS for caller location information, based on agreements between the VPC
provider, the LIS provider, and the VSP.
The details of the v3 interface used by the VPC to query a LIS for location information will be
specified in a future issue of this specification.
5.6.1.3 Generation of Routing Queries to the ERDB
Once the VPC receives an LIE containing caller location information, the VPC shall query an ERDB
to obtain routing data for the call. The VPC shall identify the appropriate ERDB to which to direct
the routing query by accessing discovery data that identifies the URL of the ERDB(s) that serves the
emergency callers location. If the VPC has received caller location information consisting of a
Page 82 of 247

NENA 08-001 v2, August 11, 2010
PIDF-LO document that contains more than one tuple 14, where each tuple contains a status element
with a geopriv location element, the VPC shall select the first tuple (i.e., the tuple containing the
highest priority location) as the basis for ERDB discovery. The VPC shall select the first piece of
information in the first tuple as the basis for discovering the ERDB. (See Section 3.9 for a detailed
description of the ERDB discovery mechanism).
Having identified the ERDB to which to direct the routing query, the VPC shall formulate a query
that contains the following information:
A Message ID that will identify the message and allow for correlation of the query and the
response;
The identifier of the node requesting the routing information (e.g., the VPC);
A civic location, a geodetic location, or both a civic location and a geo location.
Note that the VPC shall use the first location-info element to populate the routing query. If the
location information contains a geodetic location, and the coordinate system associated with that geo
location is something other than WGS84, the VPC shall convert the geodetic location to WGS84
[35] prior to sending it to the ERDB in the routing query.
In addition to the information identified above, the VPC may also include the following information
in the routing query to the ERDB:
A Date Time Stamp indicating the UTC date and time that the message was sent;
Identification of the ERDB from which routing information is being requested.
5.6.1.4 Processing of Routing Responses from the ERDB

The VPC shall be capable of processing a routing response from the ERDB that contains the
following information:
A Message ID that allows for correlation of the query and the response;
The identity of the node directly responding to routing query sent by the VPC;
An ERT comprised of:
o The Selective Routing Identifier associated with the callers location;
o The routing ESN associated with the callers location;
o The NPA that is associated with the outgoing route to the Selective Router appropriate
for the callers location;
The administrative ESN associated with the callers location (if present in the routing data at
the ERDB);
The CRN that identifies the 24x7 E.164 number of the alternate PSAP to which emergency
calls should be routed under various abnormal conditions, if present in the routing data at the
ERDB. (See Section 3.7 for further discussion of contingency/default routing procedures);
14 Please refer to [18] for recommended methods to construct a routable PIDF-LO document.
Page 83 of 247

NENA 08-001 v2, August 11, 2010
An indication of whether the ERDB was successful in providing routing information or the
ERDB invoked default routing, and the basis on which the routing information was
determined (i.e., a civic location or a geodetic location);
The MSAG-valid format of the civic address provided by the VPC in the routing query
The geo-coded location used in default routing (if geodetic default routing was applied at the
ERDB);
A VPC Identifier that identifies the VPC that initiated the query;
A Date Time Stamp that indicates the UTC date and time that the message was sent;
An identification of the ERDB that was the original source of the routing information (which
may or may not be the same as the ERDB that is directly connected to the querying VPC).
Upon receiving the response message from the ERDB, the VPC shall use the Selective Routing
Identifier, routing ESN, and NPA contained in the response message to identify the appropriate pool
of ESQKs for the call. From this pool of ESQKs, the VPC shall select an available ESQK value to
associate with the call. The VPC shall also set a guard timer once the ESQK has been associated
with the call. The recommended value for the guard timer is 8 hours in duration but can be settable
to an appropriate value based on statistical data by the VPC operator. The length of the guard timer
will affect the size of the ESQK pool. The VPC shall maintain an association between the ESQK and
the other call-related information (e.g., callback number, subscriber name, location, Provider
information) until it either receives an indication from the Call Server/Proxy that the call has
terminated or the guard timer expires (whichever occurs first), at which point the ESQK value will
be released.
The VPC shall hold one ESQK value within each pool in reserve to be used when there are no other
ESQK values within the pool available for association with an emergency call request. The VPC
shall associate this reserved (i.e., default) value with all new emergency call requests that require an
ESQK from a particular pool until such time as another ESQK value within that pool becomes
available. When a default ESQK is allocated to multiple simultaneous calls, the VPC will not be able
to provide call-related information to the ALI system.
As described in Section 3.3.9, the VPC may, optionally, be responsible for translating the Selective
Routing Identifier, routing ESN and NPA (which make up the ERT) received from the ERDB to an
ESGWRI. To support the ESGWRI translation function, the VPC will need to establish a
relationship with the ESGW operators whose systems interconnect with VPC customer systems (i.e.,
Call Server/Proxies). (See Section 7 for further discussion of Roles and Responsibilities). For each
ESGW, the VPC shall store mappings between Selective Routing Identifiers/NPAs/routing ESNs
and ESGWRI values. The VPC will have to have some knowledge about the routing logic supported
by each Call Server/Proxy it serves so that it will know which ESGWRI (i.e., associated with which
ESGW) it should return. Implicit in this arrangement, is the need for each ESGWs ESGWRI values
to be unique. Otherwise, upon receiving the ESGWRI from the VPC, the Call Server/Proxy will not
know to which ESGW the call should be routed (if the Call Server/Proxy interconnects with multiple
ESGW operators systems).
Page 84 of 247

NENA 08-001 v2, August 11, 2010
routed to the PSAP via the PSTN, using a 24x7 E.164 number. In that case, the ERDB response will
indicate success, but the only routing information provided will be the CRN (i.e., Selective Routing
Identifier, routing ESN, NPA will not be in the response).
5.6.1.5 Generation of Responses to Routing Requests from a Call Server/Proxy
Once the VPC has received the routing data from the ERDB, determined the ESQK value for the call
and optionally performed the ERT-to-ESGWRI translation, it shall prepare a response to the routing
request it received. Under normal conditions, this response message shall contain the following
information:
The identifier of the responding VPC;

An identifier that uniquely identifies the call at the Call Server/Proxy;
The ESQK allocated by the VPC to the call;
The CRN received in the ERDB response to be populated in the LRO parameter;
An indication of whether or not the VPC was successful in providing the requested routing
information, and the basis for determining the routing information (i.e., routing information
based on civic or geodetic information, obtained from the routing request or via a query to
the LIS);
If the VPC is responsible for performing ERT-to-ESGWRI translation, the routing response
returned to the Call Server/Proxy shall also contain the ESGWRI;
If the VPC is not responsible for performing the ERT-to-ESGWRI translation, the routing
response returned to the Call Server/Proxy shall also contain an ERT containing the Selective
Routing Identifier, routing ESN, and NPA received in the ERDB response.
In addition, the VPC may also include the following optional information in the routing response to
the Call Server/Proxy:
A Date Time Stamp indicating the UTC date and time that the message was sent;
The identifier of the entity that requested emergency call routing.
routed to the PSAP via the PSTN, using a 24x7 E.164 number. In that case, the VPC response will
indicate success, but the only routing information provided will be the CRN (i.e., ESQK,
ERT/ESGWRI will not be in the response).
5.6.1.6 Release of ESQKs
To minimize the risk of running out of ESQKs, the i2 Solution calls for a disconnect indication to be
sent to the VPC when a call is released, to enable the VPC to release ESQKs that are no longer in
use. This is accomplished by having the Call Server/Proxy send a call termination message to the
VPC at the conclusion of an emergency call. The VPC shall be capable of receiving a call
termination message that contains the following information:
Identification of the routing node directly adjacent to the VPC;
Page 85 of 247

NENA 08-001 v2, August 11, 2010
An identifier that uniquely identifies the call at the Call Server;

The ESQK that was allocated by the VPC for the emergency call (i.e., the ESQK value that
can now be returned to the ESQK pool at the VPC);
The identifier of the ESGW that was used to direct the call to the Selective Router, if
available.
In addition, the VPC shall be capable of receiving and processing the following information, if
provided in the call termination message from the Call Server/Proxy:
A Date Time Stamp indicating the UTC date and time the message was sent;
The identifier of the VPC.
Upon receiving a call termination message, the VPC shall return the ESQK value identified in the
message to the pool of available ESQKs, and shall respond by sending a call termination
acknowledgment message that contains the identifier of the VPC and an identifier that uniquely
identifies the call at the routing element that sent the termination message. The VPC may also
include a Date Time Stamp in the acknowledgement message, indicating the UTC date and time the
message was sent.
5.6.1.7 Support for Contingency/Default Routing
There are a number of errors or abnormal conditions (e.g., failures) that may occur in the process of
routing emergency calls originated by VoIP users to the appropriate Selective Router in the
Emergency Service Providers network. This section describes abnormal conditions that might be
detected by the VPC, and describes the actions that should be taken by the VPC under these
conditions.
One type of error that may be detected at the VPC involves problems with the structure or content of
the routing request sent to the VPC by the Call Server/Proxy, or queries from the VPC to the ERDB
or LIS. These error scenarios include the following:
The VPC receives a badly structured routing request from the Call Server/Proxy (i.e., the
request message cannot be parsed or is malformed);
The routing request from the Call Server/Proxy contains neither a Location Key nor a PIDFLO;
The VPC receives a PIDF-LO in the routing request from the Call Server/Proxy, but it cannot
determine, based on the received location, which ERDB to query for the routing data;
The VPC receives a PIDF-LO in the routing request from the Call Server/Proxy, but when it
uses it to query the ERDB for routing data, it receives either an error response or no response
from the ERDB;
The VPC receives a Location Key in the routing request from the Call Server/ Proxy, but it
cannot determine where to send the location query (i.e., it cannot determine the appropriate
LIS);
Page 86 of 247

NENA 08-001 v2, August 11, 2010
The VPC receives a Location Key in the routing request from the Call Server/ Proxy, and is
unable to successfully retrieve a PIDF-LO from the LIS (i.e., it receives an error response or
no response from the LIS).
In all of these scenarios, the VPC is unable to successfully obtain routing data from the ERDB and
provide it in a response to the Call Server/Proxy.
If the VPC is unable to successfully obtain routing data from the ERDB and provide it in a response
to the Call Server/Proxy, the VPC shall send a response message to the Call Server/ Proxy that
indicates the nature of the error that occurred. The message may also include a default routing
number (i.e., a 24x7 number associated with a call center), as determined based on prior agreements
between the VPC provider, the VoIP Service Provider, and the call center to which calls are to be
default-routed. (The default routing number will be populated in the Last Routing Option parameter
of the response message).
If a VPC is responsible for performing the ERT-to-ESGWRI translation, but it is unable to
successfully perform this translation for a specific ERT provided by the ERDB, the VPC shall send a
response message to the Call Server/Proxy that provides default routing information (consisting of a
CRN, if one was returned by the ERDB) in an LRO. It is not recommended that the ESQK be
included in the response to the Call Server since the VPC could not determine an ESGWRI.
Another type of abnormal condition that might be encountered at the VPC is related to a lack of
resources at the VPC. As described previously, one of the roles of the VPC is assigning an ESQK to
an emergency call from the appropriate ESQK pool that is associated with the Selective Routing
Identifier/routing ESN/NPA received from the ERDB. It is possible, in certain situations, for the
VPC to successfully receive routing data from the ERDB, but have no ESQKs available from the
applicable pool (other than a default ESQK) to associate with the specific call instance. The ESQK
exhaust could be caused by an unusually large number of calls being originated from a particular
geographic area, or due to some error in the allocation of the ESQK pool or in the de-allocation
process. If the VPC successfully receives routing data from the ERDB, but does not have an ESQK
available from the pool associated with the Selective Routing Identifier/routing ESN/NPA provided
in the ERDB response, the VPC shall return a routing response message to the Call Server/Proxy
that contains the reserved (i.e., default) ESQK value for the pool, along with either the ESGWRI (if
the VPC performed the ERT-to-ESGWRI translation) or the Selective Routing Identifier, routing
ESN and NPA (if the VPC did not perform the ERT-to-ESGWRI), and the CRN provided in the
response from the ERDB. (The CRN will be populated in the Last Routing Option parameter of the
response message).
A potential error scenario that could be encountered at the VPC related to the release of ESQKs is
the receipt of a call termination message containing an ESQK value that is not in use. If such an
error occurs, it is desirable that the VPC log the error and make a maintenance count.
5.6.2
Delivery of Location Information
As described above, the VPC will play an important role in delivering call and location-related
information for VoIP emergency calls to the ALI database for subsequent delivery to the PSAP to
Page 87 of 247

NENA 08-001 v2, August 11, 2010
which the emergency call was routed. This will require the VPC to be capable of processing location
information requests from an authenticated, authorized ALI database, and providing the call and
location-related information associated with an identified call instance in response.
The VPC shall store call and location-related information about an emergency call at least until this
information is delivered to the ALI database. In particular, the VPC shall store the location
information provided to the ERDB in a routing query, and MSAG valid civic address information if
included in an ERDB response. If the VPC receives an indication from the ERDB that default
routing was applied, the VPC shall store the default location information (i.e., civic or geo-coded
location) received from the ERDB and return it to the PSAP when queried over the v-E2 interface.
For purposes of tracking and troubleshooting, it is desirable that the VPC retain archival storage for
call and location-related data after an emergency call is released, for a configurable period of time, to
be negotiated with the PSAPs served by the VPC. The VPC should retain, for example, a record of
the callback information, subscriber name, the allocated ESQK and the date/time it was allocated (to
support searching for information related to a particular call instance), location information used for
determining routing, VSP identification and ESGW identification information, the routing
information received from the ERDB and used for routing the call, and identification of the ERDB
that provided the routing information.
To assist PSAPs in troubleshooting, the VPC shall support a user interface that will allow an
authorized agent of the VPC operator to search for and view call and location-related data for any
call instance associated with a given ESQK in a given time interval.
5.6.2.1 Processing Location Queries
The VPC may receive location queries from one or more ALI databases. The VPC must be able to
identify and authenticate the entities from which it receives these queries to ensure that information
is only provided to those entities that are entitled to receive it. Therefore, when the VPC receives a
properly constructed Emergency Services Positioning Request (ESPOSREQ) message (as described
in Section 6.11) from an ALI DB, the VPC shall first determine whether the requesting entity is
authorized to access emergency call and location-related data. If the requesting entity is authorized,
the VPC shall use the ESQK contained in the Emergency Services Routing Key parameter of the
ESPOSREQ message to identify the call instance, and to look up the associated call and locationrelated information stored at the VPC.
5.6.2.2 Generating Responses to Location Queries
5.6.2.2.1 Successful Responses
If the VPC can successfully obtain the call and location-related data associated with the call instance
identified by the ESQK in the ESPOSREQ message, the VPC shall construct an Emergency Services
Positioning Request Response (esposreq) message and send it to the ALI database identified by the
ESMEIdentification parameter in the received ESPOSREQ message. The esposreq message shall
contain the following key pieces of information:
Page 88 of 247

NENA 08-001 v2, August 11, 2010
The ESMEIdentification coded with the identification of the ALI Database that initiated the
query.
A PositionResult.
One or both of:
- Position information consisting of latitude and longitude as WSG84 information, and
altitude in meters, if available. If present, a Position Source will also be provided to
identify the method used to determine the location information.
- A Location Description (consisting of detailed street address information), if the location
information associated with the call instance is populated with a civic location.
A Callback Number, if available in the information associated with the call instance.
A subscriber name (populated in the Location Description), if available in the information
associated with the call instance.
An Emergency Services Routing Key, populated with the ESQK received in the ESPOSREQ.
An ESQK Date and Time Stamp.
A CompanyID, if the data associated with the call instance includes the NENA ID for the
VSP. If the NENA ID for the VSP is not available then the NENA ID of the entity at the
other end of the v2 interface is provided.
See Section 6.11 for further details related to the coding of the esposreq message.
The VPC shall include at most one civic and one geodetic location in the esposreq message. If the
VPC receives civic or geo-coded location information in the response from the ERDB, this
information will take precedence over civic or geo-location information included by the VPC in the
erdbRequest message. Specifically, if the VPC receives an msagvalidciviclocation parameter in the
erdbResponse message, it will use the msagvalidcivicaddress to populate the civic location
information in the esposreq message. If the VPC receives geo-coded location information in the
erdbResponse message, it will use the geo-coded location information to populate the position
information in the esposreq message along with the invalid civic address information. Otherwise,
the VPC will populate the civic and/or position information in the esposreq with the location
information included by the VPC in the erdbRequest message.
5.6.2.2.2 Error Responses
The VPC may be unable to provide location information in response to a request from the ALI
database due to the following conditions:
The VPC experiences a system failure resulting in the inability to look up the information;
The requesting entity is not authorized to access location data for emergency calls;
Unexpected data is received in the location request;
The ESQK identified in the request does not have any stored data associated with it;
A default ESQK was allocated to multiple call instances.
Page 89 of 247

NENA 08-001 v2, August 11, 2010
If one of the above conditions occurs, the VPC shall report the error condition to the requesting ALI
database by returning an Emergency Positioning Request Return Error message with the appropriate
Error Code value. See Section 6.11 for further details related to the coding of this message.
If the VPC is receives a badly constructed query from an authenticated entity, the VPC shall report
the problem by returning an Emergency Positioning Response Reject message containing the
appropriate Problem Code. See Section 6.11 for further details related to the coding of this message.
5.6.3
The VPC shall authenticate the entities from which it receives queries to ensure that information is
only provided to those entities that are entitled to receive it.
The VPC may implement authorization policies to ensure that requesters only receive what they are
entitled to.
5.6.4
Performance
Section 9.7.
5.6.5
The VPC application shall be highly reliable and available. It is an objective that the VPC be
available to a querying element (e.g., Call Server/Proxy, ALI Database) at a service availability level
of 99.999%.
5.7
Validation Data Base (VDB)
This section provides the high-level functional requirements for the VDB. The main functions of the
VDB are to:
Store MSAG validation data (MSAG valid civic addresses) for a given area it is expected
that there will be multiple VDBs supported by the various entities and each contains a
mechanism to validate data to conform to the MSAG for the given jurisdiction.
Perform MSAG Validation of a Civic Address request.
The legally designated 9-1-1 authority for the jurisdiction may provide this service, or it may be
delegated to an authorized entity.
5.7.1
Storage of MSAG Validation
The VDB shall support civic address information as defined by local MSAG(s) for a given region.
All modification requests to data stored on the VDB shall be logged.
Page 90 of 247

NENA 08-001 v2, August 11, 2010
The VDB database management shall allow for multiple agents to simultaneously perform database
maintenance (data object creation, update, deletion).
The VDB shall support uploads of MSAG data from authorized sources.
The database structure shall be capable of supporting 24x7 real-time queries keyed to various
elements of a civic address.
5.7.1.2 Data Management Authentication and Authorization
The VDB shall be able to authenticate the entities from which it receives source data for inclusion in
the VDB.
Based on the credentials of the entity, the VDB shall control the entitys access to view, enter, and
modify information in the VDB.
5.7.1.3 Data Integrity
The VDB database management shall enforce consistency of civic address information to MSAG
format. (NOTE: This is even more critical since a postal address will be presented and it should be
known at this time if the address can be formatted into a MSAG address since the ERDB will need
to do this conversion when the call arrives at the VPC).
The VDB shall maintain an audit trail of changes in the database.
5.7.2
Perform Validation
The validation interface is described in Section 6.11.

The VDB shall be able to process and respond to validation request messages.
The request shall use a standard message format that can be sent to any VDB (e.g. an XML message
with the same elements) for any jurisdiction/region.
The elements/fields of the message shall align with NENA 02-010 [11] data requirements, i.e. use
already supported attribute names, when applicable.
Error responses shall be provided when validation fails.
Error responses may contain suggestions for alternative addresses. The request could contain either
postal or jurisdictional addresses but the response will return a postal address and may return a
jurisdictional address.
Error responses shall provide information that enables a requestor to determine the type of error that
occurred.
As a VDB option, the VDB may geo-code the validated address and return it in the response. The
data needed to perform the geocoding must be approved by a public safety authority.
Page 91 of 247

NENA 08-001 v2, August 11, 2010
The VDB must be able to accept postal addresses and be able to return jurisdictionally accurate
address information (including the correct community name and county for the 9-1-1 jurisdiction).
The VDB must be able to accept a civic address (including the correct community name for the 9-11 jurisdiction) and be able to validate it. The VDB may also include postal address information
(postal community and postal code) in the response. The VDB may support the option to include
geodetic location information (latitude and longitude in WGS84 [35] format) in the response to the
location validation query.
The VDB shall provide a web services interface for civic address validation.
The VDB shall validate civic addresses submitted in the validation request message against both the
MSAG and, optionally, the country-specific Postal Service dataset 15. If an address resolves to one
and only one MSAG entry, the address is considered to be valid. If the address resolves to zero
MSAG entries or more than one MSAG entry, the address is considered to be invalid.
The VDB shall maintain translations from Postal Community Name to MSAG Community Name
and vice-versa.
The VDB may maintain translations from Postal County Name to MSAG County ID.
The VDB shall maintain translations from the country-specific Postal Service abbreviations to
MSAG abbreviations and vice-versa. MSAG abbreviations may differ among communities and
counties.
The VDB shall ignore variations in upper and lower case to perform address searches (i.e. perform
case-insensitive searches).
The VDB shall strip punctuation and translate non-standard abbreviations into standard countryspecific Postal Service abbreviations before performing any database search (see Section 9.2 Rules
for Address Abbreviation).
The VDB may use a database or service based on postal service data to determine whether an
address is a valid postal address. The postal service search may provide other helpful information to
assist in the MSAG address validation (such as County Name).
The VDB may accept and parse into the appropriate fields malformed data such as HouseNum and
StreetName entered into the same field or directionals embedded in the StreetName field before
validating the submitted Address. The response will be a well-formed address (or addresses).
The VDB shall always return pre/post directional and suffixes in the appropriate fields in the
validateResponse message.
The VDB shall implement the v7 interface documented in Section 6.8.
15 All translations and searches done by the VDB to determine if an address is MSAG-valid must also be done by the ERDB when a
call is being routed. This means that all data managed by the VDB must also reside in the ERDB and that any translations or data
conversions done by the VDB must also be done by the ERDB.
Page 92 of 247

NENA 08-001 v2, August 11, 2010
If a submitted address cannot be automatically validated by the VDB, the VDB operator shall
research these addresses and either create or update the appropriate Postal to MSAG translations.
The VDB operator shall provide an email address (e.g., discrepancy@VDBdomain.com) that the LIS
operator could use to send the unvalidated address to the VDB provider for further research. If the
address still cannot be validated, the VDB shall return a more detailed explanation of why the
address is invalid. Note: Resolution of discrepancies may require coordination with the appropriate
ERDB providers and/or MSAG Operators.
5.7.2.1 Authentication and Authorization of Validation Queries
The VDB may authenticate the entities from which it is allowed to receive validation queries.
5.7.3

The VDB shall be able to authenticate the entities from which it receives source data for inclusion in
the VDB.
Based on the credentials of the entity, the VDB shall control the entitys access to view, enter, and
modify information in the VDB.
5.7.3.2 Validation Queries
The VDB may authenticate the entities from which it is allowed to receive validation queries.
Based on the credentials of the entity from which a query is received, the VDB may restrict the
ability of the entity to some validation queries e.g., it may be able to validate locations in some
regions but not others.
5.7.4
Performance
No normative performance requirements are specified in this document.

5.7.5
The VDB shall be available to support validation requests with an availability of 99.9%.
5.8
Location Information Server (LIS)
The LIS sits within or at the edge of the access network and invokes applicable positioning
technologies enabling consistent and reliable location information to be attributable to an answerable
source. It may support a simple request/response message that allows the VPC to obtain the location
of a client without the client user identity being required. It may allow clients to request their
location directly. The LIS must support at least one of the functions but it is recommended that the
LIS support both functions. The LIS supports a location information credentialing system that
provides assurances of the applicability, currency, and identity of the source of the location
Page 93 of 247

NENA 08-001 v2, August 11, 2010
information. Precisely where a LIS resides in the network, how it determines location and the type of
location (geodetic or civic) that it returns will be dependent on a number of factors, among these are:
5.8.1
The nature of the connection used by the client. That is, whether it is a residential broadband
connection, an enterprise IP switch connected client, a wireless client connecting via a
campus wireless LAN, a client connecting to a wide area broadband wireless connection, etc.
Legacy circumstances. That is, the extent to which the clients, access devices, and switches
have native support for location delivery versus the need to overlay a solution for location
determination on existing infrastructure.
The type of location information and accuracy required for a given target environment. For
example, are static civic addresses with sufficient geodetic accuracy for routing sufficient or
is a more accurate geodetic location required in the absence of a civic address?
Detailed LIS Requirements
The LIS is a critical component in the support of emergency services for VoIP. The location of the
caller is critical both in terms of routing the call to the correct PSAP and in terms of emergency
service dispatch to the emergency location. In providing location, however, there are a number of
important attributes that should be associated with both the location information and the manner in
which it is provided. These are summarized in the following list:
1. Where the client must be aware of the LIS, the LIS shall support consistent mechanisms by
which it can be "discovered" by client devices in the access network in order that location
information and location keys can be obtained.
2. When providing a client key or signed location, the LIS shall support an expiry mechanism
by which it will delete its record of a client device within an agreed period of time unless it is
renewed by the client 16.
3. The LIS shall support a mechanism by which location can be provided to a requesting client
device in the served access using a standardized and open protocol such that all clients can
assume a consistent mechanism.
4. Location shall be coded in a standardized fashion such that systems and devices which utilize
delivered location will be able to do so in a consistent fashion.
5. The location information shall be able to be provided with associated "credentials" to ensure
the applicability of the location to the device.
a. The credentials should reliably identify the source of the location (i.e. the LIS
operational identity).
b. The credentials should identify a unique client ID that the location is associated with.
c. The credentials should identify a specific time after which the location should no
longer be considered valid.
6. The LIS shall support a mechanism whereby a client-provided location can be augmented
with location credentials by the LIS if that client-provided location can be determined by the
16 There is currently limited Standards support for signing location but it is expected that more support will available by the time the
i2 solution is deployed.
Page 94 of 247

NENA 08-001 v2, August 11, 2010
LIS to be representative of the clients actual location (e.g. a more accurate client-provided
GPS fix may be provided with credentials if the LIS can confirm the location falls within
known boundaries of the clients actual location).
7. The LIS shall support the creation and delivery of a "Location Key" at the request of the
client device, which can be used by the client or other network elements to query that clients
location information directly from the LIS. The details of the location key will be defined in
a future version of this specification.
8. The LIS shall support a standardized and open communications protocol to support the query
of location information using a location key such that querying network elements can assume
a consistent mechanism for doing so.
9. The LIS shall support encrypted communications between itself and the client device such
that exchanges of location information and location keys remain private.
10. The LIS shall enforce authentication on querying network entities such that they must have
permission to query the location of a device using a location key (e.g. the querying entity can
present emergency service credentials).
11. The LIS shall support encrypted communications between itself and querying network
elements such that exchanges of location information on client IDs remains concealed.
12. The LIS shall support a mechanism for validation of civic location information, as described
Section 6.8.
13. The LIS shall be able to support periodic revalidation of civic location information.
5.8.2
LIS Query Protocol and Location Information Format
In order for nomadic devices to be able to obtain information reliably and transparently regardless of
the IP access network that they "roam" into, it is necessary that there be a consistent means of
discovering and communicating with the LIS functional entity within the access network. To support
roaming across national network boundaries, it should be possible for a single VoIP client
implementation to determine location information in the same way regardless of the access network.
To facilitate this requirement, it is recommended that LIS interaction be based on a specification
from a global standards body.
The necessary functions for the location acquisition and delivery protocol to support are as follows:
5.8.3
A discovery mechanism must be provided. This may be an explicit indication of the serving
LIS entity identity provided, for example, by DHCP or DNS. Optionally, a broadcast and
response message that allows a client device to find a LIS in the access network may be
supported.
A direct query to the LIS to provide location is recommended.
Validated Address to PIDF-LO Mapping
Table 5-5 below shows how data elements returned by the VDB would be mapped to PIDF-LO for
an emergency call. The validated data tag names shown are from the validateAddressResponse
Page 95 of 247

NENA 08-001 v2, August 11, 2010
returned by the v7 interface. The coordinates will be provided with WGS 84 [35] datum using
EPSG:4326 format.
Table 5-5 - Validated Data Tag Names
Validated Address
Element
PIDF-LO Element
HouseNum
HouseNumSuffix
PrefixDirectional
StreetName
PostDirectional
MSAGCommunity
PostalCommunity
StateProvince
CountyName
PostalZipCode
Country
Latitude
Longitude
Elevation
5.8.4
HNO
HNS
PRD
RD 17
POD
A3
PCN 18
A1
A2
PC
Country
gml:coordinates
gml:coordinates
gml:coordinates
The LIS, in the context of emergency services, must implement strong authentication mechanisms to
protect the private nature of the information it contains.
The LIS, in the context of emergency services, must implement strong authorization policies to
protect the private nature of the information it contains.
5.8.5
Performance
Section 9.7.
5.8.6
Since the LIS may be involved during an emergency call, the LIS emergency application shall be
highly reliable and available. It is an objective that the LIS be available to a querying element (e.g.,
the VPC for LK de-referencing) at a service availability level of 99.999%.
17 RD is defined in RFC-5139 [37] which replaces A6 defined in RFC 4119 (PIDF-LO).
18 PCN is defined in RFC-5139 [37] which updates RFC 4119 (PIDF-LO).
Page 96 of 247

NENA 08-001 v2, August 11, 2010
5.9
Automatic Location Identification (ALI) Database
This section provides additional functional requirements on the existing ALI DB that shall be
implemented in support of the i2 solution.
The ALI database shall be configured with the following information associated with the ESQK:
The associated VPC (including identifier/address and contact information);

A new default VoIP Class of Service, designated as V
A default Administrative ESN to be used to identify the appropriate English Language
Translations (ELT) for the emergency responders in the serving area identified by the ESQK.
The ALI database provider must support a v-E2 interface to the VPC and be able to use it to request
and receive location information for VoIP emergency calls. The v-E2 interface is described in
Section 6.11. The ALI database shall interpret the uses of data elements on the v-E2 interface as
described in Section 6.11.1.
These procedures may differ from the processes that would be used to receive data from a wireless
carriers Mobile Positioning Center (MPC).
The ALI DB shall include a NENA identifier for the VPC as the secondary Company (Data
Provider) ID sent to the PSAP in the response to its ALI query, if this information is supported on
the ALI to PSAP interface.
The ALI DB shall be capable of receiving both civic location and geodetic location over the v-E2
interface. The ALI DB shall deliver either civic or geodetic or both depending on the ALI-to-PSAP
interface supported.
5.9.1
No incremental authentication and authorization requirements are specified for the ALI DB in this
document.
5.9.2
Performance
No incremental performance requirements are specified for the ALI DB in this document.
5.9.3
No incremental reliability and availability requirements are specified for the ALI DB in this
document.
Page 97 of 247

NENA 08-001 v2, August 11, 2010
Detailed Interface Specifications
This section provides an overview of interfaces defined in this standard. This section is intended to
give the reader a better understanding of what role each of the interfaces provides and also to
provide the detailed specifications for the identified interfaces. Where applicable, XML schemas
associated with the specified interfaces can be found at the following location..
Each interface addresses a security mechanism to be used as part of the message exchange.
The XML schema associated with this interface can be found at the following location:
http://www.nena.org/technical-xml-schemas
6.1
v0 LIS to VoIP Endpoint
The detailed specification of this interface is out of scope for this document.
The v0 interface is the name given to the interface by which an end-device is informed of its location
by an entity in the access network. At the time of writing, several mechanisms are in standard track
or have reached standard status for providing location to endpoints. These include, but are not
limited to:
1. Using DHCP to convey Geodetic information as defined in RFC 3825 [6]
2. Using DHCP to convey Civic information as defined in RFC 4776 [7].
3. Using LLDP-MED to convey Geodetic and/or Civic location as defined in ANSI/TIA-1057
[25].
4. Using HELD to request Geodetic and/or Civic location as defined in draft-ietf-geopriv-httplocation-delivery [26].
With some mechanisms, the client-device will need to make a request to the network to obtain
location information and format the information into a PIDF-LO. With others, the location will be
delivered to the end-device pre-formatted as a PIDF-LO.
The detailed specification of this interface is out of scope for this document. However, NENA
prepared a Technical Requirement Document (TRD) 08-752 [27] and a Technical Information
Document (TID) 08-505 [28] that addresses location determination and acquisition in the IP domain.
6.2
v1 VoIP endpoint to Call Server
The v1 interface represents the link between the client-device and a CS. It is over this link the user
establishes a call, and conveys location information. Location conveyance in call establishment is
being developed in the wider VoIP community. At present the most advanced work is in the IETF
and deals with location conveyance over SIP, (draft-ietf-sipcore-location-conveyance [12]). It is a
recommendation of the i2 architecture that the v1 interface be capable of transporting either location
or location key information regardless of the protocol being used to support the voice service. If the
Page 98 of 247

NENA 08-001 v2, August 11, 2010
end point and the VSP are unable to provide a location or a location key, calls might not get routed
to the appropriate PSAP.
This interface is out of scope for the i2 solution.
6.3
v2 Call Server/Routing Proxy/Redirect Server to VPC
This section describes the v2 interface between the VoIP CS/RP/RS and the VPC as shown in Figure
3-1. This interface provides a means for the CS/RP/RS to request emergency services routing
information from the VPC, and to inform the VPC, at call termination, when a routing/query key is
no longer required. The interface consists of four messages and these are introduced in subsequent
paragraphs. The v2 interface is XML-based.
The v2 interface is likely to need to operate in a variety of network environments, some trusted, and
some not. For this reason the HTTPS (HTTP [33] over TLS [22]) protocol using web services has
been selected as the transport mechanism for the v2 interface, as this provides strong security
mechanisms and is readily able to traverse enterprise and commercial firewalls when correctly
configured.
6.3.1
v2 Message Definitions
The v2 interface defines two sets of Request/Response messages (for a total of 4 messages). The first
message set requests and receives routing instructions. The second message set indicates that an
emergency call has concluded. The remainder of this Section details the 4 messages that make up
communication across the v2 interface.
6.3.1.1 Emergency Services Routing Request (esrRequest)
The esrRequest message is sent from the query node (CS/RP/RS) to the VPC to request routing
information and a query key. The valid parameters for the esrRequest message are included in the
following table.
Table 6-1 - esrRequest Parameters
Parameter
source
Condition
Mandatory
Vsp
Conditional
callId*
Mandatory
datetimestamp
Optional
callback*
Conditional
Description
The identifier of the node requesting
routing information directly from the
VPC.
The identifier of the caller's voice
service provider
Any identifier that can uniquely
identify the call globally.
Date Time Stamp indicating UTC date
and time that the message was sent
E.164 number that can be dialed by a
PSAP operator to reach the call
Page 99 of 247

NENA 08-001 v2, August 11, 2010
Parameter
Condition
Description
originator
The Location Information Element.
An ID inserted by the originating
network that allows LIS to validate if
the call is from the originating
network.
Vpc
Optional
The identifier of the destination VPC.
customer
Conditional
The subscriber/account name
associated with the callback number
* In some cases the <callback> number will uniquely identify the call at the CS. In such a case,
the <callId> parameter will contain the value of the <callback> number parameter. There is no
formal requirement for this to be the case however, and only the value contained in the
<callback> parameter shall be used to deliver the callback number over the v-E2 interface.
Lie
callOrigin
Mandatory
Optional
The <source> element identifies the node directly requesting emergency call routing from the VPC
over the v2 interface. It includes the source node (hostId), a NENA administered identifier (nenaId)
a 24x7 contact number (contact), and an optional uri URI (certUri) providing a link to the provider's
VESA issued certificate. The <source> must be a trusted entity of the VPC.
An example of how the <source> element is used, along with format definitions is as follows:
<source>
<organizationName>James's cool VSP</organizationName>
<hostId>cs34.example.com</hostId>
<nenaId>nena1</nenaId>
<contact>tel:17325551212/contact>
<certUri>https://cs34.example.com/certificate.crt</certUri>
</source>
The <organizationName> is a free form text field into which the node owner may place their
company name or other label. This field is optional.
The <hostId> identifies the fully qualified domain name or IP address of the directly requesting
node. This field is mandatory.
The <nenaId> is the NENA administered company identifier ((NENA Company ID 19) of the node
requesting routing information over the V2 interface. This field is optional.
The <contact> is a telephone number by which the directly requesting node operator can be reached
24 hours a day, 7 days a week. This field is mandatory.
19 Registered NENA Company IDs are not used outside the United States.
Page 100 of 247

NENA 08-001 v2, August 11, 2010
The <certUri> provides a means of directly obtaining the VESA issued certificate for the requesting
node. This field is optional.
The <vsp> element identifies the Voice Service Provider for the call. This element is used to identify
the original VoIP service provider, in cases where the original VSP is not the same entity as the one
requesting routing information over the v2 interface. In cases where the VoIP service provider and
the entity requesting routing information are not the same, the <source> element is used to identify
the entity requesting routing information over the v2 interface and the <vsp> element is used to
identify the voice service provider. The mechanisms used to determine the VSP at routing
proxy/redirect server are for further study.
<vsp>
<organizationName>Martin's super VSP</organizationName>
<contact>tel:398348975439823</contact>
</vsp>
The <hostId> and <contact> elements must be provided. The <organizationName>, <nenaId> and
<certUri> fields are optional.
The <callId> element is an identifier that can be used to uniquely identify the call globally. If a
callId is received in SIP signaling, the Call Server shall use the received callId as the callId over the
v2 interface. If a callId is not received in incoming signaling, the call server/proxy shall follow the
recommended procedures as specified in RFC3261 for UA Call-ID generation.
An example of a callId received in SIP signaling:
<callId>3848276298220188511@atlanta.example.com</callId>.
The <callback> number is a tel-uri of the format tel: 1-212-555-8215. This identifies the E.164
number that can be dialed to reach the caller. This is the number that will be included in the callback
number field in the esposreq response message to the ALI.
<callback>tel:1-212-555-8215</callback>
The <lie> is the Location Information Element that contains location information that is used to
determine the routing and query keys to be used for the call. This parameter is mandatory, and if not
provided, the VPC must provide default routing or an error to the requesting node. If the <lie> is
present in the esrRequest, then it may contain a LocationKey, a PIDF-LO (geodetic and or Civic), or
both. The exact mechanism used to determine the routing and query keys is dependent on the
contents of the <lie>.
Page 101 of 247

NENA 08-001 v2, August 11, 2010
<lie>
<locationKey>3c01abe092@lis.example.com</locationKey>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0"
entity="3c01abe092@lis.example.com">
<tuple id="sg89ab">
<status>
<gp:geopriv>
<gp:location-info>
<gml:position>
<gml:Point gml:id="point1" srsName="epsg:4326">
<gml:pos>37.775 -122.422</gml:pos>
</gml:Point>
</gml:position>
<cl:civilAddress>
<cl:country>US</cl:country>
<cl:FLR>2</cl:FLR>
</cl:civilAddress>
</gp:location-info>
<gp:usage-rules>
</gp:usage-rules>
</gp:geopriv>
</status>
<timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
</lie>
The LIE example above shows both Geodetic Location and Civic address information, which is
acceptable, but in most cases it is expected that either Geodetic Location or Civic Location would be
sent in the LIE.
The <callOrigin> parameter is used by the VPC when it sends a LocationKey to the LIS over the v3
interface. The LIS is able to use this parameter to determine if the LocationKey received belongs to
the originating network. Use of this parameter is LIS implementation-specific and is subject to local
access network policy.
<callOrigin>accessNetwork.com</callOrigin>
The <datetimestamp> is the date time stamp in UTC time using ISO 8601 [44] format indicating the
time that the message was sent from the requesting node. This field is optional, but if not included,
then the VPC must maintain an accurate date and time stamp in any call event records so that an
audit trail is readily accessible.
<datetimestamp>2004-12-12T21:28:43Z</datetimestamp>
The <vpc> element identifies the VPC from which routing information is being requested.
Page 102 of 247

NENA 08-001 v2, August 11, 2010
<vpc>
<organizationName>Specific VPC Service</organizationName>
</vpc>
The coding of the VPC element is the same as the coding for the source element.
The <customer> is an alphanumeric field that identifies the subscriber/account owner name
associated with the callback number in subscription data. The customer name will be included in the
<NAM> field of the Location Description parameter in the esposreq response message to the ALI.
<customer>Turin Turumbar</customer>
6.3.1.1.1 LIE PIDF-LO Routing

When the LIE contains a PIDF-LO, the VPC will perform a lookup in the ERDB, to obtain the ERT
consisting of a Selective Routing Identifier (i.e., CLLI code), a routing ESN, and an NPA, as well as
a contingency routing number (CRN) for the PSAP. Using the Selective Routing Identifier, routing
ESN, and NPA, the VPC can identify and allocate an ESQK. The ESQK, CRN, and either the ERT
or ESGWRI are subsequently returned to the Call Server/Proxy in an esrResponse message, with the
CRN being carried to the Call Server as an LRO.
6.3.1.1.2 LIE LocationKey Routing
The LocationKey provides information to the VPC on where to get the location of the caller. The
LocationKey may explicitly indicate a client-id and a LIS, say in the form or a URI, or it may be a
different form of identifier, such as callback number, that the VPC can use internally to determine a
LIS and subsequently request a location object. Having determined the LIS from the LocationKey,
the VPC then passes the LIE to the LIS and receives a LIE back, this time containing the original
LocationKey and a PIDF-LO. The VPC is then able to route based on the PIDF-LO as it did in the
Section 6.3.1.1.1.
6.3.1.1.3 esrRequest Message Format
The high-level message format for the esrRequest message is shown below:
Page 103 of 247

NENA 08-001 v2, August 11, 2010
<esrRequest xmlns="urn:nena:xml:ns:es:v2"
<vpc>
<hostId>vpc.example.com</hostId>
</vpc>
<source>
<organizationName>Terry's redirect proxy</organizationName>
<hostId>rp34.example.com</hostId>
<contact>tel: 398348975439823</contact>
<certUri>https://rp34.example.com/certificate.crt</certUri>
</source>
<vsp>
<organizationName>Operator One's Call Server</organizationName>
</vsp>
<callId>610239946019573</callId>
<callback>610239946019573</callback>
<lie>
<locationKey>3c01abe092@lis.example.com</locationKey>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:pidf="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://opengis.net/gml" entity="pres:user@example.com">
<tuple id="a6fea09">
<status>
<gp:geopriv>
<gp:location-info>
<gml:position>
<gml:Point gml:id="point1" srsName="epsg:4326">
<gml:pos>42.5463 -73.2512</gml:pos>
</gml:Point>
</gml:position>
</gp:location-info>
<gp:usage-rules>
</gp:usage-rules>
</gp:geopriv>
</status>
<timestamp>2004-12-01T09:28:43Z</timestamp>
</tuple>
</presence>
</lie>
<callOrigin>Some arbitrary string in here</callOrigin>
<customer>Gomer Pyle</customer>
Page 104 of 247

NENA 08-001 v2, August 11, 2010
</esrRequest>
6.3.1.2 Emergency Services Routing Response (esrResponse)

The esrResponse message is sent by the VPC to a routing entity (Call Server/Routing Proxy/Redirect
Server) in response to an esrRequest message. Valid parameters for the esrResponse message are
contained in the following table.
Table 6-2 - esrResponse Parameters
Parameter
Condition
Description
vpc
Mandatory
The identifier of the responding VPC
callId
Mandatory
An identifier that uniquely identifies

the call at the Call Server
esgwri
Conditional
If determined by the VPC, this field

will contain the Routing Key that
allows routing of the call to the
Selective Router servicing the local
area in which the call was made.
ert
Conditional
The Emergency Route Tuple

comprised of the following tags used
by the receiving node to select the
appropriate ESGWRI.
selectiveRoutingID
Conditional
The Common Language Location

Indicator (CLLI) code associated with
the Selective Router to which the
emergency call is to be directed.
routingESN
Conditional
The Emergency Services Number

associated with a particular ESZ that
represents a unique combination of
Police, Fire and EMS emergency
responders.
npa
Conditional
The Numbering Plan Area (NPA)

associated with the outgoing route to
the Selective Router that is appropriate
for callers location.
Conditional
The Query Key allocated by the VPC
esqk
Page 105 of 247

NENA 08-001 v2, August 11, 2010
Parameter
Condition
Description
to uniquely identify the call within ESZ
lro
Conditional
The last routing option. This routing

option should only be used by the call
server or proxy as a last resort. The
actually meaning of the LRO is
different depending on what other
information is returned in response to
the query.
Result
Mandatory
Code indicating the reason for success

or failure to determine an ERT and
ESQK. See the next table for more
details.
datetimestamp
Optional

and time that the message was sent.
destination
Optional
The identifier of the routing node

immediately adjacent to the VPC.
The <vpc> element identifies the VPC.

<vpc>
<hostId>vpc34.example.com</hostId>
<certUri>https://vpc34.example.com/certificate.crt</certUri>
</vpc>
The <hosted>, <nenaId>, and <contact> fields are mandatory while the other fields of the <vpc>
element are optional.
The <destination> element identifies the node that directly requested emergency call routing
information from the VPC. It includes the source node (hostId), a NENA administered Company ID
identifier (nenaId), a 24x7 contact number (contact), and optional parameters for the organization's
name and URI (certUri) for the operator's VESA issued certificate. The <destination> must be a
trusted entity of the VPC.
Page 106 of 247

NENA 08-001 v2, August 11, 2010
<destination>
<organizationName>Generic Redirect Proxys</organizationName>
<hostId>rp34.example.com</hostId>
<certUri>https://rp34.example.com/certificate.crt</certUri>
</destination>
The <organizationName> is a free form text field into which the node owner may place their
company name or other label. This field is optional.
node. This field is mandatory.
The <nenaId> is the NENA administered company identifier (NENA Company ID). This field is
mandatory.
The <callId> is an identifier that uniquely identifies the call at the requesting node.
<callId>767673678674835784587</callId>
The <esgwri> is the translation of the ERT with ESGW-specific information provided by either the
VSP or ESGW operator directly. An <esgwri> may be provided if the VPC performs the ERT-toESGWRI translation and a corresponding <esqk> is provided. The ESGWRI format is as follows:
sip: 1 numberstring@esgwprovider.domain;user=phone where the numberstring is 10
numeric characters (e.g., nnnnnnnnnn)

The <selectiveRoutingID> contains the CLLI code of the selective router to which the call is being
routed. The CLLI code is an 11 character alphanumeric field of the form AAAABBCCDDD, where
AAAA represents the city/county
BB represents the State
CC represents the building or location
DDD represents the network.
The Selective Routing Identifier will be included in the response message if the VPC is not
responsible for performing ERT-to-ESGWRI translation. The <selectiveRoutingID> must only be
provided if a <routingESN>, <npa>, and <esqk> are also provided, and must not be provided if an
<esgwri> is provided.
The <routingESN> is a 3- to 5 digit field that uniquely identifies the ESZ in the context of an SR,
and the associated Police, Fire, and EMS emergency responders associated with that ESZ. The
<routingESN> must only be provided if a <selectiveRoutingID>, <npa>, and <esqk> are also
provided, and must not be provided if an <esgwri> is provided.
The <npa> is a 3 digit field that identifies an NPA associated with an outgoing trunk group to the
appropriate SR associated with the callers location. The <npa> must only be provided if a
Page 107 of 247

NENA 08-001 v2, August 11, 2010
<selectiveRoutingID>, <routing ESN>, and <esqk> are also provided, and must not be provided if
an <esgwri> is provided.
<ert>
<selectiveRoutingID>QUBCPQ00CG1</selectiveRoutingID>
<routingESN>12345</routingESN>
<npa>418</npa>
</ert>
The <esqk> element contains the ESQK allocated by the VPC. This key identifies an ESN for a
specific PSAP, as well as the call instance at the VPC. A valid value must be returned in this field
for the call to be successfully routed to the appropriate PSAP, and for location information to be
supplied from the VPC to the PSAP. An <esqk> must only be provided if a corresponding <esgwri>
or <ert> is also provided. The <esqk> is expected to be a 10-digit North American Numbering Plan
Number. More information on ESQKs can be found in Interim p-ANI Administration Guidelines
(Rev. December 5, 2005) [54].
<esqk>npanxxnnnn</esqk>
The <lro> element contains the last routing option and provides the routing node with a "last
chance" destination for the call. The LRO may contain the Contingency Routing Number (CRN),
which is a 24x7 PSAP emergency number, or it may contain a routing number associated with a
national or default call center. The service type will depend on the condition that resulted in the
providing of the LRO. Ultimately the usage of LRO routing data for call delivery will depend on
decisions made internally to the routing node. There may be occasions when the VPC only returns
an LRO. Examples of scenarios in which this may be the case include invalid or unavailable
location information, VPC resource limitations, or the invoking of local PSAP routing policies.
When primary routing options fail, and no LRO is provided, the routing node is required to provide
specific default handling, which may include dropping the call. The <lro> shall be expressed as a
URI.
<lro>tel: 1-npa-nxx-nnnn</lro>
The <result> element indicates to the routing node whether or not the VPC was able to provide
routing information and the means by which the routing data was determined, or if no routing
information could be provided, the source of the problem. This element therefore provides a means
by which the VSP can monitor the quality of the routing information provided by a VPC operator. A
complete list of valid <result> codes is detailed in
Table 6-3. The values of the code are expected to be sent in this element.
<result>200 SuccessGeodetic</result>
The <datetimestamp> is the date time stamp in UTC time using ISO 8601 [44] indicating the time
that the message was sent from the VPC. This field is optional, but if not included, then the routing
Page 108 of 247

NENA 08-001 v2, August 11, 2010
node must maintain an accurate date and time stamp in any call event records so that an audit trail is
readily accessible.
Table 6-3 - Result Codes
Value
200
201
Name
SuccessGeodetic
SuccessLISGeodetic
Description
VPC has successfully determined the routing
information based on geodetic information contained
in the initial esrRequest
information based on geodetic information obtained
from the LIS.
202
SuccessCivic
203
SuccessLISCivic
400
LROBadLocation
401
LRONoLIS
402
LRONoLocation
403
LROBadMessage
404
LRONoAuthorization
405
ErrorBadLocation
406
ErrorNoLIS
407
ErrorNoLocation

information based on civic information contained in
the initial esrRequest
VPC has successfully determined routing information
based on civic information obtained from the LIS
No routing information can be determined from the
location provided in the LIE. This may be because the
LIE is malformed, or because the location does not
map to a provisioned PSAP boundary. LRO is
provided, but this is really default routing.
The VPC is unable to determine the LIS from which to
get the location. An LRO is returned.
The VPC was unable to get a location for the client
from the LIS. An LRO is returned.
The esrRequest received by the VPC could not be
parsed or was malformed. An LRO is returned
The requesting node's esrRequest message failed
authorization at the VPC. An LRO is provided.
VPC was unable to get routing information based on
the sourced location. VPC is unable to provide an
LRO for routing.
VPC was unable to determine the LIS based on a
provided location key. VPC is unable to provide an
LRO for routing.
The VPC is unable to get a location from the LIS for
the location key provided. VPC is unable to provide an
LRO for routing.
Page 109 of 247

NENA 08-001 v2, August 11, 2010
Value
408
Name
ErrorBadMessage
409
ErrorAuthorization
500
LRONoResource
501
LROGeneralError
502
ErrorNoResource
503
ErrorGeneral
Description
The esrRequest received by the VPC could not be
parsed or was malformed. VPC is unable to provide an
LRO for routing.
The requesting node's esrRequest message failed
authorization at the VPC. VPC is unable to provide an
LRO for routing.
VPC was unable to allocate an ESQK (or default
ESQK) due to failure, and an LRO is provided to
enable default routing.
A general error is encountered and the VPC provides a
LRO to enable default routing.
The VPC is unable to allocate an ESQK (or default
ESQK) due to failure, and no CRN was provided from
the ERDB. VPC is unable to provide an LRO for
routing.
Any error cause that is not listed above. VPC is unable
to provide an LRO for routing.
6.3.1.2.1 esrResponse Message Format

The following is an esrResponse message showing a successful response (result = 200). This
example message contains valid <esqk> and <lro> values, along with a valid <ert> consisting of a
<selectiveRoutingID>, <routingESN>, and <npa>. Note that this message could contain a valid
<esgwri> instead of the <ert> if the VPC performs the ERT-to-ESGWRI translation.
Page 110 of 247

NENA 08-001 v2, August 11, 2010
<esrResponse xmlns="urn:nena:xml:ns:es:v2"
<result>200 SuccessGeodetic</result>
<vpc>
<certUri>https://vpc.example.com/certificate.crt</certUri>
</vpc>
<destination>
<organizationName>James's Call-Server</organizationName>
</destination>
<callId>610239946019573</callId>
<ert>
<selectiveRoutingID>CITYTX12NET</selectiveRoutingID>
<npa>817</npa>
</ert>
<esqk>469327927621542</esqk>
<lro>tel: 160910920672398</lro>
</esrResponse>
6.3.1.3 Emergency Services Call Termination Message (ESCT)

The ESCT message is sent from the routing node to the VPC at the conclusion of the emergency
call. The intent of this message is to return the <esqk> associated with the call back to the pool of
available query keys for use by the VPC, and to inform the VPC as to which ESGW was used to
direct the call to the Selective Router. The valid parameters for the ESCT message are included in
the following table.
Table 6-4 - ESCT Parameters
Parameter
source
Condition
Mandatory
esqk
esgw
Conditional
Conditional
Description
The identifier of the routing node
directly adjacent to the VPC
The ESQK to return to the VPC pool
The identifier of the ESGW used to
direct the call to the selective router
Page 111 of 247

NENA 08-001 v2, August 11, 2010
Parameter
datetimestamp
Condition
Optional
callId
Mandatory
vpc
Optional
Description
and time that the message was sent
The identifier that uniquely identified
the call at the Call Server
The identifier of the VPC
The <source> element identifies the node directly requesting emergency call routing from the VPC.
It includes the source node (hostId), a 24x7 contact number (contact), as well as an optional NENA
administered company identifier (nenaId), and an optional uri (certUri) that provides a link to the
provider's VESA issued certificate. The <source> must be a trusted entity of the VPC.
The value of <hostId> element within <source> element must be identical within any set of
associated esrRequest and ESCT messages.
The format of the <source> element is shown below:
<source>
<organizationName>CS-2K</organizationName>
</source
The <organizationName> element stores free form text field into which the node owner may place
their company name or other label. This field is optional.
node, this field is mandatory.
The <nenaId> element stores the NENA administered company identifier (NENA Company ID),
this field is optional.
The <contact> element stores a telephone number by which the directly requesting node operator
can be reached 24 hours a day, 7 days a week. This element is mandatory.
The <certUri> element provides a means of directly obtaining the VESA issued certificate for the
requesting node. This element is optional.
Page 112 of 247

NENA 08-001 v2, August 11, 2010
<vpc>
</vpc>
The <hostId> and the <contact> must be provided. The <nenaId>, <organizationName> and
The <esqk> element stores the ESQK that was allocated by the VPC for the call. This is the ESQK
that can now be returned to the pool of ESQKs available for use by the VPC.
<esqk>npa-nxx-nnnn</esqk>
The <esgw> element stores the identifier for the ESGW that was used to direct to the call to the
selective router. If an LRO was used to route the call then this element must not be present in the
ESCT message. The <esgw> is expected to be in the form of an IP address or a fully qualified
domain name.
<esgw>http://esgwprovider1.example.com</esgw>
The <callId> element stores the identifier that uniquely identifies the call at the querying node.
<callId>sips:123456789456123@cs34.example.com</callId>
Any <callId> values must be identical within any set of associated esrRequest and ESCT messages.
The <datetimestamp> element stores the date time stamp in UTC time using ISO 8601 [44] format
indicating the time that the message was sent from the routing node. This field is optional, but if not
included, then the VPC must maintain an accurate date and time stamp in any call event records so
that an audit trail is readily accessible.
6.3.1.3.1 v2 ESCT Message Format

The format for the ESCT message is defined below:
Page 113 of 247

NENA 08-001 v2, August 11, 2010
<esct xmlns="urn:nena:xml:ns:es:v2"
<vpc>
</vpc>
<source>
<organizationName>National Call-Servers</organizationName>
</source>
<esgw>http://esgwprovider1.example.com</esgw>
<esqk>123456789456123</esqk>
</esct>
An esctAck message is sent from the VPC to the routing entity (CS/RP/RS) in response to an ESCT
message. If the Call Server does not receive an esctAck message after a specified time period, the
Call Server will log this event. The length of specified time period is an implementation detail. The
valid parameters for the esctAck message are contained in the following table.
Table 6-5 v2 esctAck Message Parameters
Parameter
callId
Condition
Mandatory
vpc
Datetimestamp
Mandatory
Optional
Description
Identifies the call at the
routing element
The identifier of the VPC
Date & Time Stamp
indicating UTC date and
time that the message was
sent
The <callId> element stores the identifier that uniquely identifies the call at the routing element.
Page 114 of 247

NENA 08-001 v2, August 11, 2010
<vpc>
</vpc>
The <hostId> and <contact> must be provided. The <nenaId>, <organizationName> and
The <datetimestamp> parameter stores the date and time stamp in UTC time using ISO 8601 [44]
format indicating when the message was sent from the VPC. This field is optional, but if not
included, then the routing node must maintain an accurate date and time stamp in any call event
records so that an audit trail is readily accessible.
6.3.1.3.2 v2 esctAck Message Format

Below is an example esctAck message sent by the VPC.
<esctAck xmlns="urn:nena:xml:ns:es:v2"
<vpc>
</vpc>
</esctAck>
6.3.2
v2 Message Call Flows, Key Scenarios and Semantics
Section 6.3.1 described in detail the 4 messages that make up communication across the v2 interface.
This section will describe the key call scenarios and show the message flows between the various
network elements.
6.3.2.1 v2 esrRequest contains valid Location
The following figure describes a typical call flow where a valid PIDF-LO document containing a
geodetic and/or civic location is provided by the LIS. The v2 messages are identified in bold red
Page 115 of 247

NENA 08-001 v2, August 11, 2010
LIS
UA
CS
VPC
ESGW
1. PIDF-LO
2. Call Init
(PIDF-LO)
3. esrRequest (PIDF-LO,
customer, callback)
4. esrResponse (ert or
esgwri, esqk, lro)
5. Route Call
Voice communication established

6. Call Termination
7. esct
(callid, esgw, esqk)
8. esctAck
Figure 6-1 PIDF-LO Routing over v2
1. The LIS provides a PIDF-LO containing geodetic and or civic information to the UA over
v0.
2. The UA initiates an emergency call to the CS over v1 and includes the PIDF-LO in the call
initiation message.
3. The CS determines the provisioned callback number and subscriber name associated with the
UA, and constructs an esrRequest message that includes a Call-ID, callback number,
subscriber name, and LIE containing the PIDF-LO. The CS sends the esrRequest message to
the VPC over v2.
4. The VPC receives the esrRequest from the CS and authenticates the CS. The VPC uses the
location contained in the PIDF-LO to obtain an ERT consisting of a Selective Routing
Identifier, routing ESN, and NPA, and a CRN from the ERDB (not shown). The VPC
Page 116 of 247

NENA 08-001 v2, August 11, 2010
5.
6.
7.
8.
allocates an ESQK based on the ERT. The VPC constructs an esrResponse message
containing the ESQK, LRO, and either the ESGWRI or the ERT, and returns this to the CS
over v2.
The CS uses the ESGWRI, if received in the routing response, to determine the correct
ESGW, or the CS determines the ESGW and appropriate ESGWRI value based on the ERT
received in the routing response message. The Call Server subsequently routes the call to the
ESGW over v4, and includes the ESGWRI, ESQK and callback number in outgoing
signaling.
The CS detects that call has concluded, and that the ESQK is no longer required.
The CS sends an ESCT message containing the ESQK, ESGW identifier and call ID to the
VPC.
The VPC accepts the ESCT message, authenticates the Call Server, returns the ESQK to the
pool of available keys, and notes the ESGW in its call event records. The VPC sends an
esctAck message to the Call Server.
Page 117 of 247

NENA 08-001 v2, August 11, 2010
6.3.2.2 esrRequest contains a LocationKey

The following figure describes a typical call flow where a Location Key is provided by the LIS. Note
that the Location Key cannot be genuinely used for routing and must be de-referenced at the LIS
first. The v2 messages are identified in bold red.
Figure 6-2 LocationKey Routing
Page 118 of 247

NENA 08-001 v2, August 11, 2010
1. The LIS provides a LocationKey to the UA over v0. The LocationKey may explicitly
identify a client and LIS, or it may contain a value that implies these identities to the VPC.
Regardless of the actual implementation, the LocationKey provides sufficient information to
enable to the VPC to request the location of a UA.
2. The UA initiates an emergency call to the CS over v1 and includes the LocationKey in a LIE
which is sent with the call initiation message.
UA, and constructs an esrRequest message that includes a Call ID, callback number,
subscriber name and LIE containing the LocationKey. The CS sends the esrRequest message
to the VPC.
LIS ID to send the LIE to the LIS, and request a LocationObject over v3.
5. The LIS authenticates and VPC and validates the LocationKey. The LIS returns a LIE to the
VPC containing a valid PIDF-LO.
6. The VPC uses the location returned by the LIS to request routing information from the
ERDB (not pictured). The VPC allocates an ESQK. The VPC constructs an esrResponse
message containing the ESQK, LRO, and either the ESGWRI or the Selective Routing
Identifier, routing ESN, and NPA (the ERT), and returns this to the CS over v2.
7. The CS uses the ESGWRI, if received in the routing response, to determine the correct
ESGW, or the CS determines the ESGW and appropriate ESGWRI value based on the
Selective Routing Identifier, routing ESN, and NPA received in the routing response
message. The CS subsequently routes the call to the ESGW, and includes the ESGWRI,
ESQK and callback number in outgoing signaling.
8. The CS detects that the call has concluded, and that the ESQK is no longer required. The CS
sends an ESCT message containing the ESQK, ESGW identifier, and Call ID to the VPC.
9. The VPC accepts the ESCT message, authenticates the CS, returns the ESQK to the pool of
available keys, and notes the ESGW identifier in the call event records. The VPC sends an
ESCTAck message to the CS.
Page 119 of 247

NENA 08-001 v2, August 11, 2010
6.3.2.3 VPC returns an Error

The following figure describes a typical call flow where an invalid PIDF-LO document is provided
by the LIS. The v2 messages are identified in bold red.
LIS
UA
CS
VPC
PSTN
GW
1. PIDF-LO
2. Call Init
(PIDF-LO)
customer, callback)
4. esrResponse (error)
5. Default Route

6. Call Termination
Figure 6-3 Routing Error
1. The LIS provides a PIDF-LO containing Civic address information to the UA over v0.
initiation message.
subscriber name, and a LIE containing the PIDF-LO. The CS sends the esrRequest message
to the VPC over v2.
Page 120 of 247

NENA 08-001 v2, August 11, 2010
4. The VPC receives the esrRequest from the CS and authenticates the CS. The VPC is unable
to determine routing based on the location so it returns an error indication in the esrResponse
to the CS with no LRO.
5. The error indication in the esrResponse message triggers the CS to perform its default routing
behavior using local default routing policies (as shown in the example call flow above) which
may be to send the call to a default PSAP via an admin line or to a 3rd party call center. When
the call is routed to a PSAP admin line or a third party call center, a PSTN gateway will be
used instead of an ESGW.
6. Some time later, the caller hangs-up, the CS detects that call has concluded and forwards the
call termination message to the PSTN Gateway.
Note that the VPC is not expecting a v2 ESCT message at call termination time since no ESQK was
allocated for that call.
6.3.3
v2 Interface Security
The v2 interface will need to operate in a variety of network environments, some trusted, and some
not, as described previously. The v2 interface is an XML-based interface and should be used with a
suitable security mechanism as defined in Section 4. When the connection between the routing entity
and the VPC is not on a trusted network, both the routing entity and VPC are expected to be
protected with IPsec or TLS, and thus require certificates rooted in VESA. Even in a trusted
network, TLS protection is advisable. The VPC is the server, and the routing entity is the client in
this interface. Mutual authentication is required when cryptographic security is deployed.
6.4
v3 VPC to LIS
NOTE: The v3 Interface protocol defined in Issue 1 of this Standard is being deprecated in
Issue 2 of this Standard in anticipation of NENA adopting an industry accepted mechanism to
provide the v3 functionality in a subsequent issue of this specification. The reasons for
deprecating the existing v3 interface definition include:
The existing v3 interface definition is not in line with current thinking on location
reference/dereference mechanisms and protocols.
This Standard would be more widely deployed if it used a location

reference/dereference mechanism supported by more than just NENA
Deprecation of the v3 interface protocol in i2.5 provides a warning to developers to

defer development of the v3 interface until industry Standards related to location
reference/dereference have stabilized.
It is anticipated that the v3 Interface will support the HELD protocol, with SIP as another
potential option.
The original v3 interface protocol definition can be found in NENA 08-001 Issue 1.
Page 121 of 247

NENA 08-001 v2, August 11, 2010
6.5
v4 - Call Server/Routing Proxy to ESGW
This version of the i2 specification defines the v4 interface based on the SIP protocol. Other
protocols can be used provided they meet the requirements included in this document. The v4
interface, outlined within the current NENA i2 architecture, defines the communication protocol and
messaging between a CS or RP and the ESGW. This interface specification is intended to outline the
required data fields, with formats and examples, by which a CS or RP can properly assemble and
send data and also so that the ESGW knows what data format to expect, in order to further set-up
and facilitate the completion of an emergency voice call to the appropriate E9-1-1 network element.
The v4 interface provides the final leg of IP messaging into the existing TDM-based Emergency
Services Network. In the network implementation examples shown within this document, the v4
interface is always implemented between a SIP Proxy Server and an ESGW.
6.5.1
v4 Interface Architecture
With SIP, a variety of signaling paths leading up to the v4 interface may exist, including proxy
configurations which terminate the v4 interface. Because of this network variability, the v4 interface
may terminate to a 9-1-1 Call Server/Proxy, or any other (SIP) 9-1-1 Call Proxy. Despite other
variations which may exist in practice, this specification focuses on two basic scenarios which are
depicted below.
Emergency Services
Provider Network
IP domain
Routing Proxy
Call Server/
Proxy
v6
v4
ESGW(s)
v4
v1
VoIP
End
Point
E9-1-1
Selective
Router(s)
PSAP
v2
SRDB
v2
VPC
Figure 6-4 v4 Interface Proxy Example
Scenario 1:
Page 122 of 247

NENA 08-001 v2, August 11, 2010
The CS receives routing instructions (provided by the VPC over the v2 interface). It then uses this
information to format a SIP INVITE message and sends it over the v4 interface to the appropriate
ESGW.
Scenario 2:
The CS sends the call to the RP over the v6 interface. The RP receives routing instructions (provided
by the VPC over the v2 interface). It then uses this information to format a SIP INVITE message and
sends it over the v4 interface to the appropriate ESGW.
Call flows and detailed messaging described in the following sub-sections are developed based on
Scenario 1.
6.5.2
v4 Interface Call Flow
The following call flow represented by a ladder diagram shows an emergency 9-1-1 call where the
CS queries the VPC to obtain necessary 9-1-1 call routing information and then uses the received
routing information to route the call to the ESGW. This messaging scenario is graphically depicted
in Figure 6-5. Messages which pertain to the V4 interface are shown in bold red. Also included is a
detailed call flow process description.
Page 123 of 247

NENA 08-001 v2, August 11, 2010
Figure 6-5 v4 interface Call Flow
Detailed description of the procedure:

1. A VEP, which has registered with the VSP and has a known and validated location, initiates
a 9-1-1 emergency call by sending a SIP INVITE message with 911 as the dialed number
and its media capabilities encapsulated in a SDP payload (denoted as SDP1), to the CS.
2. The CS responds back to the VEP with a SIP 100 Trying message.
Page 124 of 247

NENA 08-001 v2, August 11, 2010
3. The CS requests routing information from the VPC. Using the information provided by the
VPC, the 9-1-1 Call Server sends an INVITE to the ESGW. The INVITE message contains
the ESGWRI, ESQK and callback number associated with the emergency call. The ESGW
sets up the call to the SR using the ESGWRI to determine the appropriate trunk group. The
call is delivered to the Selective Router along with the ESQK, and possibly the callback
number, as determined by trunk group provisioning.
4. The ESGW responds back to the CS with a SIP 100 Trying message.
5. A SIP 183 Session Progress message is returned from the ESGW to the 9-1-1 Call Server to
indicate that the call has been delivered to the Selective Router.
6. A SIP 183 Session Progress message is returned from the 9-1-1 Call Server to the VEP.
7. A SIP 200 OK message is returned from the ESGW to the CS with its media capabilities
encapsulated in a SDP payload (denoted as SDP2) to indicate that the call has been answered.
8. A SIP 200 OK message is sent with its media capabilities encapsulated in a SDP payload
(denoted as SDP2) from the CS to the VEP.
9 A SIP Ack is returned from the VEP to the CS to acknowledge receipt of the 200 OK
message.
10. A SIP Ack is returned from the CS to the ESGW.
11. RTP channels are established end-to-end between the VEP and the ESGW.
12. After some time, the emergency caller releases the call and the VEP initiates a SIP BYE
message to the CS.
13. The CS sends a SIP BYE message to the ESGW. (Note: Each call could be terminated from
either end, though VEP call termination is shown here.)
14. The ESGW sends a SIP 200 OK message to the CS.
15. The CS sends a SIP 200 OK to the VEP.
6.5.3
v4 Message Parameters
6.5.3.1 v4 - Sending of SIP INVITE message

The message is identified in step 3 of Figure 6-5. It originates as a SIP INVITE from the CS to the
ESGW. Valid parameters for this message are included in the following table.
i2 Data Element
Condition
Provider-ID
Mandatory
ESQK
Mandatory
ESGWRI
Mandatory
SIP Header
found in
Via
P-AssertedIdentity
Request-URI
Description
The identifier of the VoIP [Call]
Service provider (VSP). Other
Provider-IDs (e.g., Routing Proxy
or Redirect Server) may be
presented in additional Via
headers
Key allocated for the call for ALI
query.
Number used to direct the call to
Page 125 of 247

NENA 08-001 v2, August 11, 2010
(Emergency
Services Gateway
Route Identifier)
callbackNumber
the Emergency Service Gateway

and SR trunk
Conditional*
customer
Optional
NENA
propriety
Parameter in PAssertedIdentity
(CBN=)
P-assertedIdentity
E.164 number that can be dialed

by a PSAP operator to reach the
call originator
Subscriber name
Table 6-6 SIP INVITE - Standard Message Elements
* ESGWRI, ESQK, and callback are requested. Mandatory when available.

6.5.3.2 v4 - SIP 200 OK (SDP2) message
This message is identified in step 7 of Figure 6-5. It originates as a SIP 200 OK from the ESGW.
Valid parameters are included in the following table.
Parameter
esgwID
Condition
Mandatory
SIP Header
Via
Description
The identifier (IP Address or
FQDN) of the ESGW Service
provider
Table 6-7 SIP 200 OK
6.5.4
Specification of the v4 interface
6.5.4.1 Transport of SIP based v4 interface

UDP will be the default transport mechanism of the v4 SIP interface with port 5060.
TCP will be used as alternative transport of the v4 SIP interface, with port 5060.
TLS (SIPS) over TCP transport, with port 5061, should be used where public access is required.
6.5.4.2 v4 SIP Methods, Messages and Information Elements
The implementation of the v4 interface shall support the SIP methods and responses documented
within this document, and as defined in RFC 3261 [5] and draft-ietf-sipcore-location-conveyance
[12].
Page 126 of 247

NENA 08-001 v2, August 11, 2010
6.5.4.3 v4 -SIP INVITE message to ESGW:
When a Call/Proxy Server implementation is deployed connecting the v4 interface on one end and
the ESGW on the other end, it is assumed that the Call/Proxy Server will be interconnected to the
VPC through a Redirect Server via the v5, or directly via the v2 interface. In a RP configuration, the
v4 interface is connected on one end to the RP and to the ESGW on the other end. The v2 interface
to the VPC is expected to be hosted at the RP. In both cases, the RequestURI (SIP INVITE) and PAsserted-Identity header information should be constructed as follows:
INVITE sip:+1ESGWRI@esgwprovider.net;user=phone SIP/2.0
Via: SIP/2.0/UDP proxyserver@RP.com;branch=z9hG4bKrandomstuff
Via: SIP/2.0/UDP callserver@vsp.com;branch=z9hG4bK4b43c2ff8.1
Record-Route: <sip:proxyserver@rp.com;lr>
Record-Route: <sip:callserver@vsp.com;lr>
Max-Forwards: 68
To: <sip:911@vsp.com>
From: <sip:+1CgPN@vsp.com;user=phone>
P-Asserted-Identity:<sip:+1ESQK@vsp.com;user= phone;CBN=callback 20>
Call-ID: callid1
Geolocation: <cid:URI-ID@vsp.com>;inserted-by=URI-ID@vsp.com;recipient=endpoint
Supported: geolocation
Accept: application/sdp, application/pidf+xml
CSeq: 1 INVITE
Content-Type: multipart/mixed; boundary=simple boundary
Content-Length: XXXX
--simple boundary
Content-type: application/cpim-pidf+xml; charset=us-ascii
Content-ID: URI-ID@vsp.com
(LO not shown)
--simple boundary
Content-Type: application/sdp
(SDP not shown)
--simple boundary
In network configurations using a standalone RS or a RP, an additional Via header may be present
identifying the intermediary element.
20 Although, in this example, both the From header and the P-Asserted-Identity header contain the callback number, it should be
noted that the content of the From header and the P-Asserted-Identity need not be the same. The From header is what was received
from the UA and the CBN is whatever the VSP puts in a PAI. The P-Asserted-Identity will include a URI parameter that contains the
callback number that the Call Server/Proxy determined to be associated with the emergency call, based on local procedures.
Page 127 of 247

NENA 08-001 v2, August 11, 2010
Another valid form of the PAI header would be:
P-Asserted-Identity: subscriber name <tel+1-ESQK;CBN=npanxxnnnn>
A Record-Route header must be inserted by each node involved in progressing the call to ensure
they remain in the dialog throughout the call.
6.5.4.3.1 v4 - ESGW SIP message handling:
When receiving a SIP INVITE, the ESGW shall extract the ESGWRI from the contact header and
identify the outgoing trunk group over which the emergency call will be delivered to the SR. If a
single 10-digit number is to be signaled over the outgoing trunk group, the ESGW shall extract the
number in the URI of the P-Asserted-Identity header (i.e., the ESQK) and send it over the trunk
interface to the Selective Router as the calling party number/ANI.
If the ESGW determines that two 10-digit numbers (i.e., ESQK + callback number) are to be
signaled to the SR, the ESGW shall extract the number in the URI of the P-Asserted Identity header
(i.e., the ESQK) and signal that number to the Selective Router in the Generic Digits Parameter or
Called Party Number. The ESGW shall extract the callback number from the URI parameter in the
P-Asserted-Identity header and signal that number to the Selective Router as the Calling Party
Number/ANI.
6.5.4.4 Identifying a call instance
Please refer to IETF RFC 3261 for more details on identifying call instances [5].
6.5.5
v4 SIP Messages Examples
This section identifies what information is included in the headers exchanged in the SIP INVITE,
200 OK, and the SIP BYE messages over the v4 interface. The message sequence numbers refer to
steps identified in Figure 6-5.
Note: Location information (PIDF-LO) and credential information within the SIP messaging, as part
of a multipart MIME SIP message is retained. This means that parts can be used to authenticate,
inform, and direct, but these parts are not to be removed during the transference of SIP messaging.
The end result is that the v4 must support the inclusion of a PIDF-LO and associated credential
information within the subsequent SIP INVITE messages.
The following parameters have been used to construct the examples below:
Called number = 911

Callback number = 713-555-1234
Subscriber name = John Doe
VSP Provider = vsp.com
CS URI = callserver@vsp.com
ESGWRI = 713-111-2222
ESQK = 713-511-4321
Page 128 of 247

NENA 08-001 v2, August 11, 2010
ESGW Provider = esgwprovider.com

ESGW URI = gateway@esgwprovider.com
No RP or RS is involved in progressing the call.
Message 3: CS sends SIP INVITE to ESGW

INVITE sip:+17131112222@esgwprovider.com;user=phone SIP/2.0
Max-Forwards: 68
From: Anonymous <sip:+17135551234@vsp.com;user=phone>
P-Asserted-Identity: John Doe <sip:+17135114321@vsp.com;CBN=7135551234>
Call-ID: 123456789@vsp.com
Geolocation: <cid:7135551234@vsp.com>;inserted-by=7135551234@vsp.com
;recipient=endpoint
Accept: application/sdp, application/pkcs-mime
CSeq: 1 INVITE
Content-Length: 379
--simple boundary
Content-type: application/pkcs-mime
Content-ID: 7135551234@vsp.com
(Encrypted LO + From:URI message digest not shown)
--simple boundary
(SDP not shown)
--simple boundary
Page 129 of 247

NENA 08-001 v2, August 11, 2010
Message 7: ESGW sends SIP 200 OK to CS
SIP/2.0 200 OK
Via: SIP/2.0/UDP gateway@esgwprovider.com;branch=z9hG4bK4b43c2ff8.1
From: Anonymous <sip:+17135551234@vsp.com;user=phone>
CSeq: 1 INVITE
Contact: <sip:911@esgwprovider.com>
Content-Length: 148
(SDP not shown)
Message 13: CS sends SIP BYE to ESGW (caller-terminated call)

BYE sip:+17131112222@esgwprovider.com;user=phone SIP/2.0
From: <sip:+17135551234@vsp.com;user=phone>
CSeq: 1 BYE
Content-Length: 0
Max-Forwards: 69
ESGW sends SIP BYE to CS (PSAP-terminated call)

BYE sip:+17135551234@vsp.com SIP/2.0
Via: SIP/2.0/UDP gateway@esgwprovider.com;branch=z9hG4bK4b43c2ff8.1
From: <sip:7135114321@vsp.com>
To: <sip:+17135551234@vsp.com;user=phone>
CSeq: 1 BYE
Content-Length: 0
Max-Forwards: 69
Page 130 of 247

NENA 08-001 v2, August 11, 2010
6.5.6
Assumptions
1. The sip:uri user=token parameter has a token value equal to 'phone' to ensure existing gateway
support (the use of an alternative token value would likely require software changes in
various SIP based equipment).
2. The P-Asserted-Identity SIP header is used to specify the ESQK value, since the impact on
subsequent ESGW processing will be minimized.
3. Either ordering or qvalues (ref. RFC3261) will be used to distinguish execution priority of
multiple Contact headers.
4. The logging of the specific ESGW used for the call will be done within the VPC and conveyed
to the VPC using the 200 OK, then NOTIFY SIP messages.
5. The SIP 200 OK message from the ESGW will contain a Contact header, listing the IP address
or a valid URI of the ESGW utilized.
6.5.7
The v4 interface will operate in a variety of network environments, some trusted, and some not, as
described previously. The v4 interface should be used with a suitable security mechanism as defined
in Section 4. When the connection between the CS or RP and the ESGW is not on a trusted network,
both the CS/RP and ESGW are expected to be protected with IPsec or TLS, and thus require
certificates rooted in VESA. Even in a trusted network, TLS protection is advisable. Mutual
authentication is required when cryptographic security is deployed.
6.6
v5 Call Server/Proxy to Redirect Server
The v5 interface defines the communication protocol and behaviors between the CS and a RS
function using SIP, in response to an INVITE for the purpose of routing. In addition, the RS will
subscribe to the CS to be notified upon call termination. This section also describes v2 interface
interactions between the RS and the VPC as the method used by the RS to obtain routing
information from the VPC functional element 21.
6.6.1
Technical Description
As shown in Figure 6-6, the v5 interface exists between the CS and a RS. It provides a means for the
CS to request further emergency service routing information over SIP while retaining final routing to
the appropriate ESGW. The RS receives an INVITE method from the CS and interacts with the VPC
via the v2 interface to gather emergency call parameters. The RS then formats a 300 or 302
Response back to the CS with the emergency call parameters that are subsequently used by the CS to
select the appropriate ESGW to route the call to.
21 Some implementations may aggregate the RS and the VPC into one physical component internalizing the v2 interface.
Page 131 of 247

NENA 08-001 v2, August 11, 2010
Emergency Services
Provider Network
IP domain
Redirect Server
Call Server/
Proxy
v5
ESGW(s)
E9-1-1
Selective
Router(s)
v4
PSAP
v1
v2
VoIP
End
Point
SRDB
VPC
Figure 6-6 The v5 Interface
6.6.2
The following call flow shows a 9-1-1 call where the CS forwards the call to a RS to obtain
necessary 9-1-1 call routing information and then uses the received routing information to route the
call to the ESGW. Messages which pertain to the v5 interface are shown in bold red.
Page 132 of 247

NENA 08-001 v2, August 11, 2010
VEP
CS
RS
ESGW
VPC
1. INVITE
(911; PIDF-LO;
callid1; SDP1)
2. 100 Trying
3. INVITE
(callid1; PIDF-LO; customer; callback; SDP1)
4. 100 Trying
customer, callback)
7. 300 Multiple choices

(callid1; ert or esgwri; esqk; lro)
esgwri, esqk, lro)
8. ACK
9. INVITE
(callid1; esgwri; esqk; callback; PIDF-LO; SDP1)
10. 100 Trying
11. SUBSCRIBE
(callId1; timer)
12. 200 OK SUBSCRIBE
13. NOTIFY
(callid1;state; time left)
14. 200 OK NOTIFY
15. 183 Session Progress

(SDP2)
16. 183 Session Progress

(SDP2)
Early Media: Audible Ringing Delivered

18. 200 OK (SDP3)
19. ACK
17. 200 OK INVITE (SDP3)
20. ACK
RTP channels established

21. BYE
22. BYE
23. 200 OK
24. 200 OK
25. NOTIFY
(callid1; state; time left=0)
26. 200 OK NOTIFY
27. esct
(esqk, esgw, callId1)
29. SUBSCRIBE
(callId1; timer=0)
28. esctAck (callId1)
30. 200 OK SUBSCRIBE

31. NOTIFY
(callid1; state=terminated)
32. 200 OK NOTIFY
Figure 6-7 - v5 interface Call flow
Here is the detailed description of the procedure depicted in the figure above:
Page 133 of 247

NENA 08-001 v2, August 11, 2010
1. A caller invokes an emergency call dialing 9-1-1. The VEP sends a SIP INVITE to the CS
with location attached (shown as PIDF-LO) along with the SDP offer (shown as SDP1).
2. The CS responds with a SIP 100 Trying message to the VEP.
3. The CS sends an INVITE to the RS which includes location information in a PIDF-LO
document or a reference to a location, subscriber name and callback information.
4. The RS responds with a SIP 100 Trying message to the CS.
5. The RS uses the information received in the SIP INVITE to construct a v2 esrRequest to the
VPC.
6. The VPC queries the appropriate ERDB (step not shown) based on the location and
constructs a v2 esrResponse message back to the RS with routing instructions received from
the ERDB. There are two options for what the VPC returns to the RS, depending on the
arrangement in place with the RS:
a. The VPC holds ERT-to-ESGWRI mappings. Based on the ERT received from the ERDB,
the VPC allocates an ESQK, determines the routing number (ESGWRI) for the call, and
provides this information to the RS along with the LRO. In this case, the CS will use the
ESGWRI directly for route selection.
b. The CS holds ERT-to-ESGWRI mappings. Based on the ERT received from the ERDB,
the VPC allocates an ESQK for the call and provides the ESQK and the ERT information
to the RS along with the LRO. In this case, the CS will use internal ERT-to-ESGWRI
mappings to select the proper route.
7. The RS returns a SIP 300 22 response to the CS with the various routing options available.
8. A standard SIP ACK is returned to the RS to acknowledge receipt of the 3XX response.
9. If the CS received an ERT, it translates the ERT to an ESGWRI. The CS sends a SIP
INVITE to the ESGW with the SDP offer (shown as SDP1) and ESGWRI. The ESQK is
sent as an URI in a PAI header. The callback number is sent as a parameter in the same PAI
header.
10. The ESGW responds with a SIP 100 Trying message to the CS.
11. The RS also sends a SUBSCRIBE method to the CS so that it is notified when the call
disconnects.
12. The CS returns a 200 OK to acknowledge the SUBSCRIBE request.
13. The CS sends a NOTIFY to inform the RS of the current state of the call.
14. The RS responds with a SIP 200 OK message to the CS.
15. The call is delivered to the PSAP and the ESGW signals a SIP 183 Session Progress back to
the CS.
16. The CS forwards the SIP 183 Session Progress to the VEP.
A one-way media stream is established to facilitate the delivery of audible ringing to the VEP.
22
SIP 300 response is used as an example. A SIP 302 response could also be used.
Page 134 of 247

NENA 08-001 v2, August 11, 2010
17. The PSAP call taker answers the call and the offhook signal is conveyed to the ESGW. The
ESGW sends a SIP 200 OK message to the CS with its SDP answer (shown as SDP2).
18. The CS forwards the SIP 200 OK message with the ESGW SDP answer to the VEP.
19. The VEP returns a standard SIP ACK to the CS to acknowledge receipt of the SIP 200
response and acceptance of the SDP answer.
20. The CS forwards the SIP ACK to the ESGW to confirm acceptance of the SDP answer.
The media streams are established in both directions. The caller and the PSAP call taker can now
communicate.
21. Some time later, the call is released (the call may be terminated from either direction
however, in this example, the caller hangs-up first). The VEP sends a SIP BYE message to
the CS.
22. The CS forwards the SIP BYE to the ESGW.
23. The ESGW terminates the call to the SR and then confirms reception of the call termination
by sending back a SIP 200 OK message to the CS.
24. The CS forwards the SIP 200 OK message to the VEP.
25. The CS sends a SIP NOTIFY with the URI-ID and call-state of the caller to the RS.
26. The RS responds with a SIP 200 OK message acknowledging receipt of the call termination
state.
27. The RS constructs a v2 esct message and sends it to the VPC so it can release return the
ESQK to its pool.
28. The VPC responds with a v2 esctAck message back to the RS to acknowledge.
29. The RS sends another SIP SUBSCRIBE message to the CS to cancel the subscription to the
dialog.
30. The CS returns a SIP 200 OK message to acknowledge receipt.
31. The CS sends a last SIP NOTIFY to confirm the cancellation of the subscription.
The RS returns a SIP 200 OK message to acknowledge receipt.
6.6.3
6.6.3.1 v5 SIP INVITE Message

The v5 message originates as a normal SIP INVITE from the CS. Parameters provided by this
message will be used by the RS to construct the v2 esrRequest to be sent to the VPC for routing
instructions.
Parameter
vsp
Condition
Mandatory
SIP Header
Via
PIDF-LO
Conditional*
MIME body
Description
CS entity requesting routing
instructions.
Source of the Location
Page 135 of 247

NENA 08-001 v2, August 11, 2010
Callback
Conditional*
P-AssertedIdentity
Customer
Conditional*
P-AssertedIdentity
Information Element (LIE).

E.164 number that can be dialed
by a PSAP operator to reach the
call originator.
VSP subscriber name.
Table 6-8 v5 SIP INVITE Parameters 23
* Sent if present
vsp The identity of the VoIP Service Provider (CS). This is included in the Via header as part of
the URI.
PIDF-LO If included, it contains information on the callers location used to construct the LIE.
The PIDF-LO is included as a body within the SIP INVITE.
callback The callback number, determined by the VSP CS from subscription data, will be included
as a parameter in the P-Asserted-Identity header and expressed as an E.164 dialable and routable
number.
Customer The subscriber name, determined by the VSP CS from subscription data, will be
included in a P-Asserted-Identity header. When included, the subscriber name is expected to be of
the form John Doe. Aliases, nicknames and the like are not allowed.
6.6.3.2 v5 SIP 300/302 response
The SIP 300 or SIP 302 message response is sent from the RS to the CS Proxy in response to a SIP
INVITE message.This message is constructed from the routing information provided by the VPC in
the v2 esrResponse message. A subset of valid parameters sourced from the v2 esrResponse for the
SIP 300/302 response is contained in Table 6-9.
Parameter
Provider-ID
Condition
Mandatory
SIP Header
Via
esqk
esgwri
Conditional
Conditional
PAI
Contact
Description
Redirect Server responding
to INVITE.
Key allocated for the call.
Routing indicator used to
direct the call to the ESGW.
This parameter will be
present if the ESGWRI is
determined by the VPC.
This parameter will be
omitted if the ERT
23 This table contains a subset of the elements received in the v5 SIP INVITE message. Only the elements reused in the v2 interface
are described in this table. The v5 INVITE message will include all mandatory parameters described in RFC 3261.
Page 136 of 247

NENA 08-001 v2, August 11, 2010
Parameter
Condition
SIP Header
ert
Conditional
Contact
lro 24
Conditional
Contact
Description
parameter is present.
The routing tuple to be used
by the call server to
determine the ESGWRI. If
the ESGWRI is already
provided, then this field will
be omitted.
Contingency Routing
Number to be used for
fallback or returned for error
conditions (with no
ESGWRI or ERT/ESQK)
Table 6-9 v5 SIP 300 Response Parameter
Two possible cases are supported. The first (a) is when the VPC returns an ESGWRI. The second
(b), is when the VPC returns an ERT.
a) Once the RS has received the ESQK, ESGWRI, and LRO from the VPC, it formats and
sends a SIP 300 or SIP 302 response. Most of the headers received in the INVITE are echoed
back and two Contact headers are added. The Contact headers should be ordered such that
the first header contains ESGWRI/ESQK information and the second one contains the LRO
(included only if SIP 300 is used) for fallback. A qvalue parameter shall be added to each
line to explicitly provide ordering.
Contact header (first line) this header is added to the 3XX response. It contains the
ESGWRI and a PAI, containing the ESQK, Contact: <ESGWRI>;? P-AssertedIdentity:<ESQK>; q=#
Contact header (second line) - it contains the LRO, e.g., Contact: <LRO>;q=#. The LRO is
used by the CS/RP for contingency routing.
b) Once the RS has received the ESQK, ERT, and LRO from the VPC, it formats and sends a
SIP 300 or SIP 302 response. Most of the headers received in the INVITE are echoed back
and two Contact headers are added. The Contact headers should be ordered such that the
first header contains ERT/ESQK information and the second one contains the LRO (included
only if SIP 300 is used) for fallback. A qvalue parameter shall be added to each line to
explicitly provide ordering.
Contact header (first line) this header is added to the 3XX response. It contains the ERT
and a PAI, containing the ESQK, e.g., Contact: CLLI.ESN.NPA@<CS-Provider-ID>?PAsserted-Identity:<ESQK>; q=#;
24
lro is not included when SIP 302 message is used since the SIP 302 message allows only one
Contact header.
Page 137 of 247

NENA 08-001 v2, August 11, 2010
Contact header (second line) - it contains the LRO, e.g., Contact: <LRO>:qvalue=#. The
LRO is used by the CS/RP for contingency routing.
NOTE: The 300 response may just contain one Contact header with only the LRO. This is a valid
response and indicates that the VPC was unable to provide the ERT/ESQK or ESGWRI/ESQK. The
CS/RP would then use the LRO to route the call.
6.6.3.3 v5 SIP SUBSCRIBE/NOTIFY methods for Call Termination Reporting
To enable call termination reporting using existing SIP methods, emergency calls must include
subscription as part of the exchange with the RS. A SIP SUBSCRIBE method (defined in RFC 3265
[31] with a dialog event defined in RFC 4235 [51]) is sent from the RS to the CS following the SIP
300/SIP 302 response. This is to make the CS aware that notification should be sent upon
termination of the call. When the CS detects the call has completed, a SIP NOTIFY method (defined
in RFC 3265 [31]) is sent to the RS. The RS informs the VPC by sending an ESCT message over the
v2 interface (refer to Section 6.3), to enable the ESQK allocated for the call to be released and to
inform the VPC of the ESGW that was used.
6.6.3.3.1 Initiate Subscription to Call
As described above, following the 300/302 response from the RS, a SUBSCRIBE is sent from the
RS to the CS to convey that the RS desires to receive call state pertaining to this particular dialog
(the emergency call). The CS responds with a SIP NOTIFY to acknowledge receipt of the SIP
SUBSCRIBE. The tables below describe the messages involved in this initial exchange:
Parameter
Provider-ID
FROM
Condition
Mandatory
Mandatory
SIP Header
Via
From
Package
Mandatory
Event
Timer
Manadatory
Expires
Description
The identifier of the RS.
RS URI and tag associated with the
subscription
Identify type of event being
subscribed to and the call-id value
associated with this subscription
On initial subscription this value is
set to the ESQK timeout value (8
hours).
Table 6-10 v5 SIP SUBSCRIBE (Initial subscription)
Parameter
Provider-ID
URI-ID
Condition
Mandatory
Mandatory
SIP Header
Via
From
State
Mandatory
Subscription-
Description
Contains CS URI
URI of the caller sent in the From
header.
Status of the call is active.
Page 138 of 247

NENA 08-001 v2, August 11, 2010
Parameter
Condition
Dialog-content
SIP Header
State
Content-Type:
dialog-info
Description
Dialog package refer to call flow
examples. Provides the entity
(caller URI-ID), state=current value,
call-Id of this particular leg of the
call, and tag.
Table 6-11 v5 SIP NOTIFY (Ack from CS)
6.6.3.3.2 Call Terminates

When the call ends, either at the caller or Emergency services end, the RS gets notified that the call
has completed. The table below shows the parameters in the NOTIFY when the call completes.
Parameter
Provider-ID
URI-ID
Condition
Mandatory
Mandatory
SIP Header
Via
From
State
Mandatory
SubscriptionState
Content-Type:
dialog-info
Dialog-content
Description
Contains CS URI
header. URI associated with ESQK
for the call.
Status of the subscription is active
Dialog package refer to call flow
examples. Provides the entity
(caller URI-ID), call-Id of this
particular leg of the call,
state=terminated, and tag.
Table 6-12 NOTIFY (CS to RS on Termination)
6.6.3.3.3 Final Exchange to Confirm

This exchange is necessary to notify the CS that the subscription is over. The CS could indicate the
call is over without the need of this final exchange if the CS supports setting the Subscription-state
value to terminated, and then closes the subscription, making it unnecessary for the RS to send this
exchange as defined below:
Parameter
Provider-ID
FROM
Condition
Mandatory
Mandatory
SIP Header
Via
From
Package
Mandatory
Event
Timer
Manadatory
Expires
Description
The identifier of the RS.
RS URI and tag associated with the
subscription
Identify type of event being
subscribed to and the call-id value
associated with this subscription
0 indicates the subscription is over
Page 139 of 247

NENA 08-001 v2, August 11, 2010
Table 6-13 SUBSCRIBE (Final Confirmation)
Parameter
Provider-ID
URI-ID
Condition
Mandatory
Mandatory
SIP Header
Via
From
Description
Contains CS URI
header. URI associated with ESQK
for the call.
Status of the call is active
State
Mandatory
Dialog-content
Mandatory
Length
Mandatory
SubscriptionState
Content-Type: No content
dialog-info
Content-Length 0 means no content
Table 6-14 NOTIFY (Ack from CS for final Confirm)
6.6.4
Specification of the v5 Interface
6.6.4.1 Transport of SIP-based v5 interface

UDP will be the default transport mechanism for the v5 interface with port 5060.
TCP will be used as alternative transport with port 5060.
TLS (SIPS) over TCP transport, with port 5061, should be used where public access is required.
The implementation of the v5 interface shall support SIP methods and responses documented in this
document, and as defined in RFC 3261 [5] for redirection behaviors. It must also support SIP
SUBSCRIBE/NOTIFY methods and responses as defined in RFC 3265 [31] and draft-ietf-sipcorelocation-conveyance [12] for location conveyance.
6.6.4.2.1 v5 SIP INVITE Message from the CS to the RS
The SIP INVITE message received from the CS should be constructed as follows:
Page 140 of 247

NENA 08-001 v2, August 11, 2010
INVITE sips:911@RS-UA Provider-ID SIP/2.0

Via: SIP/2.0 /TCP CS-Provider-ID;branch=z9hG4bKrandomstuff1
To: 911 <sips:911@RS-UA-Provider-ID.com>
From: CgPN <sip: URI-ID@vsp.com>;tag=AE32SS
P-Asserted-Identity: subscriber <sip:URI-ID@vsp.com;CBN=callback;user=phone>
Call-ID: Call-Idvalue-1
Geolocation: <cid:URI-ID@vsp.com>;inserted-by=URI-ID@vsp.com;recipient=endpoint
CSeq: 1 INVITE
--simple boundary
Content-ID: URI-ID@vsp.com
(PIDF-LO not shown)
--simple boundary
Content-type: application/sdp
(SDP not shown)
--simple boundary
6.6.4.2.2 v5 SIP 300 Multiple Choices Response

SIP 300 Multiple Choice Response is used an example in this section. The RS response to the SIP
INVITE from the CS should be constructed as follows:
SIP/2.0 300 Multiple Choices
Via: SIP/2.0/TCP CS-Provider-ID;branch=z9hG4bKrandomstuff1
To: 911 <sips:911@RS-UA-Provider-ID.com>
From: URI-ID <sip:URI-ID@myvsp.com>;tag=A-value
CSeq: theCSeqvalue1 INVITE
Contact: <sips:routingInfo@CS-Provider-ID?P-Asserted-Identity:
=<sips:+1-ESQK@RS-Provider-ID;user=phone>>;q=1
Contact: <sips:+1-LRO@CS-Provider-ID;user=phone>;q=2
Note: The routingInfo parameter can be expressed as a 10-digit ESGWRI or an alphanumeric

ERT.
Page 141 of 247

NENA 08-001 v2, August 11, 2010
6.6.4.2.3 v5 SIP SUBSCRIBE Message for Subscription Request
The RS requires to be informed of the state of the call in progress. A SIP SUBSCRIBE message is
sent to the CS immediately after the SIP 300 response to request notification of the call state. This
message should be constructed as follows (all values used are for illustrative purposes only):
SUBSCRIBE CS-Provider-ID SIP/2.0
Via: SIP/2.0/TCP RS-UA-Provider-ID;branchz9hG4bKrandomstuff3
Call-ID: Call-Idvalue2
To: <sip:URI-ID@myvsp.com>
From: RS-UA-Provider-ID;tag=RS-1234
Cseq: 12121 SUBSCRIBE
Event: dialog; call-id=Call-Idvalue1;from-tag=AE32SS
Expires: 3600
Note: The ESQK timer value is initially set to 8 hours.

6.6.4.2.4 v5 SIP NOTIFY Message for Subscription Confirmation
The CS acknowledges the subscription request by responding with a SIP NOTIFY message carrying
the actual state of the call. This message should be constructed as follows:
NOTIFY sips:RS-UA-Provider-ID SIP/2.0
Via: SIP/2.0/TCP CS-Provider-ID;branchz9hG4bKrandomstuff4
To: CS- Provider-ID;branch=z9hG4bKrandomstuff4
From: <sip:URI-ID@myvsp.com>;from-tag3
Cseq: 1 NOTIFY
Event: dialog
Subscription-State: active;expires=3599
Content-Type: dialog-info
Content-Length:261
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0"
state="full"
entity=":URI-ID@myvsp.com> <dialog id="as7d900as8" call-id="Call-Idvalue1"
local-tag="RS1234" direction="initiator">
<state>active</state>
</dialog>
</dialog-info>
Note: The state of the call immediately after the subscription is active.
Page 142 of 247

NENA 08-001 v2, August 11, 2010
6.6.4.2.5 v5 SIP NOTIFY for Call Termination
Once the call terminates, the CS informs the RS by sending a SIP NOTIFY message with the new
call state (terminated). This message should be constructed as follows:
NOTIFY sips: RS-UA-Provider-ID SIP/2.0
Call-ID: Call-IDValue2
To: cs3.myvsp.com
Cseq: 1 NOTIFY
Event: dialog
Content-Length: 268
version="2"
state="full"
entity=":URI-ID@myvsp.com> <dialog id="as7d900as8" call-id=" CallIDValue1"
local-tag="RS-1234" direction="initiator">
<state>terminated</state>
</dialog>
</dialog-info>
Note: Call termination is signaled by setting the <state> parameter to terminated.

6.6.4.2.6 v5 SIP SUBSCRIBE for Subsciption Termination
The RS completes the subscription dialog by sending a new SIP SUBSCRIBE message to the CS
identifying termination of the subscription for this call. This message should be constructed as
follows:
SUBSCRIBE CS-Provider-ID SIP/2.0
Via: SIP/2.0 /TCP RS-UA-Provider-ID;branchz9hG4bKrandomstuff3
To: <sip:URI-ID@myvsp.com>
From: RS-UA-Provider-ID;tag=RS-1234
Event: dialog; call-id=Call-Idvalue1;from-tag=AE32SS
Expires: 0
Note: Termination of the subscription is signaled by setting the Expires parameter to 0.

Page 143 of 247

NENA 08-001 v2, August 11, 2010
6.6.4.2.7 v5 SIP NOTIFY for Subscription Termination Confirmation
The CS confirms termination of the subscription by sending a SIP NOTIFY message to the RS. This
message should be constructed as follows:
NOTIFY sips: RS-UA-Provider-ID SIP/2.0
Via: SIP/2.0/TCP CS-Provider-ID;branchz9hG4bKrandomstuff4
To: CS-Provider-ID;branch=z9hG4bKrandomstuff4
Cseq: 1 NOTIFY
Event: dialog
Subscription-State: terminated;expires=0
Content-Length: 0
Note: The termination of the subscription for a particular call is signaled by setting the
Subscription-State header to Terminated.
6.6.5
SIP Exchange Example
This section identifies what information is included in the SIP headers exchanged between the CS
requesting emergency call routing instructions and RS. The message sequence numbers refer to steps
identified in Figure 6-7. Not all message examples are provided.
Called number = 911

Callers anonymous URI = sip:fhdoweww34@vsp.com
Subscriber name = John Doe
CS URI = callServer@vsp.com
RS Provider = rsprovider.com
RS Provider URI = rs-ua@rsprovider.com
ESGWRI = 713-111-2222
ERT = CTONPQ14DS2.54639.713
ESQK = 713-511-4321
LRO = 800-555-3434
Page 144 of 247

NENA 08-001 v2, August 11, 2010
Message 3: CS sends SIP INVITE to RS for further routing instructions
INVITE sips:rs-ua@rsprovider.com SIP/2.0
Via: SIP/2.0/TCP callServer@vsp.com ;branch=z9hG4bKrandomstuff1
To: 911 <sips:911@vsp.com;user=phone>
From: anonymous <sip:fhdoweww34@vsp.com>;tag=afrt4
P-Asserted-Identity: John Doe <sip:+17135551234@vsp.com;user=phone>
Geolocation: <cid:fhdoweww34@vsp.com>;inserted-by=fhdoweww34@vsp.com
;recipient=endpoint
CSeq: 1 INVITE
Content-Length: 234
--simple boundary
Content-ID: fhdoweww34@vsp.com
(PIDF-LO not shown)
--simple boundary
(SDP not shown)
--simple boundary
Message 7a: RS responds to CS with a SIP 300 Multiple Choices message using ESGWRI
Via: SIP/2.0/TCP callServer@vsp.com;branch=z9hG4bKrandomstuff1
To: 911 <sips:911@vsp.com;user=phone>
From: Anonymous <sip:fhdoweww34@vsp.com>;tag=afrt4
CSeq:2 INVITE
Contact: <sips:+17131112222@vsp.com?P-Asserted-Identity:=<sips:+17135114321@vsp.com;user=phone>?>
Contact: <sips:+1-8005553434@vsp.com;user=phone>
Page 145 of 247

NENA 08-001 v2, August 11, 2010
Message 7b: RS responds to CS with a SIP 300 Multiple Choices message using ERT
To: 911 <sips:911@vsp.com >
CSeq: 2 INVITE
Contact: <sips:CTONPQ14DS2.54639.713@rsprovider.com?P-AssertedIdentity:=<sips:+1-7135114321@vsp.com;user=phone>?>
Contact: <sips:+1-8005553434@vsp.com;user=phone>
The ERT is constructed as CLLI.ESN.NPA where the CLLI is set to the destination SR; the ESN is
set to the ESN for the location; the NPA is set to an appropriate value for the trunk group to the SR.
Message 9: CS sends SIP INVITE to ESGW over v4 Interface
INVITE sips:+17131112222@esgwprovider.com SIP/2.0
Via: SIP/2.0/TCP rs-ua@rsprovider.com;branch= 12356sssss98 _
To: 911 <sip:911@vsp.com;user=phone>
P-Asserted-Identity:<sip:+17135114321@vsp.com;user=phone;CBN=7135551234>
Accept: application/sdp
CSeq: 1 INVITE
Content-Length: 234
(SDP not shown)
Page 146 of 247

NENA 08-001 v2, August 11, 2010
Message 11: RS send a SIP SUBSCRIBE method to CS
SUBSCRIBE callServer@vsp.com SIP/2.0
Via: SIP/2.0/TCP rs-ua@rsprovider.com;branchz9hG4bKrandomstuff3
Call-ID: hesdr39532@rsprovider.com
To: <sip:fhdoweww34@vsp.com>
From: rs-ua@rsprovider.com;tag=RS1234
Event: dialog; call-id=123456789@vsp.com;from-tag=afrt4
Expires: 28800
Message 12 (200 OK) not shown

Message 13: CS immediately sends a SIP NOTIFY to RS with current state
NOTIFY sips:rs-ua@rsprovider.com SIP/2.0
Via: SIP/2.0/TCP callServer@vsp.com;branchz9hG4bKrandomstuff4
To: callServer@vsp.com;branch=z9hG4bKrandomstuff4;tag=RS1234
From: <sip:fhdoweww34@vsp.com>;tag=hewp41
Cseq: 12121 NOTIFY
Event: dialog
Content-Length: <body-length>
version="0"
state="full"
entity=":sip:fhdoweww34@vsp.com> <dialog id="as7d900as8"
call-id="123456789@vsp.com"
local-tag="RS1234" direction="initiator">
<state>active</state>
</dialog>
</dialog-info>
Page 147 of 247

NENA 08-001 v2, August 11, 2010
Message 25: CS sends a SIP NOTIFYto RS to signal call termination
From: <sip:URI-ID@myvsp.com>;tag=hewp41
Cseq: 12121 NOTIFY
Event: dialog
Content-Length: <body-length>
version="2"
state="full"
entity=": sip:fhdoweww34@vsp.com> <dialog id="as7d900as8"
call-id="123456789@vsp.com"
local-tag=" RS-1234" direction="initiator">
<state>terminated</state>
</dialog>
</dialog-info>
NOTE: The call server may send the redirect server several NOTIFY messages communicating state
changes of the dialog. The redirect server will ignore all notifications except the termination
notification.
NOTE: Termination can come from the VEP as well, same result.
Message 29: RS terminates the subscription
SUBSCRIBE callServer@vsp.com SIP/2.0
Via: SIP/2.0/TCP rs-ua@rsprovider.com;branchz9hG4bKrandomstuff3
To: <sip:fhdoweww34@vsp.com>
From: rs-ua@rsprovider.com;tag=RS1234
Event: dialog; call-id=123456789@vsp.com;from-tag=afrt4
Expires: 0
Page 148 of 247

NENA 08-001 v2, August 11, 2010
Message 31: CS sends a SIP NOTIFY to RS confirming completion of subscription
Via: SIP/2.0/TCP callServer@vsp.com;branchz9hG4bKrandomstuff4
From: <sip:fhdoweww34@vsp.com>;tag=hewp41
Cseq: 1 NOTIFY
Event: dialog
Subscription-State: terminated;expires=0
Content-Length: 0
NOTE: If the CS sends a NOTIFY that indicates that the call is over, the CS can set the
Subscription-state value to terminated, and that closes the subscription, making it unnecessary for
the RS to send another SUBSCRIBE with expires=0.
6.6.6
v5 Security Requirements
not, as described previously. v5 is a SIP interface and should be used with a suitable security
mechanism as defined in Section 4. When the connection between the Call Server and the Redirect
Server is not a trusted network, both the Call Server and Redirect Server are expected to be protected
with IPSEC or TLS, and thus require a certificates rooted in VESA. Even in a trusted network, TLS
protection is advisable. Mutual authentication is required when cryptographic security is deployed.
6.7
v6 Call Server to Routing Proxy Interface
The v6 interface is defined as a SIP interface from a CS to a 9-1-1 RP. This interface is used where
the CS desires to unconditionally route all emergency calls to an entity that will both determine the
route and forward the call to the correct ESGW. The CS does not need to remain in the call setup
path (it is however expected to remain in the end-to-end signaling path).
6.7.1
v6 Interface Architecture
As shown in Figure 6-8, this implementation of a VoIP emergency call network incorporates a 9-1-1
RP to which all emergency calls are forwarded. The v6 interface is the SIP messaging between the
CS and the RP. The RP then contacts the VPC (using the v2 interface) to obtain the ESGWRI or
ERT, and ESQK, and forwards the call to the appropriate ESGW. In the case when the ERT is
obtained from the VPC, the Routing Proxy is responsible for translating the ERT to the appropriate
ESGWRI and then forwarding the call with the ESGWRI to the correct ESGW..
Page 149 of 247

NENA 08-001 v2, August 11, 2010
Emergency Services
Provider Network
IP domain
Routing Proxy
Call Server/
Proxy
v6
v4
v1
VoIP
End
Point
ESGW(s)
E9-1-1
Selective
Router(s)
PSAP
v2
SRDB
VPC
Figure 6-8 v6 Interface Architecture
6.7.2
The following call flow represents a typical 9-1-1 call where the CS utilizes a RP which has a
connection to a VPC. All necessary call information is passed to the Routing Proxy using a SIP
INVITE. After the proper route is determined by the VPC using the v2 interface, the RP routes the
call to the appropriate ESGW via the v4 interface. Messages which pertain to the v6 interface are
shown in bold red.
Page 150 of 247

NENA 08-001 v2, August 11, 2010
Figure 6-9 V6 interface Call Flow
Page 151 of 247

NENA 08-001 v2, August 11, 2010
1. A caller invokes an emergency call dialing 9-1-1. The VEP sends a SIP INVITE to the CS
with location attached (shown as PIDF-LO) along with the SDP offer (shown as SDP1).
3. The CS sends an INVITE to the RP which includes location information in a PIDF-LO
document, subscriber name and callback information communicated in a PAI header.
4. The RP responds with a SIP 100 Trying message to the CS.
5. The RP uses the information received in the SIP INVITE to construct a v2 esrRequest to the
VPC.
constructs a v2 esrResponse message back to the RP with routing instructions received from
the ERDB. There are two options for what the VPC returns to the RP, depending on the
arrangement in place with the RP:
provides this information to the RP along with the LRO. In this case, the RP will use the
ESGWRI directly for route selection.
b. The RP holds ERT-to-ESGWRI mappings. Based on the ERT received from the ERDB,
to the RP along with the LRO. In this case, the RP will use internal ERT-to-ESGWRI
7. The RP sends a SIP INVITE with the SDP offer (shown as SDP1) to the ESGW to set up the
call to the SR using the ESGWRI received to determine the appropriate ESGW. The ESQK is
sent as an URI in a PAI header. The callback number is sent as a parameter in the same PAI
header.
8. The ESGW responds with a SIP 100 Trying message to the RP.
9. The call is offered to the PSAP and the ESGW signals a SIP 183 Session Progress back to the
RP.
10. The RP propagates the SIP 183 Session Progress to the CS.
11. The CS propagates the SIP 183 Session Progress to the VEP.
A one-way media stream is established so that audible ringing can be delivered to the VEP.
12. The PSAP call taker answers the call and the offhook signal is conveyed up to the ESGW.
The ESGW sends a SIP 200 OK message to the RP with its SDP offer (shown as SDP2).
13. The RP propagates the SIP 200 OK to the CS with the ESGW SDP offer.
14. The CS forwards the SIP 200 OK message with the ESGW SDP offer to the VEP.
response and acceptance of the SDP offer.
16. The CS forwards the SIP ACK to the RP to confirm acceptance of the SDP offer.
17. The RP forwards the SIP ACK to the ESGW to confirm acceptance of the SDP offer.
Page 152 of 247

NENA 08-001 v2, August 11, 2010
A two-way media stream is established. The caller and the PSAP call taker can now communicate.
18. Some time later, the call is released. (The call may be terminated from either direction
however, in this example, the caller hangs-up first). The VEP sends a SIP BYE message to
the CS.
19. The CS forwards the SIP BYE to the RP.
20. The RP forwards the SIP BYE to the ESGW.
21. The ESGW confirms reception of the call termination by sending back a SIP 200 OK
message to the RP. It then conveys the call state to the SR (not shown).
22. The RP forwards the SIP 200 OK message to the CS.
23. The CS forwards the SIP 200 OK message to the VEP.
24. The RP constructs a v2 esct message and sends it to the VPC so it can release return the
ESQK to its pool.
25. The VPC responds with a v2 esctAck message back to the RP to acknowledge.
6.7.3
6.7.3.1 v6 Sending of SIP INVITE Message

This message is identified in step 3 of Figure 6-9. It originates as a SIP INVITE from the CS to the
RP. Valid parameters for this message are included in the following table.
Table 6-15 - v6 SIP INVITE Parameters
Parameter
Condition
SIP Header
vsp
Mandatory
Via
PIDF-LO
Conditional*
MIME body
callback
Conditional*
P-asserted-Identity
customer
Conditional*
* Sent if present.
P-asserted-Identity
Description
The identifier of the VoIP Service Provider
(VSP).
Source for the Location Information
Element.
E.164 number that can be dialed by a
PSAP operator to reach the call originator.
Subscriber name.
vsp The identity of the VoIP Service Provider (CS). This is included in the Via header as part of
the URI.
PIDF-LO If included, it contains information on the callers location used to construct the LIE.
The PIDF-LO is included as a body within the SIP INVITE.
Callback The callback number, determined by the VSP CS from subscription data, will be
included in the P-Asserted-Identity header and expressed as an E.164 dialable and routable number.
Page 153 of 247

NENA 08-001 v2, August 11, 2010
Customer The subscriber name, determined by the VSP CS from subscription data, will be
included in a P-Asserted-Identity header. When included, the subscriber name is expected to be of
the form John Doe. Aliases, nicknames and the like are not allowed.
6.7.4
Specification of the v6 interface
6.7.4.1 Transport of SIP based V6 interface

UDP will be the default transport mechanism for the v6 interface with port 5060.
TCP will be used as alternative transport with port 5060.
TLS (SIPS) over TCP transport, with port 5061, should be used if possible.
The implementation of v6 interface shall support the SIP methods and responses documented in this
document and RFC 3261 [5] and in draft-ietf-sipcore-location-conveyance [12].
6.7.4.2.1 v6 SIP INVITE Message to RP
The SIP INVITE message received from the CS should be constructed as follows:
Page 154 of 247

NENA 08-001 v2, August 11, 2010
INVITE sips:911@RP-UA.Provider-ID.net SIP/2.0

Record-Route: <sips:CS-Provider-ID;lr>
To: 911 <sips:911@RP-UA-Provider-ID.com>
From: CgPN <sip:URI-ID@vsp.com>;tag=value
P-Asserted-Identity: customer <sip:callback@vsp.ca;user=phone>
Geolocation: <cid:URI-ID@vsp.ca>;inserted-by=URI-ID@vsp.ca;recipient=endpoint
CSeq: 1 INVITE
--simple boundary
Content-ID: URI-ID@vsp.ca
(PIDF-LO not shown)
--simple boundary
(SDP not shown)
--simple boundary
6.7.5
v6 SIP Message Examples
This section identifies information included in SIP headers exchanged between the CS and the
Routing Server. The message sequence numbers refer to steps identified in Figure 6-9. Not all
message examples are provided.
Called number = 911

Callers URI = sip:joeblack@vsp.com
Subscriber name = Joe Black
CS URI = callServer@vsp.com
RP Provider = rpprovider.com
RP Provider URI = rp-ua@rpprovider.com
ESGWRI = 713-111-2222
ERT = CTONPQ14DS2.54639.713
ESQK = 713-511-4321
Page 155 of 247

NENA 08-001 v2, August 11, 2010
LRO = 800-555-3434
Message 3: CS sends SIP INVITE to RP
INVITE sips:rp-ua@rsprovider.com SIP/2.0
Via: SIP/2.0/TCP callServer@vsp.com ;branch=z9hG4bKrandomstuff1
Record-Route: <sips:callServer@vsp.com;lr>
To: 911 <sips:911@vsp.com>
From: Joe <sip:joeblack@vsp.com>;tag=afrt4
P-Asserted-Identity: Joe Black <sip:+7135554321@vsp.com;user=phone>
Geolocation: <cid:7135554321@vsp.com>;inserted-by=7135554321@vsp.com
;recipient=endpoint
CSeq: 1 INVITE
Content-Length: 234
--simple boundary
Content-ID: 7135554321@vsp.com
(PIDF-LO not shown)
--simple boundary
(SDP not shown)
--simple boundary
Page 156 of 247

NENA 08-001 v2, August 11, 2010
Message 7: RP sends SIP INVITE to ESGW over v4 Interface
INVITE sips:+17131112222@esgwprovider.com SIP/2.0
Via: SIP/2.0/TCP rp-ua@rpprovider.com;branch=z9hG4bKrandomstuff2
Record-Route: <sips:rp-ua@rpprovider.com;lr>
To: 911 <sip:911@vsp.com>
From: Joe <sip:joeblack@vsp.com>;tag=afrt4
P-Asserted-Identity: <sip:+17135114321@vsp.com;user=phone;CBN=7135554321>
Accept: application/sdp,
CSeq: 1 INVITE
Content-Type: sdp;
Content-Length: 234
(SDP not shown)
Message 12 and 13 (200 OK) not shown

Message 19: CS sends SIP BYE to RP
BYE sip:+7131112222@rpprovider.com;user=phone SIP/2.0
Via: SIP/2.0/TCP callserver@vsp.com;branch=z9hG4bK4b43c2ff8.1
From: <sip:joeblack@vsp.com>;tag=afrt4
CSeq: 1 BYE
Content-Length: 0
Max-Forwards: 69
6.7.6
not as described in previously. V6 is a SIP interface and should be used with a suitable security
mechanism as defined in Section 4. When the connection between the Call Server and the Routing
Proxy Server is not a trusted network, both the Call Server and Routing Proxy Server are expected to
be protected with IPsec or TLS, and thus require a certificates rooted in VESA. Even in a trusted
network, TLS protection is advisable. Mutual authentication is required when cryptographic security
is deployed.
Page 157 of 247

NENA 08-001 v2, August 11, 2010
6.7.7
v6 Interface Assumptions
When a 9-1-1 Proxy Server control model implementation is used, the 9-1-1 ProxyServer will be
interconnected to the VPC via the v2 interface or the equivalent messaging set.
6.8
v7 LIS to VDB
This section describes the v7 interface between the LIS and the VDB. The LIS shall use this
capability to verify that an address is MSAG-valid, ensuring that civic addresses maintained in the
LIS are and remain routable in the legacy 9-1-1 infrastructure.
The v7 interface supports validation requests for one civic address at a time as records are added,
modified, or re-validated. In this case, the LIS shall use this protocol to send web service calls to the
appropriate VDB(s).
6.8.1
v7 Message Definitions
The v7 interface is made up of a query-response message pair. The first message is sent from the LIS
to the VDB requesting location information to be validated against the MSAG. The second message
is sent from the VDB to the LIS in response to this request. The remainder of this section details the
2 messages that make up communication across the v7 interface.
6.8.1.1 v7 Request for Address Validation (validateAddressRequest)
The validateAddressRequest message between a LIS and a VDB requests validation of a civic
address against the MSAG. The valid parameters for this message are included in the following
table.
Table 6-16 v7 validateAddressRequest Parameters
Parameter
MessageID
Condition
Optional
CustomerID
Optional
StreetAddress
StreetName
MSAGCommunity*
PostalCommunity*
StateProvince
Country
PrefixDirectional
StreetSuffix
Mandatory
Mandatory
Conditional
Conditional
Mandatory
Mandatory
Optional
Optional
PostDirectional
CountyName
Optional
Optional
Description
Optional parameter that the LIS may provide. If available
in the request, the value is echoed back in the response.
This value is optionally assigned by the VDB to the LIS
and represents a unique client for that VDB.
Data container for the civic address.
Name of the street without suffix and prefix.
Valid service community name as found in the MSAG.
Name of the community as found in the postal guide.
Name of the state (U.S.) or province/territories (Canada).
Country identifier as per ISO-3166-1.
Leading street direction suffix (NSEW).
Valid street abbreviation as defined in the postal guide
(e.g., AVE).
Trailing street direction suffix (N,S,E,W).
Name of the county.
Page 158 of 247

NENA 08-001 v2, August 11, 2010
Parameter
CountyID
Condition
Optional
PostalCode
HouseNum
HouseNumSuffix
Optional
Optional
Optional
Description
County identification code (usually the FIPS code for the
U.S.).
Postal code as per postal guide.
Civic number.
Civic number extension (e.g. 1/2, A).
* MSAGCommunity or PostalCommunity or both must be present.

All mandatory elements must be provided in the request. The optional elements may be present in
the request.
It is recommended that v7 clients submit addresses using only country-specific postal service
abbreviations. However, v7 clients may submit addresses using any non postal service abbreviations.
The <MessageID> element uniquely identifies the request at the originating node and may be
provided by the LIS. If so, the VDB will echo it back in the response. The format is as follows:
<MessageID>character string</MessageID>
The <CustomerID> element contains an identifier that a VDB operator has assigned to uniquely
identify a client. If available, the LIS should provide it in the request. This parameter is optional and
the format is as follows:
<CustomerID>character string</CustomerID>
The <StreetAddress> element contains sub-elements defining the civic address. The format is as
follows:
<StreeAddress>
<HouseNum>civic number</HouseNum>
<HouseNumSuffix>number suffix</HouseNumSuffix>
<PrefixDirectional>direction</PrefixDirectional>
<StreetName>name of the street</StreetName>
<StreetSuffix>suffix</StreetSuffix>
<PostDirectional>direction</PostDirectional>
<PostalCommunity>postal name of cummunity</PostalCommunity>
<MSAGCommunity>MSAG community name</MSAGCommunity>
<CountyName>name of the county</CountyName>
<CountyID>FIPS code</CountyID>
<StateProvince>state or province code</StateProvince>
<PostalCode>zip or postal code</PostalCode>
<Country>country code</Country>
</StreetAddress>
Page 159 of 247

NENA 08-001 v2, August 11, 2010
6.8.1.1.1 v7 validateAddressRequest Example
The following represents a validation request example where only the mandated address fields are
provided.
<validateAddressRequest xmlns=urn:nena:xml:ns:es:V7>
<MessageID>78801FA048D4226E4787F955</MessageID>
<CustomerID>vdbprovider24769854</CustomerID>
<StreetAddress>
<StreetName>LAVACA</StreetName>
<PostalCommunity>AUSTIN</PostalCommunity>
<StateProvince>TX</StateProvince>
<Country>US</Country>
</StreetAddress>
</validateAddressRequest>
6.8.1.2 v7 Validation Response (validateAddressResponse)

The validateAddressResponse provides a Return Code showing Success or Error. It also returns a
Valid field that shows whether the submitted address yielded an MSAG-valid entry or not. It
contains an array of street addresses that contains a single address (for Success) or one to n (n to be
determined by the VDB operator) addresses (for failures if any n possible matches were found).
The valid parameters for this message are included in the following table.
Table 6-17 v7 validateAddressResponse Parameters
Parameter
MessageID
Condition
Optional
ReturnCode
Mandatory
Valid
Mandatory
AddressList
Conditional
Description
Parameter that the LIS may provide. If available in the
request, the value is echoed back in the response.
Code defining the outcome of the request. See Table
6-18 for the defined values.
Defines whether the requested address yielded an
MSAG-valid address. Values are Valid, Invalid and
na.
Container for the list of addresses the VDB was able to
select based on the available address criterion.
The <MessageID> element uniquely identifies the request at the originating node and may be
provided by the LIS. If so, the VDB will echo it back in the response. The format is as follows:
<MessageID>character string</MessageID>
Page 160 of 247

NENA 08-001 v2, August 11, 2010
The <ReturnCode> element contains a return code characterizing the outcome of the validation
process at the VDB. Valid return codes are listed in Table 6-18 below. The format is as follows:
<ReturnCode>return code</ReturnCode>
Any <AddressList> elements present, contain one civic address, along with an optional
corresponding geodetic position. Multiple <AddressList> elements, if present, have an ordered
sequence, from best match to worst match. The format is as follows:
<AddressList>
<Civic>
<HouseNum>civic number</HouseNum>
<HouseNumSuffix>number suffix</HouseNumSuffix>
<PrefixDirectional>direction</PrefixDirectional>
<StreetName>name of the street</StreetName>
<StreetSuffix>street suffix</StreetSuffix>
<PostDirectional>direction</PostDirectional>
<PostalCommunity>postal name of cummunity</PostalCommunity>
<MSAGCommunity>MSAG community name</MSAGCommunity>
<CountyName>name of the county</CountyName>
<CountyID>FIPS code</CountyID>
<StateProvince>state or province code</StateProvince>
<PostalCode>zip or postal code</PostalCode>
<Country>country code</Country>
</Civic>
<GeoPosition>
<Latitude>latitude</Latitude>
<Longitude>longitude</Longitude>
<Elevation>elevation<Elevation>
</GeoPosition>
</AddressList>
<AddressList>
<Civic>
...
</Civic>
..<GeoPosition>
...
</Geoposition>
</AddressList>
When the Return Code 210 = Success Address Translated (location is MSAG-valid but address
was modified) is supplied, the VDB shall include the modified information in the response message.
For example, if submitted AV is changed to AVE in order to validate, or if John Carpenter Freeway
is submitted and changed to Hwy 144, the modified value is used in the StreetAddress included in
the AddressList of the response message.
Page 161 of 247

NENA 08-001 v2, August 11, 2010
There will be no Addresses returned if the input address fails validation and no alternative addresses
are found.
The VDB shall return the postal address, MSAG community name, information as to whether the
address is valid and optionally, the geo-code of the address when the validation succeeds. The VDB
may return MSAG County ID (if it is present in the MSAG).
The VDB shall return suggested alternate postal address(es) when the validation fails (if alternates
exist).
The VDB shall return addresses using only country-specific postal service street suffix abbreviations
and directional abbreviations in the appropriate fields.
When MSAG community and postal community names are both present in the request, the VDB
shall first use MSAG community name to search its database. If a match is not found using the
MSAG community name, it shall then use the postal community name.
When only one community name is present in the request, the VDB shall use that information to
search its database.
If a single match for the submitted address is found, the VDB shall return a Valid condition with
ReturnCode 200 and the data from the database search.
If no match is found and the VDB is searching using the postal community name, the VDB shall
lookup the MSAG community name from a postal-to-MSAG translation table. If a translation value
is found, the VDB shall search the database with the translated community name. If a single match is
found, the VDB shall return a Valid condition with ReturnCode 210 and the data from the VDB
search.
If the preceding searches have not found a match, the VDB may use other search mechanisms to find
likely matches for the address. Some alternate methods are:
return where HouseNum = <input house num>, StreetName sounds (e.g. soundex algorithm) like
<input street name>, State = <input state> and Zip = <input zip> or,
Search for alternate spellings for StreetName and Abbreviations in a translation table.
In this case, if any matches are found, the VDB will provide an Invalid condition with the
appropriate ReturnCode (551 to 561, 580) and return up to a specified number of matches 25. If no
matches are found, the VDB will return an Invalid condition with the appropriate ReturnCode
(551 to 561) only.
If the submitted address is for a geographical area that is not in the serving area of the VDB, the
VDB will respond with a na condition and ReturnCode 562.
If the submitted address yields multiple MSAG matches, the VDB shall provide an Invalid
condition with ReturnCode 570 and return up to a specified number of matches.
25 The maximum number of alternatives to be provided may be configurable by the VDB operator.
Page 162 of 247

NENA 08-001 v2, August 11, 2010
The VDB shall validate the data received against the appropriate VDB database and return an
indicator of the datas validity and one or more addresses that may be matches for the input address.
6.8.1.2.1 v7 Defined Return Codes
Table 6-18 below lists the defined Return Codes supported over the v7 interface with their
associated description.
Table 6-18 - v7 Return Codes
Return Code
Description
200
210
500
551
552
553
554
555
Success (location is MSAG-valid).

Success Address translated (location is MSAG-valid but address was modified).
Internal Server Error (to indicate System Failure).
Street Name is required.
Community is required.
State/Province is required.
Postal code not found.
Prefix Directional must contain only the characters N, S, E, W and must be from
1-3 characters in length.
Post Directional must contain only the characters N, S, E, W and must be from 13 characters in length.
State not found.
Community not found.
Street not found.
House number is out of range.
Not in Serving Area.
More than one MSAG entry match.
Not found - alternates returned.
556
558
559
560
561
562
570
580
6.8.1.2.2 v7 validateAddressResponse Examples

Here is a successful validation response example for a single address where the VDB added the
MSAG community name, county name, county ID and geodetic information.
Page 163 of 247

NENA 08-001 v2, August 11, 2010
<validateAddressResponse xmlns=urn:nena:xml:ns:es:V7>
<ReturnCode>200</ReturnCode>
<Valid>valid</Valid>
<AddressList>
<Civic>
<HouseNum>700</HouseNum>
<StreetSuffix>ST</StreetSuffix>
<MSAGCommunity>AUSTIN</MSAGCommunity>
<CountyName>TRAVIS</CountyName>
<CountyID>453</CountyID>
<PostalCode>78701</PostalCode>
</Civic>
<GeoPosition>
<Latitude>30.270339</Latitude>
<Longitude>-97.745044<Longitude>
<Elevation>100<Elevation>
</GeoPosition>
</AddressList>
</validateAddressResponse>
Page 164 of 247

NENA 08-001 v2, August 11, 2010
Here is a successful validation response example for a single address where the VDB has modified
the provided address and subsequently added the MSAG community name, county name, county ID
and geodetic information.
<Valid>valid</Valid>
<AddressList>
<Civic>
</Civic>
<GeoPosition>
</GeoPosition>
</AddressList>
Here is an unsuccessful validation response example for a single address where the VDB couldnt
validate against a unique MSAG entry. The VDB returns alternate addresses.
Page 165 of 247

NENA 08-001 v2, August 11, 2010
<Valid>invalid</Valid>
<AddressList>
<Civic>
</Civic>
<GeoPosition>
</GeoPosition>
</AddressList>
<AddressList>
<Civic>
<PostalCommunity>HOUSTON</PostalCommunity>
<MSAGCommunity>HOUSTON</MSAGCommunity>
<CountyName>HARRIS</CountyName>
</Civic>
<GeoPosition>
<Longitude>-95.275822</Longitude>
</GeoPosition>
</AddressList>
6.8.2
v7 Message Flows, Key Scenarios and Semantics
Page 166 of 247

NENA 08-001 v2, August 11, 2010
This section describes the key scenarios and shows the message flows between the various elements
involved. An automated mechanism is assumed in this section however, a manual process could be
used as well (by a LIS administrator for example).
It is expected that location validation will be performed outside of the emergency call flow so it
doesnt introduce delays in processing the call.
6.8.2.1 v7 - Successful Postal Address Validation
The following figure describes a typical message flow where a valid location is provided by the LIS
to the appropriate VDB. The v7 messages are identified in bold red.
Figure 6-10 v7 Successful Validation
1. Locations of broadband connections are loaded into the LIS 26. The civic locations may be
postal-formatted.
2. If the serving VDB is not already known, the LIS issues an identityRequest message to the
RDS to discover the serving VDB for the location it manages. It is assumed that the LIS is
authenticated with the RDS.
3. The RDS searches its own database for corresponding records based on the provided
location. It then constructs an identityResponse message back to the LIS containing the
serving VDB URI(s).
26 This interface is out of scope for this document.
Page 167 of 247

NENA 08-001 v2, August 11, 2010
4. The LIS acknowledges the identityResponse message and constructs a
validateAddressRequest message with the targeted location to (one of) the discovered
VDB(s) over v7.
5. The VDB authenticates the LIS, launches a database lookup using the provided location and
provides a response back to the LIS containing the return code, the valid flag and MSAGvalid address associated with the location provided.
6.8.2.2 v7 Initial Unsuccessful Postal Address Validation
The following figure describes a typical message flow where an invalid location is provided by the
LIS to the appropriate VDB. The v7 messages are identified in bold red.
Figure 6-11 v7 Unsuccessful Validation
Page 168 of 247

NENA 08-001 v2, August 11, 2010
1. Locations of broadband connections are loaded into the LIS 27. The civic locations may be
postal-formatted.
2. If the serving VDB is not already known, the LIS issues an identityRequest message to the
RDS to discover the serving VDB for the location it manages. It is assumed that the LIS is
authenticated with the RDS.
serving VDB URI(s).
VDB(s) over v7.
provides a response back to the LIS containing the return code, the invalid flag and, if found,
a list of potential alternate addresses.
6. The LIS uses internal error management processes/mechanisms to correct the errors using the
provided information by the VDB or other sources.
7. It corrects the location and reissues a validateAddressRequest message to the VDB.
provides a response back to the LIS containing the return code, the valid flag and MSAGvalid address associated with the location provided.
6.8.3
not. The v7 interface should be used with a suitable security mechanism as defined in Section 4.
When the connection between the LIS and the VDB is not a trusted network, both the LIS and the
VDB are expected to be protected with IPsec or TLS, and thus require a certificates rooted in VESA.
Even in a trusted network, TLS protection is advisable. Mutual authentication is required when
cryptographic security is deployed. This provides strong security mechanisms and is readily able to
traverse enterprise and commercial firewalls when correctly configured. The LIS is expected to be a
VESA-certified entity, and the configuration of the LIS should be such that it uses a server-side
VESA certificate that is presented to the VDB on session establishment. This allows the VDB to
validate the LIS credentials before agreeing to accept and provide location information. The VDB
may use this information for billing or other purposes.
6.9
v8 Interface - VPC to ERDB
The v8 interface, in the context of the i2 architecture, defines the communication protocol and
messaging between a VPC and an ERDB, or between ERDBs 28. The ERDB is the entity that stores
the boundary information for emergency service zones. The ERDB should be able to accept queries
27 This interface is out of scope for this document.
28 The ERDB steering mechanism is only partially defined in this version of the document.
Page 169 of 247

NENA 08-001 v2, August 11, 2010
that contain geo-spatial or civic location information. When queried with location information, it
returns the ERT, MSAG formatted civic address (if routing is based on civic location information),
geo-coded location information (if geodetic default routing was applied at the ERDB), and CRN, if
available, which is used for contingency routing. In addition, the ERDB may also return an
administrative ESN via the v8 interface, if one is included in the routing information associated with
the callers location.
6.9.1
v8 Message Definition
A Request/Response message pair is defined here to allow a VPC to send a routing query to an
ERDB that contains information describing the emergency callers location (or to allow an ERDB to
forward a routing query received from a VPC to another ERDB), and to support the return of the
associated routing information by the ERDB. XML messages are used to support this information
exchange, with tags utilized for conveying civic and geodetic information to the ERDB.
6.9.1.1 v8 erdbRequest Request Routing Information
For the query, the erdbRequest is expected to contain geographical coordinates, civic address
information or both civic and geodetic location information. The erdbRequest will be sent to an
ERDB identified via the Root Discovery process (Section 3.9 describes the Root Discovery process).
The location information provided to the ERDB in the query is derived from the LO obtained by the
VPC.
Table 6-19 - erdbRequest Parameters
Parameter
messageId
Condition
Mandatory
source
Mandatory
vpc
Conditional
location
Conditional
geolocation
*Conditional
civiclocation
*Conditional
datetimestamp
Optional
destination
Optional
Description
This parameter uniquely identifies the query
at the VPC
Identifies the node directly requesting routing
information from the ERDB
Identifies the VPC that originally requested
the routing information
If present, contains one or both of the
following elements:
WGS84 coordinates derived from LO
Validated address passed in LO. This is
constructed from civic location information
received in the PIDF-LO
The datetimestamp parameter carries the date
and time of the message generation described
using UTC
Identifies the ERDB from which routing
information is being requested
Page 170 of 247

NENA 08-001 v2, August 11, 2010
* One of these must be present, it is possible that both these elements may be present
The <messageId> parameter uniquely identifies the query at the VPC. The format is up to 32
characters, expressed as follows:
<messageId>78801FA048D4226E4787F955</messageId>
The <source> element identifies the node directly requesting emergency call routing information
from the ERDB over the v8 interface. It includes the source node (hostId), a NENA administered
identifier (nenaId), a 24x7 contact number (contact), and an optional uri (certUri), a link to the
provider's VESA issued certificate. The <source> must be a trusted entity of the ERDB.
The format must be as follows:
<source>
<organizationName>Noname VPC</organizationName>
<contact>tel:+398348975439823</contact>
</source>
The <hostid> and <contact> fields are mandatory while all the other fields of the <source>
The <vpc> element identifies the VPC that is requesting the routing information from the ERDB. In
cases where the routing request is steered from one ERDB to another, the <vpc> element would
identify the VPC requesting the routing information whereas the <source> element would identify
the ERDB that is steering the request. The format must be as follows:
<vpc>
<nenaId>NENA911</nenaId>
</vpc>
The <hostId> and <contact> fields are mandatory while all the other fields of the <source>
The <location> element contains the actual physical location of the VEP. It may be expressed as a
geodetic location, a civic address, or both formats of the same physical location.
Page 171 of 247

NENA 08-001 v2, August 11, 2010
geolocation The ERDB requires WGS 84 format so this may require the VPC to convert the
coordinate information, if received, to WGS84. The two other coordinates systems discussed to date
are NAD 83 and NAD 27 (HARN). Geolocation may be provided using GML notation as Point,
Circle or Sphere. If Circle or Sphere data is provided, the ERDB will use the center-point of the
circle or sphere to determine routing. The GML format may be as follows:
<location>
<gml:pos>37.775 -122.4194</gml:pos>
</gml:Point>
</location>
civiclocation The civiclocation element uses NENA-defined data elements. This is constructed
from elements of the PIDF-LO. This must be the Civic Address that was used for ERDB discovery.
It is assumed that this address was previously validated at the VDB. The format must be as follows:
<location>
<civiclocation>
<PrefixDirectional>N</PrefixDirectional>
</civiclocation>
</location>
The <datetimestamp> parameter carries the date and time of the message generation described using
ISO 8601 [44] UTC format.
The <destination> element identifies the ERDB from which routing information is being requested.
It includes the source node (hostId), a 24x7 contact number (contact), and optional parameters for
the organization's name and uri (certUri) for the operator's VESA issued certificate, and a NENA
administered identifier (nenaId). The <destination> must be a trusted entity of the VPC/ERDB.
Page 172 of 247

NENA 08-001 v2, August 11, 2010
<destination>
<organizationName>ERDB Provider</organizationName>
<hostId>erdb34.example.com</hostId>
<certUri>https://erdb.example.com/certificate.crt</certUri>
</destination>
6.9.1.2 erdbRequest Message Format

The following is an example erdbRequest message.
Page 173 of 247

NENA 08-001 v2, August 11, 2010
<erdbRequest xmlns="urn:nena:xml:ns:es:v8"
<source>
<organizationName>Vern's Virtual VPC</organizationName>
<certUri>https:\\rp34.example.com/certificate.crt</certUri>
</source>
<location>
<civiclocation>
</civiclocation>
<gml:pos>37.775 -122.4194</gml:pos>
</gml:Point>
</location>
<datetimestamp>2001-12-17 09:30:47.0Z</datetimestamp>
<destination>
<organizationName>Earl's Excellent ERDB</organizationName>
<certUri>https:\\cs47.example.com/certificate.crt</certUri>
</destination>
</erdbRequest>
6.9.1.3 v8 erdbResponse Routing Response

The response message assumes the responding ERDB has been determined.
Page 174 of 247

NENA 08-001 v2, August 11, 2010
Table 6-20 - erdbResponse Parameters
Parameter
messageId
source
Condition
Mandatory
Mandatory
erdb
Conditional
ert
Conditional
selectiveRoutingID Conditional
routingESN Conditional
npa Conditional
adminesn
Conditional
crn
Conditional
msagvalidcivicaddress Conditional
geocodedlocation
Conditional
result
Mandatory
Description
Uniquely identifies the query at the VPC
The identifier of the node directly
responding to the routing query over the v8
interface
The identifier of the ERDB that is the
original source of the routing information
A routing identifier comprising the
following 3 elements:
The Common Language Location Indicator
(CLLI) code associated with the Selective
Router to which the emergency call is to be
directed.
The Emergency Services Number associated
with a particular ESZ that respresents a
unique combination of Police, Fire and EMS
emergency responders.
The primary Numbering Plan Area (NPA)
associated with the outgoing route to the
Selective Router that is appropriate for
callers location.
Identifies the administrative ESN associated

with the LO in the query
Contingency 24x7 E.164 phone number to
use when unable to route using the
ERT/ESGWRI.
Carries the MSAG valid formatted civic
address provided by the ERDB
Carries the geo-coded location information
derived by the ERDB if geodetic default
routing was applied
Indicates the success or error in responding
to the query
Page 175 of 247

NENA 08-001 v2, August 11, 2010
Parameter
datetimestamp
destination
Condition
Optional
Optional
Description
The datetimestamp parameter carries the
date and time of the message generation
described using UTC
The identifier of the node requesting the
routing information
The <messageID> parameter uniquely identifies the query at the VPC. The format is up to 32
characters, expressed as follows:
The <source> element identifies the node directly responding with emergency call routing
information over the v8 interface. It includes the source node (hostId), a 24x7 contact number
(contact), and an optional uri (certUri) and an optional NENA administered identifier (nenaId) to
provide a link to the provider's VESA issued certificate.
<source>
<organizationName>Noname ERDB</organizationName>
<certUri>https://erdb34.example.com/certificate.crt</certUri>
</source>
The <erdb> element identifies the node that is the source of the routing information. In some cases
the <erdb> element will be coded with the same information as the source element. In cases where
ERDB steering occurs, the <erdb> element will be coded with the identity of the ERDB from which
the routing information was obtained. It includes the source node (hostId), a 24x7 contact number
(contact), an optional NENA administered identifier (nenaId), and an optional uri (certUri) that
provides a link to the provider's VESA issued certificate. The format must be as follows:
Page 176 of 247

NENA 08-001 v2, August 11, 2010
<erdb>
<organizationName>No Name 1 ERDB</organization name>
<nenaId>NENA911</nenaId>
<certUri>https://erdb1.example.com/certificate.crt</certUri>
</erdb>
The <ert> element is composed of a <selectiveRoutingID> tag, a <routingESN> tag and a <npa>
tag which are used to derive the appropriate ESGWRI.
The <selectiveRoutingId> contains the CLLI code of the selective router to which the call is being
routed. The CLLI code is an 11 character alphanumeric field of the form AAAABBCCDDD, where
AAAA represents the city/county
BB represents the State
CC represents the building or location
DDD represents the network.
The <selectiveRoutingID> must be provided if a <routingESN> and <npa> are provided.
The <routingESN> is a 3- to 5-digit field that uniquely identifies the ESZ in the context of an SR,
and the associated Police, Fire, and EMS emergency responders associated with that ESZ. The
<routingESN> must be provided if a <selectiveRoutingID> and <npa> are provided.
The <npa> is a 3 digit field that identifies the primary NPA associated with an outgoing trunk group
to the appropriate SR associated with the callers location. The <npa> must be provided if a
<selectiveRoutingId> and <routingESN> are provided.
<ert>
<selectiveRoutingID>AAAABBCCDDD</selectiveRoutingID>
<routingESN>nnnnn</routingESN>
<npa>NPA</npa>
</ert>
The <adminESN> parameter is coded with the administrative ESN that is associated with the
location information that is received in the query, when this information is available. It is associated
with a particular set of English Language Translations for an ESZ in a PSAP that are stored by the
ALI Database.
<adminesn>12345</adminesn>
Page 177 of 247

NENA 08-001 v2, August 11, 2010
The <crn> parameter holds the PSAP 24 x 7 emergency number that can be used to route the call in
times of network failure. The format is expected to be an E.164 PSTN telephone number.
<crn>npa-nxx-nnnn</crn>
The <msagvalidcivicaddress> parameter carries the MSAG-valid formatted civic address provided
by the ERDB. As previously described, the ERDB is expected to convert a received civic address
into an MSAG valid format that can be presented at the PSAP. This parameter is expected to be sent
only if a civic location is received in the erdbRequest message. The format must be as follows:
<msagvalidcivicaddress>
<HouseNumSuffix>1/2</HouseNumSuffix>
<PostDirectional>SW</PostDirectional>
</msagvalidcivicaddress>
The <geocodedlocation> parameter carries the geo-coded location information derived by the
ERDB if geodetic default routing was applied to the emergency call. This parameter is expected to
be sent only if civic location information is received in the ERDBRequest message and is found to
be invalid, the ERDB determines that default routing procedures must be invoked, and the PSAP
Authority has authorized the use of geodetic default routing. The format must be as follows:
<geocodedlocation>
<gml:pos>37.775 -122.4194</gml:pos>
</gml:Point>
</geocodedlocation>
The <result> parameter carries an indication of whether the ERDB was able to provide routing
information and the means by which routing information was determined. If no routing information
was provided, this parameter could be used to determine the cause of the problem. Table 6-21 Result Codes lists and describes the codes that should be used.
Page 178 of 247

NENA 08-001 v2, August 11, 2010
<result>200</result>
<datetimestamp> The <datetimestamp> parameter carries the date and time of the message
generation described using ISO 8601 [44] UTC format.
The <destination> element identifies the node that directly requested emergency call routing
information. It includes the source node (hostId), a 24x7 contact number (contact), and optional
parameters for the organization's name and uri (certUri) for the operator's VESA issued certificate.
The <destination> must be a trusted entity of the VPC/ERDB.
<destination>
<organizationName>vpc Provider</organizationName>
</destination>
Table 6-21 - Result Codes
Value
200
Name
SuccessGeodetic
201
SuccessCivic
210
Default route on Geo
211
Default Route on Postal,

City, County, State
212
Default Route on Postal,
Description
This value indicates that the ERDB was successful in
determining routing information using the received
Geo Location information
This value indicates that the ERDB was successful in
determining routing information using the received
Civic Location information
This value indicates that the ERDB was unable to
provide routing based on the civic location provided
but was able to successfully geocode the complete
location yielding a default route based on geocoded
information.
match an exact tabular MSAG-location based on the
civic location provided but was successful in
determining a default route based on the combination
of Postal Zone, Community name, County and State.
Page 179 of 247

NENA 08-001 v2, August 11, 2010
Value
Name
County, State
213
Default Route on City,

County, State
214
Default Route on County,

State
215
Default Route on State
400
ErrorBadLocation
401
ErrorNoLocation
403
ErrorBadMessage
404
ErrorAuthorization
500
ErrorGeneral
562
Out of Area
Description
of Postal Zone, County and State.
of Community name, County and State.
of County and State.
determining a default route based on the State.
provide routing information because the received
location information was bad
provide routing information because the no location
information was received in the query
This value indicates that routing information was not
provided because the query received was corrupted
This value indicates that routing information was not
provided because the query failed authentication
This value indicates that a general error occurred and
the ERDB is unable to return routing information
This value indicates that the ERDB cannot process the
request as the address provided falls ouside its serving
area.
6.9.1.4 ERDBResponse Message Format

The following is an example of an erdbResponse message.
Page 180 of 247

NENA 08-001 v2, August 11, 2010
<erdbResponse xmlns="urn:nena:xml:ns:es:v8"
<source>
<organizationName>Earl's Excellent ERDB</organizationName>
<certUri>https:\\cs47.example.com/certificate.crt</certUri>
</source>
<ert>
<selectiveRoutingID>CITYTX12NET</selectiveRoutingID>
<npa>512</npa>
</ert>
<adminesn>00000</adminesn>
<crn>5129987777</crn>
<msagvalidcivicaddress>
<StreetName>LAVACA ST</StreetName>
</msagvalidcivicaddress>
<result>200</result>
<datetimestamp>2001-12-17T09:30:47.0Z</datetimestamp>
<destination>
<organizationName>Vern's Virtual VPC</organizationName>
<certUri>https:\\rp34.example.com/certificate.crt</certUri>
</destination>
</erdbResponse>
6.9.2
v8 Message Flows, Key Scenarios and Semantics
Section 6.9.1 describes in detail the two messages that make up communication across the v8
interface. This section will describe the key call scenarios and show the message flows between the
various network elements.
Page 181 of 247

NENA 08-001 v2, August 11, 2010
6.9.2.1 v8 ERDB returns Routing Information in response to erdbRequest
The following figure describes a typical call flow where a valid location is provided by the VPC to
the appropriate ERDB. The v8 messages are identified in bold red.
Figure 6-12 - ERDB returns Routing Information over v8
initiation message.
the VPC over v2.
Page 182 of 247

NENA 08-001 v2, August 11, 2010
location contained in the PIDF-LO to request Routing information based on the provided
location.
4. The ERDB authenticates the VPC and retreives the location-associated ERT, CRN, admin
ESN and MSAG-formatted address from its database and constructs the erdbResponse to the
VPC over v8.
5. There are two options for what the VPC returns to the CS depending on the arrangement in
place with the CS:
provides this information to the CS along with the LRO. In this case, the CS will use the
ESGWRI directly for route selection. The VPC logs the MSAG-formatted address and
Admin ESN with the other call-related information for audit trail purposes.
b. The CS holds ERT-to-ESGWRI mappings. Based on the ERT received from the ERDB,
to the CS along with the LRO. In this case, the CS will use internal ERT to ESGWRI
6. The CS subsequently routes the call to the ESGW over v4, and includes the ESGWRI, ESQK
and callback number in outgoing signaling.
The media stream is established. The caller and the PSAP call taker can now communicate.
7. Some time later, the caller hangs up, the CS detects that call has concluded, and that the
ESQK is no longer required.
8. The CS sends an ESCT message containing the ESQK and ESGW identifier to the VPC over
v2.
available keys, and notes the ESGW in its call event records. The VPC sends an ESCTAck
message to the CS.
6.9.2.2 v8 ERDB returns Routing Error
The following figure describes a typical call flow where an invalid location is provided through the
VPC, and default routing is not applied or unsuccessful at the ERDB. The v8 messages are identified
in bold red.
Page 183 of 247

NENA 08-001 v2, August 11, 2010
UA
CS
1. Call Init
(PIDF-LO)
VPC
customer, callback)
ERDB
PSTN
GW
3. erdbRequest
(invalid location)
4. erdbResponse
(error)
5. esrResponse (error)
6. Default Route Call
7. Call Termination
Figure 6-13 ERDB Returns an Error over v8
initiation message.
subscriber name, and a LIE containing the PIDF-LO. The CS sends the esrRequest message
to the VPC over v2.
location contained in the PIDF-LO to request routing information based on the provided
assumed-to-be-valid location.
4. The ERDB authenticates the VPC and tries unsuccessfully to retrieve the location-associated
routing information from its database. The ERDB is unable to perform default routing using
the received location. It then constructs the erdbResponse to the VPC over v8 specifying the
error condition encountered.
5. The VPC receives the erdbResponse message and constructs an esrResponse message back to
the CS over v2 with the error condition included.
Page 184 of 247

NENA 08-001 v2, August 11, 2010
6. The CS acknowledges the error and performs its default routing behavior using local default
routing policies, which may be to send the call to a default PSAP (as shown in the example
call flow above), or to drop the call altogether. While in this example, the call is default
routed to a PSAP through the PSTN gateway.
The media stream is established. The caller and the call taker can now communicate.
7. Some time later, the caller hangs-up, the CS detects that call has concluded and forwards the
call termination message to the PSTN gateway.
6.9.3
Security
not, as described previously. The v8 interface is an XML-based interface and should be used with a
suitable security mechanism as defined in Section 4. When the connection between the VPC and the
ERDB is not a trusted network, both the VPC and ERDB are expected to be protected with IPsec or
TLS, and thus require certificates rooted in VESA. Even in a trusted network, TLS protection is
advisable. Mutual authentication is required when cryptographic security is deployed.
6.10 v9 Interface LIS/VPC to RDS
The v9 interface, in the context of the i2 architecture, defines the communication protocol and
messaging between a LIS or VPC to the Root Discovery Service (RDS).
The RDS is the entity that stores the serving areas of ERDBs and VDBs. The RDS should be able to
accept queries that contain geo-spatial or civic location information. When queried with location
information, it returns a list of URIs for ERDBs or VDBs serving that area.
6.10.1 v9 Messages Definitions
A Request/Response message pair is defined here to allow a LIS or VPC to send a query to the RDS
that contains information describing the emergency callers location and to support the return of
URIs associated with VDBs or ERDBs that serve that area. XML messages are used to support this
information exchange.
6.10.1.1 v9 identityRequest Request VDB/ERDB Information
For the query, the identityRequest is expected to contain either geographical coordinates or civic
address information. The location information provided to the RDS in the query is derived from the
LO obtained by the VPC or from the Location Information stored in the LIS.
Table 6-31 - identityRequest Parameters
Parameter
geolocation
Condition
*Conditional
Description
WGS84 coordinates derived from LO
civiclocation
*Conditional
Civic address information present in the LIS or

the civic address received at the VPC
Page 185 of 247

NENA 08-001 v2, August 11, 2010
Parameter
querytype
Condition
Mandatory
Description
Identifies whether VDB or ERDB information is
being requested
* One of these must be present; it is possible that both these elements may be present
geolocation Geolocation may be provided using gml notation as Point, Circle or Sphere. If Circle
or Sphere data is provided the RDS will use the center-point of the circle or sphere to determine the
appropriate ERDB/VDB.
<location>
<gml:pos>37.775 -122.4194</gml:pos>
</gml:Point>
</location>
civiclocation the civic address must be provided using NENA data elements as defined in NENA
02-010 [11] and NENA 02-013 [38].
<location>
<civiclocation>
<HouseNumSuffix>A</HouseNumSuffix>
<PostDirectional>S</PostDirectional>
</civiclocation>
</location>
querytype format:
<querytype>ERDB</querytype>
or
Page 186 of 247

NENA 08-001 v2, August 11, 2010
<querytype>VDB</querytype>
6.10.1.2 identityRequest Message Format using Civic Location
<identityRequest xmlns="urn:nena:xml:ns:es:v9" xmlns:alins="http://www.nena9-11.org/schemas/2003/ali" xmlns:gml="http://www.opengis.net/gml"

<location>
<civiclocation>
</civiclocation>
</location>
</identityRequest>
6.10.1.3 identityRequest Message Format using Geodetic Location

Point Example
Page 187 of 247

NENA 08-001 v2, August 11, 2010
<identityRequest xmlns="urn:nena:xml:ns:es:v9"
<location>
<gml:pos>37.775 -122.4194</gml:pos>
</gml:Point>
</location>
</identityRequest>
Circle Example
<identityRequest xmlns="urn:nena:xml:ns:es:v9"
xmlns:gml="http://www.opengis.net/gml"
<location>
<gs:Circle srsName="urn:ogc:def:crs:EPSG:6.6:4326">
<gml:pos>37.775 -122.4194</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">30</gs:radius>
</gs:Circle>
</location>
</identityRequest>
6.10.1.4 identityResponse VDB/ERDB Response

The response may contain one of three different response types: error, ambiguous or found.
Table 6-32 identityResponse v9:error Attribute
Attribute
code
Condition
Mandatory
message
Optional
Description
Indicates error that occurred;
400 = not found
500 = general error
Text describing the error code
Table 6-32 identityResponse v9:ambiguous Parameters
Page 188 of 247

NENA 08-001 v2, August 11, 2010
Parameters
civiclocation
Condition
Mandatory
Description
If an ERDB/VDB cant be determined; this
message returns the civic address fields
which must be resolved before an answer
can be determined.
Table 6-33 identityResponse v9:found Parameters
Parameters
erdbAddress
Condition
Conditional
poc
Conditional
VDB
Conditional
Description
List of ERDB URIs that have routing
information for the address or geo-position
submitted.
This only applies when geodetic information
is provided in the query. Percentage Overlap
Confidence value; this describes the
percentage of the initially provided callerlocation overlapped with the corresponding
ERDB service area.
List of VDB URIs that have MSAG
information for the address submitted.
* Conditional either VDB or ERDB information must be returned.

6.10.1.5 identityResponse Message Format when found
<identityResponse xmlns="urn:nena:xml:ns:es:v9"
<found>
<ERDB>
<erdbAddress>earlserdb.vendor.com</erdbAddress>
<poc>90</poc>
</ERDB>
<ERDB>
<erdbAddress>ernestserdb.vendor2.com</erdbAddress>
<poc>50</poc>
</ERDB>
</found>
</identityResponse>
Page 189 of 247

NENA 08-001 v2, August 11, 2010
<found>
<VDB>
<vdbAddress>vernsvaluablevalidator.vendor.com</vdbAddress>
</VDB>
<VDB>
<vdbAddress>valerievolubleverifier.vendor2.com</vdbAddress>
</VDB>
</found>
</identityResponse>
6.10.1.6 identityResponse Message Format when ambiguous

xsi:schemaLocation="urn:nena:xml:ns:es:v9:\MYDOCU~1\XMLSchema
\CurrentNENA\I2\v9\v9.xsd">
<ambiguous message="token">
<civiclocation>
</civiclocation>
< /ambiguous>
</identityResponse>
6.10.1.7 identityResponse Message Format when error
Page 190 of 247

NENA 08-001 v2, August 11, 2010
xsi:schemaLocation="urn:nena:xml:ns:es:v9:\MYDOCU~1\XMLSchema
\CurrentNENA\I2\v9\v9.xsd">
<error code="400" message="token"/>
</identityResponse>
6.10.2 v9 Message Flows, Key Scenarios and Semantics

Section 6.10.1 described in detail the 2 messages that make up communication across the v9
interface. This section will describe the key call scenarios and show the message flows between the
various network elements.
6.10.2.1 v9 LIS Discovering VDB
The following figure describes a typical call flow where a valid location is provided by the LIS to
the RDS in order to discover the appropriate VDB. The v9 messages are identified in bold red.
Figure 6-14 - RDS returns VDB URIs over v9
1. The LIS issues an identityRequest message to the RDS to discover the serving VDB for a
location it manages. It is assumed that the LIS is authenticated with the RDS.
serving VDB URI(s).
Page 191 of 247

NENA 08-001 v2, August 11, 2010
VDB(s) over v7.
4. The VDB authenticates the LIS and provides a response back to the LIS containing the return
code and MSAG address associated with the location provided.
6.10.2.2 v9 VPC Discovering ERDB
The following figure describes a typical call flow where a valid location is provided by the VPC to
the RDS in order to discover the appropriate ERDB. It is expected that the VPC will query the RDS
for every call. The v9 messages are identified in bold red.
UA
CS
1. Call Init
(PIDF-LO)
VPC
2. esrRequest (PIDFLO, customer,

callback)
ESGW
3. identityRequest
(location)
4. identityResponse
(erdb URI(s), [poc])
esgwri, esqk, lro)
ERDB
RDS
5. erdbRequest
(location)
6. erdbResponse
(ert, crn, msagaddr)
8. Route Call

9. Call Termination
10. esct
(callid, esgw, esqk)
11. esctAck
Figure 6-15 - RDS returns ERDB URIs over v9
initiation message.
Page 192 of 247

NENA 08-001 v2, August 11, 2010
the VPC over v2.
location contained in the PIDF-LO to discover the serving ERDB based on the provided
location over v9.
4. The RDS authenticates the VPC and searches its database for corresponding records based on
the provided location. It then constructs an identityResponse message back to the VPC
containing the serving ERDB URI(s).
5. The VPC acknowledges the identityResponse message and uses the location contained in the
PIDF-LO to request Routing information from (one of) the discovered ERDB(s) over v8.
6. The ERDB authenticates the VPC and retreives the location-associated ERT, CRN, admin
ESN and MSAG-formatted address from its database, and constructs the v8 erdbResponse to
the VPC.
7. The VPC allocates an ESQK based on the received ERT. The VPC constructs an
esrResponse message containing the ESQK, LRO, and either the ESGWRI or the ERT, and
returns this to the CS over v2. The VPC logs the MSAG-formatted address and Admin ESN
with the other call-related information for audit trail purposes.
8. The CS uses the ESGWRI, if received in the routing response, to determine the correct
ESGW, or the CS determines the ESGW and appropriate ESGWRI value based on the ERT
received in the routing response message. The CS subsequently routes the call to the ESGW
over v4, and includes the ESGWRI, ESQK and callback number in outgoing signaling.
The media is established. The caller and the PSAP call taker can now communicate.
9. Some time later, the caller hangs-up, the CS detects that call has concluded, and that the
ESQK is no longer required.
10. The CS sends an ESCT message containing the ESQK and ESGW identifier to the VPC over
v2.
available keys, and notes the ESGW in its call event records. The VPC sends an ESCTAck
message to the CS.
6.10.3 v9 Interface Security
not, as described in previously. V9 is a XML-based interface and should be used with a suitable
security mechanism as defined in Section 4. When the connection between the VPC or LIS and the
RDS is not a trusted network, both the VPC/LIS and RDS are expected to be protected with IPsec or
TLS, and thus require certificates rooted in VESA. Even in a trusted network, TLS protection is
advisable. Mutual authentication is required when cryptographic security is deployed.
6.11 v-E2 Interface ALI to VPC
The v-E2 interface, in the context of the i2 Solution migration architecture, defines the
communication protocol and messaging between a VPC and an ALI DB. This interface specification
Page 193 of 247

NENA 08-001 v2, August 11, 2010
outlines the required data fields, with formats and examples, by which a VPC shall properly
assemble and send emergency call-related data in response to a query from an ALI DB, in order to
facilitate the delivery of emergency call-related data to a conventional PSAP.
This interface is based on the E2+ interface between a wireless Mobile Positioning Center (MPC)
and an Emergency Services Message Entity (ESME) described in NENA-05-001[13], which is in
turn based on E2 interface specified in TIA J-STD-036-B [34]. This document provides incremental
requirements, describing the differences from NENA 05-001.
The technical description and the network architecture described in Sections 3 and 4 of NENA
05-001 shall apply with the following clarifications for the i2 Solution. In the i2 Solution
architecture, the VPC takes the place of the MPC in the architecture and the ESME is referred to as
an ALI, as illustrated in Figure 6-15.
ALI
VPC
ALI
VPC
PSAP
one-to-one
many-to-many
Figure 6-16. v-E2 Interface Architecture
It is not recommended that an E2 interface as described in TIA J-STD-036A (rather than NENA 05001) be used as the basis for the VPC to ALI interface. However, if this is the case, the ALI will not
be able to receive civic location information. It may receive some information, e.g., Callback
Number or geodetic location if it is available. Please refer to Appendix A.
If a PSAP-to-ALI Message (PAM) interface is used for communications between the VPC and the
ALI, this is not specified as part of the i2 Solution.
VPC operators may reuse existing physical interfaces to establish v-E2 logical connection along side
existing E2+ logical connections based on business agreements.
6.11.1 v-E2 Message Definitions
There are four Request/Response messages defined in NENA 05-001 that are defined here for use in
requesting and responding to requests for emergency call information from the VPC. The remainder
of this section details the four messages that make up communication across the v-E2 interface.
Page 194 of 247

NENA 08-001 v2, August 11, 2010
The VPC and the ALI DB shall be able to support the messages and parameters defined in NENA
05-001, as modified in this document for use across the v-E2 interface.
6.11.1.1 Emergency Services Position Request (ESPOSREQ)
The ESPOSREQ message is sent from the ALI DB to the VPC to request call- and location-related
information from the VPC for an emergency call, identified by a query key, the Emergency Services
Query Key (ESQK). The valid parameters for the ESPOSREQ message are included in the following
table. The ALI DB shall use the Position Request parameter to make the initial request for location
information as well as to request updates of location.
Table 6-22. ESPOSREQ Parameters
Parameter
Ref. in
NENA 05-001
Condition
Description/Value
Package Type=Query
with Permission
9.1.1
Mandatory
Query with
Permission
Transaction ID
9.1.2
Mandatory
Component Sequence
9.2.1
Mandatory
Component Type
9.2.2
Mandatory
Component ID
9.2.3
Mandatory
Operation Code
9.2.4
Mandatory
Parameter Set
9.2.7
Mandatory
ESMEIdentification
9.3.1
Mandatory
Position Request Type
9.3.2
Mandatory
Emergency Services
Routing Key (esprKey)
9.3.3
Callback Number
9.3.4
Invoke (Last)
Private TCAP
Mandatory 29 Emergency Services

Query Key (ESQK)
Optional
If 20 digits are sent to

the SR, the callback
number may be sent
over the v-E2
interface.
29 This parameter is Optional in NENA 05-001 for wireless call information provided to the ESME from the MPC. However, when
the E2 interface is used to support VoIP call information from a VPC to an ESME, this parameter must be populated with the
Emergency Services Query Key.
Page 195 of 247

NENA 08-001 v2, August 11, 2010
6.11.1.2 Emergency Services Position Request Response (esposreq)
This message is sent from the VPC to the ALI DB to inform the ALI DB of the position of the VoIP
Endpoint.
Table 6-23. Emergency Services Position Request Response (esposreq) Parameters
Parameter
Package Type
Transaction ID
Component Sequence
Component Type
Component ID
Parameter Set
Position Result
PositionInformation
Geographic Position
Position Source
Reference in
NENA 05-001
Ref. in
this doc.
9.1.1
9.1.2
9.2.1
9.2.2
9.2.3
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory
9.2.7
9.3.8
9.3.9
9.3.9.2
9.3.9.3
Mandatory
Mandatory
1.1.3.3
6.11.2.3
Inclusion
Condition
Optional
Optional
CallbackNumber
9.3.5
6.11.2.4 Conditional 30
Emergency Services Routing

Digits Request Response
9.3.7
5.11.2.5
NA
GeneralizedTime
9.3.11
6.11.2.6
Optional
MobileIdentificationNumber
InternationalMobileSubscribe
rIdentity (IMSI)
MobileCallStatus
CompanyID
9.3.12
9.3.13
6.11.2.7
-
NA
NA
9.3.14
9.3.15
6.11.2.8
NA
Mandatory 31
LocationDescription
9.3.16
6.11.2.9
Conditional
Description/Value
Response
Return Result (Last)
Geo Location
Method of location
determination
Callers E.164
number
Not used.
(In the future this
parameter might be
populated with
ESQK )
Timestamp for
assignment of ESQK
Not used
Not used
Not used
Name of the VSP
(up to 15 characters)
Tagged elements of
the E2 interface is used to support VoIP call information from a VPC to an ESME, this parameter must be populated with an E.164
number identifying the Callback Number of the emergency caller, if it is available to the VPC.
the E2 interface is used to support VoIP call information from a VPC to an ESME, this parameter must be populated with
identification for the VoIP Service Provider, if it is available to the VPC. If one is not available, the VPC must substitute its own
name.
Page 196 of 247

NENA 08-001 v2, August 11, 2010
Parameter
Reference in
NENA 05-001
Ref. in
this doc.
Inclusion
Condition
Description/Value
the civic address

along with
Subscriber name
The VPC shall use the civic location information, if received in the response from the ERDB, to
populate the civic location information in this response message. If geo-coded location information
is received from the ERDB, geo-coded location information will be populated in the Position
Information Geographic Position parameter.
6.11.1.3 Emergency Services Position Request Response Return Error
This message is sent from the VPC to the ALI DB to inform the ALI DB that the requested action
was not performed. The Error Code contains the reason for the failure.
Table 6-24. Emergency Services Position Request Response Return Error Parameters
Parameter
Reference in
NENA 05-001
Reference
in this
document
Condition
Package Type
9.1.1
Mandatory
Transaction ID
9.1.2
Mandatory
Component Sequence
9.2.1
Mandatory
Component Type
9.2.2
Mandatory
Component ID
9.2.3
Mandatory
Error Code
9.2.5
Mandatory
Parameter Set
9.2.7
Mandatory
Description/Value
Response
Return Error
Note: No new error codes have been identified for this application.
6.11.1.4 Emergency Services Position Request Response Reject
This message is sent from the VPC to the ALI DB to inform the ALI DB that the invoke message
contains a Transaction or Component Level protocol error. The problem code describes the nature of
the protocol error.
Page 197 of 247

NENA 08-001 v2, August 11, 2010
Table 6-25. Emergency Services Position Request Response Reject Parameters
Parameter
Reference in
NENA 05-001
Reference
in this
document
Condition
Package Type
9.1.1
Mandatory
Transaction ID
9.1.2
Mandatory
Component Sequence
9.2.1
Mandatory
Component Type
9.2.2
Mandatory
Component ID
9.2.3
Mandatory
Problem Code
9.2.6
Mandatory
Parameter Set
9.2.7
Mandatory
Description/Value
Response
Reject
Note: No new problem codes have been identified for this application.
6.11.2 Emergency Services Protocol (ESP) Parameters
This section identifies the use and also differences from NENA 05-001 that shall be supported when
the v-E2 interface is implemented between a VPC and the ALI DB.
6.11.2.1 ESMEIdentification
The ESMEIdentification parameter shall be populated with the identification of the ALI requesting
the location information.
6.11.2.2 Position Information Geographic Position Parameter
If coordinate-based location information is provided to the VPC for the emergency call, this
information shall be used to populate the Position Information Geographic Position Parameter.
Specifically, the VPC shall obtain the geodetic location parameters from the PIDF-LO contained in
the LIE parameter of the Emergency Services Routing Request received by the VPC over the v2
interface as described in Section 6.3. (If the VPC receives the LIE directly from an LIS, the
following requirements apply if a geodetic object is included.) Geo-coded location information
provided by the ERDB may also be used to populate the Position Information Geographic Position
parameter. The contents of these geodetic parameters shall be mapped to the v-E2 interface
Geographic Position parameter described in Section 9.3.10.2 of NENA 05-001, with one exception,
noted below.
Page 198 of 247

NENA 08-001 v2, August 11, 2010
If the received geodetic location object information does not include altitude or uncertainty
parameters, the VPC shall use the Type of Shape and Shape description corresponding to
Ellipsoid Point
(FUTURE, for further study) If the received geodetic location object information includes
uncertainty and confidence but not altitude parameters, the VPC shall use the Type of Shape
and Shape description corresponding to Ellipsoid Point with Uncertainty.
If the received geodetic location object information includes altitude, with or without
uncertainty parameters, and the altitude type is specified as meters, the VPC shall use the
Type of Shape and Shape description corresponding to Point with altitude and uncertainty.
The degrees of latitude shall be used to populate the Degrees of Latitude in the Type of
Shape and Shape description parameter. If degrees of latitude are provided in a format
different from the one supported on the v-E2 interface, or if the degrees of latitude are
provided in a coordinate system different from the one supported on the v-E2 interface (i.e.,
WGS84), the VPC shall convert the latitude information to a format suitable for coding of
degrees of latitude on the v-E2 interface.
The degrees of longitude shall be used to populate the Degrees of Longitude in the Type of
Shape and Shape description parameter. If degrees of longitude are provided in a format
different from the one supported on the v-E2 interface, or if the degrees of longitude are
provided in a coordinate system different from the one supported on the v-E2 interface (i.e.,
WGS84[35]), the VPC shall convert the longitude information to a format suitable for coding
of degrees of longitude on the V-E2 interface.
(Future) If an Uncertainty parameter value is included and available to the VPC, the VPC
may use this information to populate the Uncertainty code and Confidence parameters of the
Type of Shape and Shape description parameter.
If an Altitude parameter is included, and the Altitude type is specified as meters, the VPC
shall use its contents to populate the Altitude in the Type of Shape and Shape description
used for Point with Altitude and Uncertainty. If uncertainty/confidence values are not
available to the VPC, when an Altitude parameter is included, the value of K for the
uncertainty code and confidence shall be populated with 0 to indicate no information. If
Altitude Uncertainty and Confidence are included, the VPC shall use this information to
populate the Altitude Uncertainty code and Confidence parameters in the Type of Shape and
Shape description parameter. If Altitude uncertainty/confidence values are not available to
the VPC, when an Altitude parameter is included, the value of K for the uncertainty code and
confidence shall be populated with 0 to indicate no information.
Exception Case - If an Altitude parameter is included, and the Altitude type is specified as
floor, the VPC shall use the use its contents to populate the Location parameter contained
in the Location Description parameter described in NENA 05-001, Section 9.3.16, subject to
the additional requirements described in Section 6.11.2.9.
Page 199 of 247

NENA 08-001 v2, August 11, 2010
6.11.2.3 Position Information - Position Source Parameter
The VPC shall use the Method parameter included in the PIDF-LO to populate the Position Source
parameter. The v-E2 interface shall support the new codings of the Position Source referred in the
shown in Table 6-26. Values of this parameter can be used by the ESME to identify this call as a
VoIP call.
If the Method parameter is not included in the PIDF-LO, the VPC shall populate the Position
Source parameter with the value corresponding to IP-Unknown.
Table 6-26. Mappings of Method token values of the PIDF-LO to codings of the Position
Source Parameter in the esposreq Response Message
Location Object parameter

(PIDF-LO: Method token**
Value)
Position
Source
parameter
value
(decimal)
<Not provided in PIDF-LO>

Manual: entered manually by an
operator or user, e.g., based on
subscriber billing or service location
information
DHCP: provided by DHCP (used for
wireline access networks, see
802.11 below)
Triangulation: triangulated from
time-of-arrival, signal strength or
similar measurements
Cell: location of the cellular radio
antenna
128
129
IP Unknown
IP Manual entry
130
IP - Network Assisted (e.g.,

via DHCP)
131
802.11: 802.11 access point (used

for DHCP-based provisioning over
wireless access networks)
132
IP Network Assisted RF
Derived (e.g., ToA,
Triangulation)
IP Radio Network Access
Point (e.g., lat/lon of cellualar
tower or of 802.11
transceiver)
IP Radio Network Access
Point (e.g., lat/lon of cellular
tower or of 802.11
transceiver)
IP - Radio Network Sector
(e.g. lat/lon of centroid of
cellular sector coverage
area, or centroid of 802.11
coverage area with
directional antennas)
IP GPS (e.g., GPS in the
handset)*
IP A-GPS (e.g., networkassisted GPS)*
132
133
GPS: Global Positioning System
134
A-GPS: GPS with assistance
135
Position Source
parameter value
meaning
Page 200 of 247

NENA 08-001 v2, August 11, 2010

(PIDF-LO: Method token**
Value)
Position
Source
parameter
value
(decimal)
136
Position Source
parameter value
meaning
Derived, via Transformation

(e.g. either Geo-Coding or
Reverse-Geo-Coding) 32
Note: The values for GPS and A-GPS are provided here separately in order for contextual distinction
that implemented systems may rely on (i.e. GPS fix for a VoIP emergency call).
** Methods Tokens assigned by the IANA can be found at
http://www.iana.org/assignments/method-tokens/
6.11.2.4 Callback Number
The Callback Number parameter shall be populated with an E.164 number that represents the
emergency caller in the i2 Solution. This Callback Number shall be derived by the VPC from the
Callback parameter of the Emergency Services Routing Request described for the v2 interface in
Section 6.3.
6.11.2.5 Emergency Services Routing Key
The VPC shall populate the Emergency Services Routing Digits Request Response parameter with
the Emergency Services Query Key received in the ESPOSREQ message and used by the VPC as a
key to obtaining the emergency call related information used in this response.
6.11.2.6 Generalized Time
The VPC shall populate the Generalized Time parameter with the time that the ESQK was allocated
to the current emergency call (with which it is associated and for which location information is being
provided).
6.11.2.7 Mobile Identification Number
The VPC may populate the Mobile Identification Number with the Main Telephone Number
(applicable in Multi-Line Telephone Systems) if one is provided for the emergency call. Otherwise,
this optional parameter can be omitted.
6.11.2.8 Company ID
The VPC shall populate this parameter with the name of the VoIP Service Provider, if available.
32 This position source parameter value can be used to indicate a geo-coded location.
Page 201 of 247

NENA 08-001 v2, August 11, 2010
6.11.2.9 LocationDescription
The VPC shall populate the Location Description parameter with the appropriate data fields tagged
using the NENA version 4 XML tags as defined in the NENA 02-010, and as described in NENA
05-001, Section 9.3.16.
The VPC shall use the information obtained from the civic address location object to populate these
fields, using the mapping described in Table 6-27. The VPC shall use the information contained in
the <customer> field of the v2 esrRequest message to populate the <NAM> field with the Subscriber
name associated with the VEP.
Table 6-27. Mappings of Civic Address Data Elements and Other Data Elements to Tagged
Fields in Location Description Parameter

(PIDF-LO: Civic Address
Type)
Populated by
the VPC
PIDF-LO: Civil: HNO

PIDF-LO: Civil: HNS
PIDF-LO: Civil: PRD
PIDF-LO: Civil: RD
PIDF-LO: Civil: STS
PIDF-LO: Civil: POD
PIDF-LO: Civil: A3
PIDF-LO: Civil: A1
NENA XML 4.0 tag in Location

Description parameter
Location Description: <HNO>
Location Description: <HNS>
Location Description: <PRD>
Location Description: <STN>
Location Description: <STS>
Location Description: <POD>
Location Description: <MCN>
Location Description: <STA>
Location Description: <COI>
PIDF-LO: Civil: County Name 33

PIDF-LO: Civil: LOC
PIDF-LO: Civil: FLR
(CAtype27)
PIDF-LO: Civil: LMK
NENA ID of the
VSP
v2 <customer>
Location Description: <LOC>*

Include "FL<content>" in LOC
<content>*
Not supported.
Location Description: <CPF>
Location Description: <NAM> 34
*NOTE: This information shall be included in the contents of the <LOC> tagged field as follows:
If included in the PIDF-LO, these fields shall be concatenated in the following order: Floor,
Location (LOC).
Each field shall be directly preceded by the indicated abbreviation (i.e., FL, LOC), and shall
be separated from the next field by the character ~ (tilde).
33 The VPC must convert the received County Name to a FIPS County Code.
34 While incorporated in the Location Description container, the name here is not associated with the physical location or the
broadband connection, but rather the VoIP service subscriber name.
Page 202 of 247

NENA 08-001 v2, August 11, 2010
If the information for a given field cannot be included completely (i.e., without truncating it),
then the last (truncated) field to be included shall also end with the character ~ (tilde) to
indicate that it has been truncated.
The VPC operator and the E9-1-1 Service Provider/Database operator should determine if an
administrative ESN value can be transmitted over the v-E2 interface without causing any detrimental
affects to the 9-1-1 system.
If supported, the VPC shall use the administrative ESN received from the ERDB to populate the
ESN tagged field in the Location Description parameter. If an administrative ESN is not available
for the call, then the VPC may use the value of the Routing ESN to populate the ESN, or shall omit
the ESN tagged value from the Location Description parameter.
6.11.3 v-E2 Message flows, Key Scenarios and Semantics
The following call flow shows a 9-1-1 call where the CS interacts with a VPC to obtain the
necessary 9-1-1 call routing information and then uses the received routing information to route the
call to the ESGW. The ESGW routes the call forward to the SR which delivers it to the PSAP. The
PSAP queries an ALI database for location information. The ALI database queries the VPC for
location information and passes it to the PSAP. Messages which pertain to the v-E2 interface are
shown in bold red.
Page 203 of 247

NENA 08-001 v2, August 11, 2010
UA
CS
VPC
PSAP
SR
ESGW
ALI
1. INVITE
(911, PIDF-LO,
callid1, SDP1)
2. 100 Trying
3. esrRequest
(PIDF-LO, [customer],
[callback])
4. esrResponse
(ert/esgwri, esqk, lro)
5. INVITE
(callid1, esgwri, esqk,
[callback], SDP1)
6. IAM
(esqk, [callback])
7. 100 Trying
8. ACM
10. 183 Session
Progress (SDP2)
11. 183 Session

Progress (SDP2)
9. Call Delivery
esqk, [callback])
12.Audible Ringing
Early Media: Audible Ringing Delivered

13. PSAP Answers
14. ANM
15. 200 OK (SDP3)
16. 200 OK (SDP3)
17. ACK
18. ACK

19. ALI Query
(esqk or callback)
20. ESPOSREQ
(esqk, [callback])
21. esposreq
(location, callback)
22. ALI Response
(Location info)
23. PSAP releases
24. REL
25. BYE
26. BYE
27. 200 OK
28. 200 OK
30. esct
(esqk, esgw, callid1)
29. RLC
31. esctAck
(vpc, callid1)
Figure 6-17 v-E2 Call Flow
Page 204 of 247

NENA 08-001 v2, August 11, 2010
1. A caller invokes an emergency call by dialing 9-1-1. The VEP sends a SIP INVITE to the
CS. In this example, location information (i.e., location-by-value) is included in the SIP
INVITE (shown as PIDF-LO) along with the SDP offer (shown as SDP1).
3. The CS uses the information received in the SIP INVITE to construct a v2 esrRequest to the
VPC.
constructs a v2 esrResponse message back to the CS with routing instructions received from
the ERDB. There are two options for what the VPC returns to the CS, depending on the
arrangement in place with the CS:
a. The VPC is responsible for the ERT-to-ESGWRI mapping. Based on the ERT received
from the ERDB, the VPC allocates an ESQK, determines the routing number (ESGWRI)
for the call, and provides this information to the CS along with the LRO. In this case, the
CS will use the ESGWRI directly for route selection.
b. The CS is responsible for the ERT-to-ESGWRI mapping. Based on the ERT received
from the ERDB, the VPC allocates an ESQK for the call and provides the ESQK and the
ERT information to the CS along with the LRO. In this case, the CS will use internal
ERT-to-ESGWRI mappings to select the proper route.
5. If the CS received an ERT, it translates the ERT to an ESGWRI. Otherwise, it uses the
ESGWRI received from the VPC to determine the outgoing route to the ESGW. The CS
sends a SIP INVITE to the ESGW with the SDP offer (shown as SDP1) and the ESGWRI.
The CS also includes an ESQK in the INVITE, sent as a URI in a PAI header. The callback
number is also sent, as a parameter in the same PAI header.
6. The ESGW uses the ESGWRI in the received INVITE message to determine the outgoing
route to the SR. In this example, the selected trunk group is an SS7 trunk group, so the
ESGW sends an SS7 Initial Address Message (IAM) to the SR. Depending on trunk group
provisioning, the IAM with either contain just the ESQK, or both the callback number and
the ESQK.
7. The ESGW also responds with a SIP 100 Trying message to the CS.
8. After the SR seizes the outgoing MF trunk and receives a wink back, it returns an SS7
Address Complete Message (ACM) to the ESGW, indicating that interworking was
encountered (with Called Partys Status set to no indication).
9. The call is delivered to the PSAP with the ESQK and/or the callback number, depending on
local signaling arrangements.
10. The ESGW signals a SIP 183 Session Progress back to the CS.
11. The CS forwards the SIP 183 Session Progress to the VEP.
Page 205 of 247

NENA 08-001 v2, August 11, 2010
Upon receiving complete ANI information, the PSAP signals the attendant and returns audible
ringing to the calling party 35. Simultaneously, upon return of the 183 Session Progress messages,
one-way communication is established between the ESGW and the UA is established to facilitate
delivery of early media/audible ringing to the UA.
12. The PSAP call taker answers the call and the off-hook signal is conveyed to the SR.
13. The SR sends an SS7 Answer Message (ANM) to the ESGW.
14. The ESGW sends a SIP 200 OK message to the CS with its SDP answer (shown as SDP2).
15. The CS forwards the SIP 200 OK message with the ESGW SDP answer to the VEP.
response and acceptance of the SDP answer.
17. The CS forwards the SIP ACK to the ESGW to confirm acceptance of the SDP answer.
The media streams are established. The caller and the PSAP call taker can now communicate.
18. The PSAP launches a location query to the ALI database. The query contains either the
ESQK or the callback number, depending on local arrangements. (Note that the ALI query
can be sent anytime after the call is delivered to the PSAP [Step 9], and likely occurs shortly
after voice communication is established.)
19. The ALI service formulates an ESPOSREQ (request) message and sends it over the v-E2
interface to the VPC. Depending on local arrangements, the ESPOSREQ will either contain
just the ESQK, or the callback number and the ESQK.
20. The VPC responds by sending an esposreq (response) message over the v-E2 interface to the
ALI service. The esposreq includes location information and the callback number.
21. The ALI service provides the location and callback information to the PSAP.
22. Some time later, the call is released (the call may be terminated from either direction
however, in this example, the PSAP hangs-up first).
23. The SR sends an SS7 Release Message (REL) to the ESGW.
24. The ESGW generates a SIP BYE and sends it to the CS.
25. The CS forwards the SIP BYE message to the VEP.
26. The VEP terminates the call then confirms reception of the call termination by sending back
a SIP 200 OK message to the CS.
27. The CS forwards the SIP 200 OK message to the ESGW.
28. The ESGW sends an SS7 Release Complete Message (RLC) to the SR, completing the
release of the call.
29. The CS constructs a v2 esct message and sends it to the VPC so it can release the ESQK and
return it to the ESQK pool.
30. The VPC responds with a v2 esctAck message back to the CS to acknowledge.
35 Note that in some implementations, the SR provides audible ringing to the caller during the outpulsing of the ANI information to
the PSAP.
Page 206 of 247

NENA 08-001 v2, August 11, 2010
6.11.4 v-E2 Interface Security
The v-E2 interface will need to operate in a variety of network environments, some trusted, and
some not, as described previously. The v-E2 interface is TCP/IP-based and should be used with a
suitable security mechanism as defined in Section 4. When the connection between the ALI DB and
the VPC is not a trusted network, both the ALI DB and the VPC are expected to be protected with
IPsec or TLS, and thus require a certificate rooted in VESA. Even in a trusted network, TLS
protection is advisable. Mutual authentication is required when cryptographic security is deployed.
Page 207 of 247

NENA 08-001 v2, August 11, 2010
Roles and Responsibilities
The organizational components of the i2 solution refer to those entities, commercial or public, which
operate the various network elements in this architecture. For example, there are those entities that
are responsible for the operation of a Call Server, those entities that are responsible for the operation
of an ESGW, and those entities that are responsible for the operation of a Selective Router. In
practice these entities may have responsibility for one or more instances of these network elements
and may have a scope which is considerably larger than just the operation of i2 defined network
elements. Thus, the entities defined here are logical ones the key in recognizing whether any of the
roles associated with these entities apply to any given real world party, is whether that party has
specific ownership and responsibility for the effective operation of the corresponding network entity.
Similarly the implementation of a specific logical network element may be such that various
components of the implementation are shared by more than one entity. In this case the owning
entities are jointly responsible and individually answerable for the effective operation of the network
element constituted by that implementation.
Caller Operates the device from which the call is made and initiates the call to emergency
services.
VoIP Service Provider (VSP) Operates the network equipment that provides call
processing for subscribers.
Redirect Operator Operates Redirect Server(s).
Routing Proxy Operator Operates Routing Proxy server(s).
LIS Operator Operates the LIS associated with the IP access network used by the callers.
ESGW Operator Operates emergency service gateway(s).
SR Operator Operates the Selective Router(s) corresponding to specific local exchange
areas.
PSAP Operator Operates the Public Safety Answering Points in a particular county, state,
or other regional jurisdiction.
ALI Operator Operates the Automatic Location Identification infrastructure used to
provide caller information associated with a pANI offered in a query from a PSAP.
VPC Operator Operates VPC network element(s).
Credential Authority An authority responsible for supporting the infrastructure to assign
and revoke electronic digital certificates to i2 network entities.
Routing Number Authority (RNA) An authority responsible for distributing ranges of
numbers to network operators for the purposes of call routing and query steering.
MSAG Source Is responsible for defining, maintaining and publishing the Master Street
Address Guide for a given coverage area.
Validation Database (VDB) Operator An operator that provides location information
validation services to LIS operators and other users.
Page 208 of 247

NENA 08-001 v2, August 11, 2010
Emergency Service Zone (ESZ) Routing Database (ERDB) Operator An operator that
supports the real time routing server that can resolve location information to emergency
service zone route at the request of a VPC.
Root Discovery Operator (RDO) - The operator that supports the well known root database
from which the URI of the correct VDB or ERDB can be determined based on regional
location information.
9-1-1 Administrator The administrative jurisdiction of a particular 9-1-1 system. This could
be a county/parish or city government, a special 9-1-1 or Emergency Communications
District, a Council of Governments, an individual PSAP or other similar body.
The different organizational entities, overlaid on their corresponding functional entities, are shown in
the following diagram.
ESGW
Operator
SR
Operator
ESGW
Routing
Number
Authority
Selective
Router
Proxy
Operator
VSP
Proxy
Server
VPC
Operator
PSAP
Call
Server
PSAP
Operator
VPC
ESQK
Source
Redirect
Server
Credential
Authority
ALI
Redirect
Operator
ERDB
Discovery
Certificate
Source
Root
discovery
operator
Client
Device
ERDB
ALI
Operator
ERDB
Operator
MSAG
Caller
VDB
Discovery
Root
discovery
operator
VDB
MSAG
Source
VDB
Operator
LIS
LIS
Operator
Figure 7-1 i2 Organizational Entities
Page 209 of 247

NENA 08-001 v2, August 11, 2010
7.1
Responsibilities
7.1.1
Caller
The caller is responsible for initiating the emergency call by inputting the appropriate emergency
service number (e.g., 9-1-1). Arbitrary VoIP devices utilized on arbitrary access networks may
not provide sufficient functionality to be properly supported by the i2 network and last resort
routing, or even failure to deliver the call to any emergency operator, may occur.
The caller may also be known as the subscriber. The caller is the individual initiating the actual
emergency call. The subscriber is the individual who nominally owns the device and service
subscription. The terms caller and subscriber may be used relatively interchangeably in the
document text depending on context.
7.1.2
VoIP Service Provider
The VoIP Service Provider (VSP) operates the Call Server/Proxy which is directly utilized by the
caller to initiate the emergency call on the v1 interface. It is the VSPs responsibility to ensure that
its call server(s) can appropriately identify that an emergency call has been invoked by the caller and
to initiate appropriate call handling. This appropriate handling includes the following:
Provide subscription-based calling party information including:

o Calling party number
o Customer name
Ensure that its call server(s) are correctly configured to identify the correct VPC, ESGW,
redirect, or proxy servers depending on options used. VSPs are responsible for routing
emergency calls towards the emergency service network using one of the following options:
o Identify and query an appropriate VPC to obtain routing information for the call and
direct the call to the ESGW indicated by that routing information through support of
the v2 and v4 interface definitions.
o Identify an appropriate redirect server and direct the call toward it and subsequently
route it as determined by that redirect server utilizing the v5 and v4 interfaces.
o Identify an appropriate proxy server and direct the call to that server utilizing the v6
interface.
In configurations where VSPs support v4 interfaces to ESGWs and choose to provide their own
ERT-to-ESGWRI mapping, VSPs will have to coordinate the mapping with ESGW operators. VSPs
are responsible for ensuring their call server(s) have access to the other network entities, whichever
options are used, such that all geographic areas from which their callers can initiate calls and which
are accessible via the i2 architecture, are serviced. This may be by their own means or by the
establishment of commercial or other arrangements with the operators of VPC, redirect, proxy, and
ESGW server entities.
Page 210 of 247

NENA 08-001 v2, August 11, 2010
7.1.3
Redirect Operator
The redirect operator maintains redirect server(s) and provides access to authorized call servers
which are in receipt of an emergency call using the v5 interface definitions. The redirect operator is
responsible for ensuring that redirect server equipment has access to VPC functionality that can
provide routing direction for all areas from which their VSP user base can originate calls.
7.1.4
Routing Proxy Operator
The Routing Proxy operator maintains proxy server(s) and provides access to authorized call servers
which are in receipt of an emergency call using the v6 interface definitions. The Routing Proxy
operator is responsible for ensuring that it can determine the appropriate routing information by
accessing relevant VPC functionality, and that it has access to the necessary ESGW infrastructure to
deliver calls for those areas.
7.1.5
LIS Operator
This operator is associated with a particular IP network access area. The LIS operator is responsible
for providing an operating infrastructure which supports requests for location information by
individual end user devices (UA) and/or properly credentialed network elements (e.g. VPC) over the
v0 and v3 interfaces respectively. The LIS operator is also responsible for providing technologies
and processes which ensure that the geographical location information provided with respect to users
is correct to within a specified range of accuracy. Where the location is effectively constrained to a
specified range, as determined by other standards, regulatory rulings, contract, etc., LIS operators are
responsible for providing a Civic Address corresponding to that location when one is applicable. LIS
operators are responsible for ensuring that this Civic Address information is properly and
independently validated with an appropriate VDB to ensure successful resolution of destination
when that address is used to route emergency calls.
7.1.6
ESGW Operator
The ESGW operator provides the equipment to interface between the IP network and the legacy
circuit switch-based emergency network. The ESGW operator is responsible for providing sufficient
and reliable capacity for the delivery of emergency calls to the Selective Router network elements in
their area of coverage. ESGW operators are responsible for ensuring that calls are placed on the
correct trunks based on the ESGWRI provided in emergency call setup signaling and in accordance
with the guidance of the corresponding SR operator as to which trunks correspond to which values
of routing information. ESGW operators are responsible for providing the appropriate signaling (i.e.,
MF or SS7, and appropriate number of digits (i.e., 10-digits [ESQK only] or 20-digits [ESQK +
callback number]) for the trunk groups over which emergency calls are to be delivered to an SR,
based on input from the SR operator. ESGW operators are responsible for ensuring that the call
server operators to whom they provide service, or VPC operators, if the translation from ERT to
ESGWRI is to be performed by the VPC, are informed which ESGWRIs are applicable to which
ESGW instances that they operate. The ESGW operator is also responsible for ensuring that the
Page 211 of 247

NENA 08-001 v2, August 11, 2010
infrastructure that they operate provides the correct default, contingency, and congestion routing
mechanisms as specified by the SR operators, PSAP operators or other authorities as applicable to
the area of service. ESGW operators are also responsible for maintaining a call record system which,
upon request from the SR operator, will allow them to identify the call server operator from which a
given call originated, identified by time and ESQK. They must support the necessary mechanisms to
block delivery of calls from specific call server operators to specific destinations at the request of SR
operators.
7.1.7
Selective Router (SR) Operators
These operators provide the infrastructure to deliver calls arriving on trunks from ESGW network
elements to the correct serving PSAP based on the routing information in the call setup signaling.
They provide the equipment to adapt to the signaling and voice bearer media (e.g. CAMA) used by
the PSAP CPE. This equipment maintains the call state between the SR and the PSAP and responds
appropriately to mid-call commands such as call transfer requests to emergency responders. The SR
operator is responsible for ensuring that correct default, contingency, and congestion call routing
functions are configured for all incoming ESGW trunks. They are responsible for ensuring that
ESQK entries in the Selective Routing Database (SRDB) are configured to support call delivery to
the correct PSAP, selective transfer, etc. based on the correct ESN associations. SR operators are
responsible for working with the VPC operator either directly or through the MSAG administrator to
ensure that ESQK block assignments are correctly associated with the appropriate ERT. SR
operators are responsible for providing the correct information associated with unique routing data to
ESGW operators that connect to the SR(s) such that those operators can provision the correct trunk,
default, contingency, and congestion routing data against each ESGWRI in their systems.
7.1.8
PSAP Operators
PSAP operators provide the call center resources which take and assess emergency calls to
determine appropriate handling of the call. They are responsible for connecting the caller to the
correct first responder organizations when necessary. They are responsible for ensuring that they
operate the necessary CPE with associated staffing capacity and reliability to serve the volume of
calls originating in their serving area. They are responsible for ensuring that they have the necessary
CPE to query ALI equipment and receive and display call related information including the callers
location.
PSAP operators provide direction in terms of the correct default routing for calls that the network
needs to support. They may also have a role in specifying the necessary ESQK block allocation sizes
on a per ESZ basis.
7.1.9
ALI Operator
ALI operators provide the infrastructure to PSAP operators to retrieve the location, ESN
information, and other call related information based on the query key that was provided for the call.
Page 212 of 247

NENA 08-001 v2, August 11, 2010
The ALI operator is responsible for providing an electronic query interface to PSAP operator CPE.
All valid query keys presented on that interface must be matched to the related call information,
including location, and presented back to the PSAP. In the case of i2 related requests, the local ALI
operator must ensure that the request is steered to the appropriate VPC over the v-E2 interface. ALI
operators are responsible for providing a reliable real-time infrastructure which can identify the
correct VPC to which to steer the query based on the presented ESQK, format a valid ESPOSREQ
message and to receive and process the esposreq response. The ALI operator is responsible for
ensuring that the ALI database maintains correct ESQK-to-VPC steering data such that any valid
ESQK presented as a query key can be matched to an appropriate VPC. The steering data must be
sourced from the VPC operator. ALI operators are responsible for maintaining records of queries to
facilitate historical analysis including identification of calls by time and ESQK assignment, and
content and status of request/response messages as they occurred.
ALI operators are responsible for ensuring that the responses received from the VPC are correctly
formatted and presented to the PSAP CPE.
7.1.10 VPC Operator
The VPC operator provides robust infrastructure which allows the routing information for a given
emergency call to be determined based on the location of the caller, and maintains the call
information, caller location information, and corresponding routing information, based on the
information received from the Call Server/Proxy via the v2 interface, from the ERDB via the v8
interface, and from the LIS via the v3 interface (if applicable). In configurations where VPCs
provide ERT-to-ESGWRI mapping, VPCs will have to coordinate the mapping with ESGW
operators. The VPC operator will be responsible for having mechanisms in place to respond to ALI
queries for location information. VPC operators will also be responsible for ensuring that any
MSAG-valid formatted civic location information or geo-coded location information received from
the ERDB in response to a routing query is stored at the VPC for inclusion in the response to the
ALI database. In addition, they are responsible for ensuring they have the infrastructure in place to
direct location queries to any applicable LIS interface when presented with a location key.
The VPC operator is responsible for ensuring that the VPC equipment supports compatible E2
interface capabilities to support ALI queries. The VPC operator must ensure that the necessary
processes and mechanisms are in place to obtain ESQK allocations from the RNA, to determine the
correct ERT-to-ESQK sub-block associations, and to make the E2 interface connections accessible
from authorized ALI operators. Where it is required to do so, the VPC operator must also ensure that
the ESQK allocations appropriate to each of its VPC instances is communicated to the ALI operator
in order that they can maintain a correct VPC steering database.
VPC operators are responsible for ensuring that any PSAP policies on call handling are applied with
respect to default routing when a location information source cannot be verified, or where location
information type (geodetic and/or civic) or content is limited. The VPC operator is responsible for
ensuring that last resort routing data is defined and that equipment is configured to provide this
Page 213 of 247

NENA 08-001 v2, August 11, 2010
information in response to v2 interface queries when no more applicable route can be identified for
the call.
VPC operators are responsible for maintaining 24x7 telephone response service such that PSAP
operators can contact them for details of a particular call in the event of failure of an ALI query or in
order to determine the identity of the originating call server operator and to facilitate communication
with that operator in the event that assistance is needed to make contact with the caller. The VPC
operator is also responsible for maintaining historical records of all calls such that similar
investigations can be conducted at arbitrary points in the future.
7.1.11 Credential Authority
The credential authority is responsible for providing certificates to appropriately qualified call
server, VPC, ESGW, LIS, ERDB, and VDB operators. These digital certificates are to be provided
as and when they are needed to ensure that authentication can occur over the i2 defined interfaces
and so that location information can be digitally signed and checked for source of origin by network
elements within the i2 architecture.
It is the responsibility of credential authorities to ensure that certificates are securely generated,
distributed, and maintained. Where necessary, they are also responsible for the withdrawal and
cancellation of certificates.
Two types of credential authority are defined VESA and the delegate authorities.
Certificate
Source
VESA
Credential
Authority
Delegation
Delegate
Credential
Authority
Certificate
Source
Delegate
Credential
Authority
Certificate
Source
Delegate
Credential
Authority
Certificate
Source
Figure 7-2 Organizational Decomposition VESA and Delegate Credential Authorities
Page 214 of 247

NENA 08-001 v2, August 11, 2010
7.1.11.1 Valid Emergency Services Authority (VESA)
This organization is the root source of all certificates. It is responsible for identifying and issuing
certificates either directly to end using entities or through delegate credential authorities. It is
responsible for ensuring that any delegate credential authority that it identifies is properly qualified
and operating with sufficient security and legitimacy to perform this role. Where VESA issues
certificates directly to end users, it also has the responsibilities of a delegate credential authority in
those cases.
VESA is also responsible for maintaining a master revocation list for all end entities that have had
their certificates revoked for any reason. It must provide a means for the delegate credential
authorities to populate the list. This list must be made available electronically to all organizational
entities which need to validate data based on VESA root certificates.
7.1.11.2 Delegate Credential Authorities
A delegate credential authority issues certificates, which are derived from VESA certification. It is
responsible for issuing certificates to the operators of network entities that utilize VESA certificates
for the exchange of authenticated data on the i2-defined interfaces.
Delegate credential authorities are responsible for ensuring that the organizations involved in the i2
architecture are properly equipped in infrastructure and operating processes to meet the demands of
reliable emergency call delivery and processing from VoIP networks before issuing certificates.
They should operate an appropriate process of assessment and renewal audit, in order to assess these
organizations and validate their suitability to participate in the i2 network. Part and parcel of this
responsibility is the generation and provision of electronic digital certificates which are required for
the purposes of authentication and authorization between the various network entities comprising the
i2 architecture.
Delegate credential authorities are also responsible for identifying when a given certificate needs to
be revoked (where an entity no longer meets the requirements of eligibility for the certificate for
example, when it ceases operation). When a certificate is identified as being revoked or expired, this
information must be communicated to the VESA so the certificate can be included in the master
revocation list.
Examples of delegate credential authorities may be PSAP operators, state emergency authorities, or
regional 9-1-1 service providers.
7.1.12 Routing Number Authority (RNA)
The RNA is responsible for distributing ranges of numbers from a reserved number space to
properly credentialed network element operators for the purposes of call routing and query steering.
The RNA issues multiple discrete blocks of ESQK allocations to VPC operators from a reserved
numbering space defined for this purpose. The routing number authority is responsible for ensuring
the uniqueness and correctness of the numbers allocated and the corresponding information
Page 215 of 247

NENA 08-001 v2, August 11, 2010
associated with each number. They are responsible for ensuring that the VPC instances against
which allocations are made are properly credentialed and approved to provide emergency call
routing service. They are also responsible for polling these organizations to ensure that they are still
credentialed and, where necessary, for reclaiming ESQK allocations from VPC operators as VPCs
go out of service.
7.1.13 Master Street Address Guide (MSAG) Source
The MSAG source represents the organizational components that are responsible for performing the
division of an emergency coverage area into the individual emergency service zones (ESZ), and the
association of ESN lists to those zones. The ESZ must be defined in terms of civic address
boundaries incorporating the necessary postal and 9-1-1 field formatting. The definitions may further
support the division by geo-spatial boundaries 36. The MSAG source is required to make this
information available to authorized ERDB operators, VDB operators, PSAP and SR operators and
any other concerned parties who require this fundamental information. The MSAG source is
expected to have the necessary infrastructure in place to ensure that the MSAG data is kept current
and synchronized and that updates are made available in an electronic form to authorized parties in a
timely fashion. The MSAG source can be devolved into two specific organizational entities.
MSAG
MSAG
Data
DB MSAG Source
MSAG
Operator
MSAG
Admin
Figure 7-3 Organizational Decomposition - MSAG Source
7.1.13.1 MSAG Administrator

The MSAG administrator is the component of the MSAG source that is responsible for determining,
documenting, and maintaining the actual MSAG data. This includes the local level activities to
36 Note that in order to support future devices that may only be able to be provided location as a geodetic location (e.g., devices that
support IETF RFC 3825 or mobile wide area wireless Internet access devices), there needs to be a geospatial boundary equivalent of
the MSAG. As in the case of cellular, the logical ESZ boundary may be of lower resolution, for example it may be the PSAP
boundary, in which case the ESN associated with this logical ESZ would indicate "query caller" as it does for cellular telephony
access.
Page 216 of 247

NENA 08-001 v2, August 11, 2010
understand ESZ boundary break downs and associated ESN lists. The MSAG Administrator is
responsible for maintaining the civic data in the MSAG. The MSAG Administrator is also
responsible for creating and maintaining the geo-spatial representation of ESZ boundaries. They are
responsible for liaising with the SR operators in the area of coverage to assist the SR operators in
determining which ERT values correspond to the ESZ allocations. They provide the data to the
MSAG operator for the actual electronic storage and distribution of the MSAG data.
7.1.13.2 MSAG Operator
The MSAG operator maintains the database equipment and infrastructure that supports the access
and retrieval of the MSAG data by authorized parties. They must provide the necessary
infrastructure for the MSAG administrator to ensure that the data can be updated. They must ensure
that the database itself remains reliable, uncorrupted, and secure from unauthorized access. The
MSAG Operator that provides access to the civic data of the MSAG may be different from the
MSAG Operator that provides access to the geo-spatial ESZ boundary data for the MSAG.
7.1.14 Validation Database (VDB) Operator
The VDB operators are responsible for providing the service by which LIS operators and other
authorized categories of users in their area of operation can submit access network location
information over the v7 interface for validation. Validation checks will ensure that the location
information will successfully key into the current MSAG in support of call routing. VDB operators
are responsible for providing an effective electronic means of performing validation and providing
assistance in correcting non-valid information. They must ensure that the validation occurs against
the current version of the MSAG. They are responsible for ensuring that the root discovery operator
is informed of the availability of their service and the regional coverage it provides to support
reliable discovery by users. When changing the URI of their infrastructure, they are responsible for
ensuring that old URIs are maintained for an overlap period and the RDO is informed of the
associated expiry and activation times.
The VDB operator should liaise with neighboring operators and resolve areas of overlap based on
regional coverage as identified in the root discovery information (see section on RDO).
7.1.15 Emergency Routing Database (ERDB) Operator
The ERDB operators are responsible for ensuring that reliable infrastructure with the necessary
performance to support real time routing queries over the v8 interface is available to authorized VPC
operators. They must ensure that the routing queries can occur using either the civic address or
geodetic boundary information contained in the MSAG that corresponds to the location in the query.
They must also support default routing procedures consistent with the policies of the associated 9-11 Authority.
The ERDB operator is responsible for working with SR operators, PSAP operators and other parties
as necessary to ensure that ESZ boundaries are associated with correct ERT values that will be used
as the basis of call routing and that the correct ERT is provided in response to a routing request.
Page 217 of 247

NENA 08-001 v2, August 11, 2010
They are responsible for ensuring that the US postal address format for civic address keying of the
routing database has a corresponding correct MSAG format for providing to the VPC in the v8
interface routing response.
They are responsible for ensuring that the root discovery operator is informed of the availability of
their service and the regional coverage it provides in order that they can be reliably discovered by
users. When changing the URI of their infrastructure, they are responsible for ensuring that old URIs
are maintained for an overlap period and the RDO is informed of the associated expiry and
activation times.
The ERDB operator should liaise with neighboring operators and resolve areas of overlap based on
regional coverage as identified in the root discovery information (see section on RDO). That is,
where ambiguity may arise in the root discovery data because of sub-municipality splits in ERDB
operator coverage, the operator may make arrangements to proxy routing requests for these areas of
overlap. The ERDB operators are responsible for maintaining records of all routing requests
including results and status against time and the identity of the requesting VPC entity.
Note that trunk group configurations at the ESGW are transparent to the ERDB.
7.1.16 Root Discovery Operator (RDO)
This is a singleton organizational entity in the architecture. That is, it is assumed that the functions
supported by this entity can be accessed by a single well known network address (URI). The RDO is
responsible for maintaining and making available the identities of the key VDB and ERDB functions
in the network. This information is to be maintained as current and made available to all requesting
entities. The RDO is responsible for ensuring that updated versions of the data with specific
activation and expiry times are available. New versions of data must always be made available
before current versions expire. The RDO is not responsible for discovering ERDB and VDB
operators itself, but it is responsible for providing the means to have discovery information reliably
communicated by those entities in an electronic form. The RDO is responsible for consolidating the
discovery information as received by all VDB and ERDB operators, negotiating coordinated
activation and expiry intervals, and making this consolidated information available for access over
the v9 interface. The RDO can be organizationally devolved into the ERDB RDO and the VDB
RDO as these functions have discrete user bases and separate root URI values may be assigned to
each function.
7.1.17 9-1-1 Administrator
The 9-1-1 Administrator represents the administrative jurisdiction for a particular 9-1-1 system. This
could be a county/parish, city or state government, a special 9-1-1 district, an Emergency
Communications District, a Council of Governments, an individual PSAP or other similar body. In
addition to its other responsibilities, the 9-1-1 Administrator is responsible for ensuring that 9-1-1
service is made available to users of NG9-1-1 services in accordance with this NENA standard.
The Role and Responsibilities of the 9-1-1 Administrator include:
Page 218 of 247

NENA 08-001 v2, August 11, 2010
Establish administrative process/implementation plan for accommodating VoIP Service

Providers, including VPC and ESGW operators.
Identify and describe the jurisdictional boundary and point of contact for each jurisdiction
Designation/Selection of ERDB/VDB operator(s)
Provide common point between MSAG operator(s) and VDB/ERDB operator(s)
Ensure distribution of MSAG data to authorized users (either themselves or their designated
agent)
Providing geodetic data to authorized users (either themselves or their designated agent)
Establish trunking criteria for ESGW operators and ensure access to selective router(s)
Establish default routing criteria, including CRNs for PSAPs
Review/approve ESQK numbering resource requests from VPC operators
Ensure timely response to new VPC/VSP/ESGW deployments
Coordinate testing for VPC/VSP deployments, either themselves or their designated agent
provides this function
Ongoing quality control interaction with VPCs, ESGWs, VSPs and E9-1-1 System Service
Providers (SSPs).
Page 219 of 247

NENA 08-001 v2, August 11, 2010
Recommended Reading and References
This issue contains references to documents which were work in progress (e.g., Internet Draft at
the IETF) at the time of writing. This document may be revised as these references stabilize.
[1] IETF RFC 1032, Establishing a Domain Guidelines for Administrators, M. Stahl, November
1987.
[2] IETF RFC 1033, Domain Administrators Operations Guide, M. Lottor, November 1987.
[3] IETF RFC 1035, Domain Names Implementation and Specification, P. Mockapetris,
November 1987.
[4] IETF RFC 2131, Dynamic Host Configuration Protocol, R. Droms, March 1997.
[5] IETF RFC 3261, SIP: Session Initiation Protocol, J. Rosenberg et al, June 2002.
[6] IETF RFC 3825, Dynamic Host Configuration Protocol Option for Coordinate-based Location
Configuration Information, July 2004
[7] IETF RFC 4776, Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for
Civic Addresses Configuration Information, H. Schulzrinne, November 2006.
[8] IETF RFC 4119, A Presence-based GEOPRIV Location Object Format, J. Peterson, December
2005
[9] Void
[10] Void
[11] NENA 02-010, NENA Standard Data Formats for ALI Data Exchange & GIS Mapping,
Version 8.2, June 10, 2009
[12] IETF Internet Draft, Location Conveyance for the Session Initiation Protocol, J. Polk & B.
Rosen, draft-ietf-sipcore-location-conveyance
[13] NENA 05-001, Implementation of the Wireless Emergency Service Protocol E2 Interface, Issue
1, December 2, 2003
[14] IETF RFC 2313, PKCS #1: RSA Encryption, Version 1.5, March 1998
[15] IETF RFC 3280, Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile, April 2002
[16] NIST FIPS PUB 197, Advanced Encryption Standard, November 2001
[17] IETF RFC 4301, Security Architecture for the Internet Protocol, S. Kent & K. Seo, December
2005
[18] IETF RFC 5491, GEOPRIV PIDF-LO Usage Clarification, Considerations and
Recommendations, J.Winterbottom, M. Thomson, H. Tschofenig, March 2009
[19] IETF RFC 3174, US Secure Hash Algorithm 1 (SHA1), D. Eastlake, 3rd et al, September 2001
[20] RSA-1024, A Method for Obtaining Digital Signatures and Public-Key Cryptosystems, R.L.
Rivest et al, September 1, 1977
Page 220 of 247

NENA 08-001 v2, August 11, 2010
[21] ITU-T Recommendation X.509, Information Technology Open Systems Interconnection The
Directory: Public-key and attribute certificate frameworks, November 2008
[22] IETF RFC 4346, The Transport Layer Security (TLS) Protocol Version 1.1, T. Dierks & E.
Rescorla, April 2006
[23] IETF RFC 5246, The Transport Layer Security (TLS) Protocol, T. Dierks, E. Rescorla, August
2008
[24] IETF RFC5031, A Uniform Resource Name (URN) for Emergency and Other Well-Known
Services, H. Schulzrinne, January 2008
[25] ANSI/TIA-1057, Link Layer Discovery Protocol for Media Endpoint Devices, April 2006
[26] IETF Internet Draft, HTTP Enabled Location Delivery (HELD), M. Barnes Ed., draft-ietfgeopriv-http-location-delivery
[27] NENA 08-752, Technical Requirements Document (TRD) for Location Information to Support
IP-Based Emergency Services, Issue 1, December 21, 2006
[28] NENA 08-505, Recommended Method(s) for Location Determination to Support IP-Based
Emergency Services, Issue 1, December 21, 2006
[29] VOID
[30] IETF RFC 1034, Domain Names Concepts and Facilities, P. Mockapetris, November 1987
[31] IETF RFC 3265, Session Initiation Protocol (SIP)-Specific Event Notification, A. B. Roach,
June 2002
[32] NENA 03-503, SS7 Guidelines for Wireline and VoIP Emergency Services Gateway
Interconnection to 9-1-1 Selective Routers, Issue 1, October 20, 2005
[33] IETF RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1, R. Fielding & al, June 1999
[34] TIA J-STD-036-B-2005, Enhanced Wireless 9-1-1 Phase 2, June 2005
[35] NIMA TR8350.2, Department of Defense World Geodetic System 1984 Its Definition and
Relationships with Local Geodetic Systems, Third Edition, Amendment 2, January 2004
[36] TIA J-STD-036-A-2002, Enhanced Wireless 9-1-1, Phase 2 (ANSI/J-STD-036-A-2002)
(superseded by J-STD-036-B-2005), June 2002
[37] IETF RFC 5139, Revised Civic Location Format for Presence Information Data Format
Location Object (PIDF-LO), M.Thomson, J. Winterbottom, January 2008
[38] NENA 02-013, Data Standards for the Provisioning and Maintenance of MSAG Files to VDBs
and ERDBs, Version 3, June 7, 2008
[39] NENA 00-001, Master Glossary of 9-1-1 Terminology, Version 12, July 15, 2009
[40] IETF RFC 3325, Private Extensions to the Session Initiation Protocol (SIP) for Asserted
Identity within Trusted Networks, C. Jennings & al, November 2002
[41] IETF RFC 3966, The tel URI for Telephone Numbers, H. Schulzrinne, December 2004
Page 221 of 247

NENA 08-001 v2, August 11, 2010
[42] OGC 06-142r1, GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet
Engineering Task Force (IETF), version 1.0, April 10, 2007
[43] IETF Internet Draft, Requirements for a Location-by-Reference Mechanism, R. Marshall, Ed.,
draft-ietf-geopriv-lbyr-requirements
[44] ISO 8601:2004, Data elements and interchange formats Information interchange
Representation of dates and times, Third Edition, December 2004
[45] NENA 03-005, Generic Requirements for an Enhanced 9-1-1 Selective Routing Switch, Issue 1,
January 15, 2004
[46] Void
[47] Void
[48] Void
[49] ANSI T1-628a-2001 (R2005), ECS Connection and Ring Back Addendum, American National
Standard Institute
[50] ANSI T1-666-1999 (R2004), Signaling System Number 7 (SS7) Operator Services Network
Capabilities, American National Standard Institute
[51] IETF RFC 4235, An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol
(SIP), J. Rosenberg, H. Schulzrinne, R. Mahy Ed., November 2005
[52] IETF Internet Draft, Best Current Practice for Communications Services in support of
Emergency Calling, B. Rosen & J. M. Polk, draft-ietf-ecrit-phonebcp
[53] ITU-T Recommendation E.164, http://www.itu.int/rec/T-REC-E.164-200502-I/en
[54] ATIS-0300089 P-ANI Administration Guidelines, http://www.atis.org/inc/wkdocs.asp
Page 222 of 247
NENA Interim VoIP Architecture for Enhanced

9-1-1 Services (i2)
NENA 08-001 Version 2, (Board Approval Date)
Exhibits (Informative)
9.1
Potential ALI Changes
9.1.1
Purpose
This section provides a list of potential system changes on the ALI that could be considered
when implementing the i2 solution.
9.1.2
Overview
The initial i2 deployment will be similar to Wireless Wireline Compatibility Mode as specified
in J-STD-036. The VoIP provider will deliver an ESQK into the 9-1-1 Network. The PSAP will
query the local Emergency Services Message Entity, the ALI system, with the ESQK. Once the
ESME receives the ESQK from the PSAP it will query the VoIP Positioning Center (VPC) using
the E2+ message format as implemented over the v-E2 interface. This implementation approach
may necessitate software changes to an ESME that is currently supporting an E2 NCAS
deployment only. NENA 080-001, Issue 2, allows for 20 digits (i.e., ESQK + Callback
Number) to be delivered to the SR, and included in the v-E2 ESPOSREQ (query) message sent
to the VPC.
The E2 NCAS deployment allows for the delivery of the Callback Number and Emergency
Services Routing Digit to the PSAP (Format B within J-STD-036-B). In the E2 NCAS
deployment the callers geodetic location is obtained from the Mobile Positioning Center and the
data associated with the Emergency Services Routing Digits, as stored within the ESME, is used
for the cell site address. This differs from a deployment that uses the E2+ message format. When
the E2+ message format is used, the VPC is responsible for delivery of the Callback Number and
will place the civic address of the VoIP caller into tagged fields of the E2+ Location Description
parameter.
9.1.3
Potential Changes Required to Support i2 Solution
The following list is informative. The Pubic Service Agency should consult with their 9-1-1
System Service Provider to obtain an analysis of the potential changes required for implementing
the i2 solution. This text is meant to be used for discussion between the PSAP and the ALI
provider.
Implement E2+ query based on ESQK or ESQK + Callback Number. ESQK shall be
placed into the ESRK field of Emergency Services Protocol message. Since the ESQK
will have the same form and function as the ESRK, there will be no change to the
existing ESRK field. The Callback Number, if included will be placed in the Callback
Number Request parameter of the ESPOSREQ message, as described in Section 9.3.4
of NENA 05-001.
Implement parsing of tagged fields in the E2+ Location Description parameter into the
ALI format.
o Determine if any E2+ fields should not be used.
Version 2, (Board Approval Date)
Page 223 of 247

9-1-1 Services (i2)
o Determine approach for using ESN returned in E2+ response and how agency names
will be displayed.
o Review the <LOC> tag and any data elements delivered in this field.
Determine if any conflict exists with existing ALI format.
o Determine if there are any embedded labels in the ALI format that may need to be
accounted for when parsing the VoIP data.
Review VoIP Class of Service values and determine if any changes need to be made in
call detail reports or Computer Aided Dispatch systems.
Determine if the E2+ Position Source or ALI ESQK shell record shall be used to create a
VoIP Class of Service.
o Ensure that the VoIP Position Source value(s) are NOT interpreted as wireless values.
Determine if the existing ALI format has any conflicts for displaying geodetic Location
and Civic Location fields at the same time. This may be an issue if your existing ALI
format has multi use fields.
o Determine if a VoIP position source or Class of Service can be used to prioritize
when a Geo Location or Civic Location should be displayed.
Determine if there is a need for additional ALI text messages.
o ESME should have the ability to distinguish when steering is done to a MPC or a
VPC. This will be necessary to ensure wireless text messages are not created for VPC
responses.
Page 224 of 247

9-1-1 Services (i2)
9.2
Rules for Address Abbreviation
9.2.1
Resources for Abbreviation Matching
USPS Publication 28 can be found at the following link:

http://pe.usps.gov/cpim/ftp/pubs/Pub28/pub28.pdf
The Canadian Postal Guide can be found at the following link:
http://www.canadapost.ca/business/offerings/address_management/pdf/addressing_guide-e.pdf
The following table is excerpted from USPS Publication 28 to show variations in Street Suffix
Abbreviations. The suffix name of AVENUE was picked for illustration purposes only.
Primary Street Suffix

Name
AVENUE
Commonly Used Street

Suffix or Abbreviation
AV
AVE
AVEN
AVENU
AVENUE
AVN
ANVUE
Postal Service Suffix

Abbreviation (USPS Pub
28, Appendix C)
AVE
Table 9-1: Street Suffix Abbreviation
The VDB must be able to translate AV, AVE, AVEN, AVENU, AVENUE, AVN and ANVUE
to the USPS accepted abbreviation of AVE.
Address received
over the v7
Result Code
OAK AVE
OAK AV
Oak Ave
OAK AVE.
100 (Success)
102 (Alt returned)
102 (Alt returned)
102 (Alt returned)
Address contained
in the MSAG and
returned over v-E2
OAK AVN
OAK AVN
OAK AVN
OAK AVN
Address returned
over the v7
OAK AVE
OAK AVE
OAK AVE
OAK AVE
Table 9-2: Examples of Street and Street Suffix Names as input/outputs over v7
9.2.1.1
Additional Validation Functionality
The VDB may optionally do more than matching based on a standardized list. For example, if a
VDB receives AVINU, it could decide to associate and return AVE in the v7 response. The
limit of this VDB functionality should be incumbent on the specific implementation.
Page 225 of 247

9-1-1 Services (i2)
9.3
MSAG to Postal Address Comparison
This appendix is provided for informational purposes only. The intent of the appendix is to
illustrate the fact that postal addresses and MSAG addresses are very often different and it is the
MSAG address which is required to ensure proper dispatch at the PSAP.
Information for VDB Developers
Example using actual MSAG data; postal addresses were looked up at
http://www.satorisoftware.com/US/addresscheck/AddressCheck.asp.
These are just some customer address examples pulled at random from MSAGs around the
country (no searches were done to find examples likely to not match to Postal addresses). Based
on this tiny sample it appears that conformity to Postal addresses is going to vary widely from
MSAG to MSAG with most MSAGs being very different from the Postal.
Variations of Andover in MSAG (each of these variations will have a different set of valid streets
and addresses associated with them):
Community
ANDOVER
BORO
ANDOVER
BORO
ANDOVER TWP
County
SMST
State
NJ
SUSX
NJ
SUSX
NJ
MSAG Address
18 AMBLER LANE
ABERDEEN TWP, NJ
Postal Address
18 Ambler Ln
Matawan NJ 07747-1225
County name: Monmouth
1 CLIFFSIDE WAY
ANDOVER TWP NJ
1 Cliffside Way
Andover NJ 07821-5042
County name: Sussex
400 US HWY NO 206

ANDOVER NJ
Lookup failed with or

without zip
Comment
Note that Postal City does not match
MSAG City.
Postal lookup failed if zip not supplied
using city name ABERDEEN TWP;
worked without zip if TWP omitted.
Note that Postal City does not contain
TWP.
using city name ANDOVER TWP;
worked without zip if TWP omitted.
Mapquest returned: You searched for
"400 us hwy no 206, andover, nj
07860", MapQuest did not find this
exact address, but found one very
similar: "400 Us Highway 206 S,
Page 226 of 247

9-1-1 Services (i2)
MSAG Address
Postal Address
301 W 1ST AVE

BARRINGTON BORO
NJ
301 W 1st Ave

Barrington NJ 080071206
County name: Camden
17 Avenue A
Newark NJ 07114-2661
County name: Essex
2184 Azalea Ave
Sea Girt NJ 08750-2401
County name: Monmouth
17 AVENUE A ST
NEWARK CITY NJ
2184 AZALEA AVE
WALL TWP NJ
10 ACADEMY DR E
HANOVER TWP NJ
10 Academy Dr E
Whippany NJ 079811801
County name: Morris
2948 HIGHWAY 72 E
ABBEVILLE, ABB, SC
2948 Highway 72 E
Abbeville SC 296205258
County name: Abbeville
4216 Taylor Creek Rd
Afton VA 22920-2159
County name: Albemarle
105 E Holland St
Archbold OH 435021210
County name: Fulton
without zip
4216 TAYLOR CREEK

RD
AFTON, ALB, VA
105 E HOLLAND
ARCHBOLD, FUL, OH
921 LIGHTHOUSE
CHURCH RD
BAKER, OKA, FL
132 BANDERA CIR

BANDERA BAY, HEN,
TX
132 Bandera Cir

Mabank TX 75156-8920
County name: Henderson
Comment
Newton, NJ 07860-6002".
using city name BARRINGTON
BORO; worked without zip if BORO
omitted.
Note that Postal City does not contain
CITY
MSAG City.
The MSAG has a few streets in it for
Sea Girt, NJ Azalea Ave is not one
of them.
using city name WALL TWP; worked
without zip if TWP omitted.
MSAG City.
Whippany, NJ is not in the MSAG
using city name HANOVER TWP;
worked without zip if TWP omitted
Mapquest returned:
You searched for "921 LIGHTHOUSE
CHURCH RD, BAKER, FL 32531",
MapQuest did not find this exact
address, but found one very similar:
"Baker, FL 32531".
MSAG City.
Page 227 of 247

9-1-1 Services (i2)
MSAG Address
31496 330TH ST
BARNARD, NOD, MO
Postal Address
31496 330th St
Barnard MO 64423-8240
County name: Nodaway
139 SAWYERS CREEK 139 Sawyers Creek Rd
RD
Camden NC 27921-7507
CAMDEN, CAM, NC
County name: Camden
32995 TERRACE VIEW Lookup failed with or
RD
without zip
CAPE KIWANDA, TIL,
OR
493 SIMCOE MTN RD

CENTERVILLE, KLI,
WA
8620 N CR 800 E
DECATUR, WLS, IN
34 DUNKARD
CHURCH RD
DELAWARE TWP,
HUNT, NJ
1463 RD 51 E
DIX, KIM, NE
1720 SCIOTO RD
ELIZABETHTON, UNI,
TN
493 Simcoe Mountain Rd

Centerville WA 986132906
County name: Klickitat
without zip
34 Dunkard Church Rd
Stockton NJ 08559-1405
County name: Hunterdon
1463 Road 51 E
Dix NE 69133-8920
County name: Kimball
1720 Sciota Rd
Elizabethton TN 376431904
County name: Carter
2261 COMERS ROCK

RD
ELK CREEK, GRA, VA
Comment
Mapquest returned:
You searched for "32995 Terrace View
Rd, Cape Kiwanda, OR 97135", MapQuest
did not find this exact address, but
found one very similar: "Pacific City, OR
97135".
Mapquest returned:
You searched for "8620 N CR 800 E,
DECATUR, IN 46733", MapQuest did not
find this exact address, but found one
very similar: "8620 N 800 E-90, Decatur,
IN 46733-9202".
MSAG City.
Street name changed counties are

different; this is probably not a match
Mapquest returned:
You searched for "1720 SCIOTO RD,
ELIZABETHTON, TN 37643", MapQuest
did not find this exact address, but
found one very similar: "Elizabethton,
TN 37643-1904".
street number or box number out of
range
Mapquest returned:
Map of the address
Page 228 of 247

9-1-1 Services (i2)
MSAG Address
13228 US 24
EMERALD TWP, PAU,
OH
Postal Address
13228 US 24
Cecil OH 45821-9401
County name: Paulding
Comment
MSAG City.
Page 229 of 247

9-1-1 Services (i2)
9.4
ERDB Discovery Using Geodetic Information
ERDB discovery consists of sending location information to a root discovery node and being
returned the URI of an ERDB that can provide routing information for the associated call.
Geodetic information is normally expressed as an area or volume, so in border areas it is
possible, indeed quite likely, that the geodetic area representing the location of the caller may
span more than one ERDB. In this case the VPC will receive more than one ERDB URI.
Expressing service areas using geodetic coordinates to define a polygon is a relatively common
practice today to describe PSAP service boundaries. Errors in boundary specification between
two adjacent service areas may result in 'holes', areas in which neither PSAP will claim coverage,
or overlap where more than one PSAP would claim coverage. As of the time of writing it is
acknowledge that some geodetic PSAP boundary errors can range between 10 and 30 meters.
Figure 9-1 illustrates a typical ERDB service area polygon.
Figure 9-1: ERDB Service Area Polygon
9.4.1
Polygon Definition
As described earlier, geodetic representations for PSAP boundaries today can have errors in
coverage ranging from 10 to 30 meters, and these can result in coverage gaps where a caller may
not be able to reach a PSAP. In an attempt to overcome these problems, specific measures are
put in place for ERDB area definitions.
A minimum polygon vertex precision is required. 4 decimal places is the recommended

as minimum as this places the error at around 10 meters.
A deliberate ERDB boundary overlap is required.
Where area vertices are expressed to 4 decimal places, a boundary overlap of 50 meters is
required.
Page 230 of 247

9-1-1 Services (i2)
Geodetic locations are most likely to be provided to, or by mobile devices. High accuracy
geodetic locations using A-GPS systems typically yield a location with an uncertainty radius of
around 30 meters or better. Providing an overlap of 50 meters will result in a significant
reduction in the chance of misrouting a call, but will also result in almost no chance for the
existence of coverage gaps. Where ERDB boundaries are known to be of extremely high
precision, or frequent misrouting is known to occur, the degree of overlap between service areas
can be reduced. A safety net of 50 meters overlap however is recommended as the norm.
Specific polygon definition rules are as follows:
1. Polygons must be expressed in 2 dimensions using the EPSG:4326 coordinate reference
system.
2. Polygons must be defined with the upward normal being in the upward direction. To
accomplish this, polygon vertices must be defined in a counter-clockwise direction.
3. Lines between adjacent polygon vertices are minimum distance (geodesic).
4. Polygons must be closed areas, with the first and last points in the definition being the
same.
5. A connecting line SHALL NOT cross another connecting line.
6. Two successive points must not be diametrically opposed on the ellipsoid.
7. This definition does not permit connecting lines greater than roughly 20,000 km. If such a
need arises, the polygon can be described by adding an intermediate point.
8. There are no restrictions on the number of points that may be used to represent a service
area polygon.
9.4.2
Endpoint (Subscriber) Location Representation
Endpoint geodetic location information in this specification is provided from the VPC to the
ALI/PSAP over the v-E2 interface, which reuses the E2 specification [34] in existence for
cellular wireless. This interface restricts the formats of geodetic information to:
ellipsoid point (latitude, longitude)
ellipsoid point with altitude (latitude, longitude, altitude)
ellipsoid point with uncertainty radius (latitude, longitude, radius)
ellipsoid point with altitude and uncertainty radius (latitude, longitude, altitude, radius).
Since location conveyance to the PSAP is restricted to these forms, these will be the supported
locations for acceptance by the ERDB root discovery server. Location is provided inside a
PIDF-LO [8][37] document to the VPC, and it is expected that the geodetic location information
be constricted to the shapes and forms defined in the GeoShapes specification [42]. The
GeoShapes specification supports a number of shapes in addition to those supported by the v-E2
and ERDB root discovery interface. If the VPC receives a shape other than one that is acceptable
to the ERDB root discovery node, the VPC must either convert the shape to an acceptable form
without loss of coverage, or provide some kind of default routing for the call 37. The VPC must
not provide the unacceptable shape type to the ERDB root discovery node. Valid GeoShapes,
37 These conversions can and do occur today in GMLCs and MPCs that operate in cellular wireless networks, as location
determination techniques vary across carrier deployments and technologies.
Page 231 of 247

9-1-1 Services (i2)
and their v-E2 equivalents are provided in Error! Reference source not found.Table 9-1-1,
where a GeoShape requires conversion this is clearly indicated.
Geo Shape
Type
Point
v-E2 Shape Equivalent
VPC Actions
Ellipsoid Point
Ellipsoid Point with altitude
Pass to Root
Discovery
Server
Circle
Ellipsoid Point with

Uncertainty radius
Sphere
Ellipsoid Point with Altitude

and Uncertainty radius
Pass to Root
Discovery
Server
Pass to Root
Discovery
Server
Conversion 38
Required
Conversion
Required
Conversion
Required
Conversion
Required
Conversion
Required
Ellipse
Ellipsoid
Polygon
Prism
ArcBand
Notes
Geoshape uses the
EPSG:4326 CRS
for 2d points, and
the EPSG:4979
CRS for 3d points
Table 9-3: GeoShape to VE2 Shape Mapping
Examples of the three accepted shape types are provided below.

9.4.2.1
GeoShape Examples
Following are examples of the GeoShapes supported by the v-E2 and ERDB root discovery
interfaces
9.4.2.1.1 Point
2D point:
38 Conversion methodology is left to implementation. Where conversion is performed, the converted shape is used to query both
the Root Discovery Server and later the ERDB and for return to the PSAP over the v-E2 interface.
Page 232 of 247

9-1-1 Services (i2)
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326"
<gml:pos>-34.407 150.883</gml:pos>
</gml:Point>
3D point :
<gml:Point srsName="urn:ogc:def:crs:EPSG::4979"
<gml:pos>-34.407 150.883 24.8</gml:pos>
</gml:Point>
9.4.2.1.2 Circle
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326"
<gml:pos>42.5463 -73.2512</gml:pos>
<gml:radius uom="urn:ogc:def:uom:EPSG::9001">850.24</gml:radius>
</gs:Circle>
9.4.2.1.3 Sphere
<gs:Sphere srsName="urn:ogc:def:crs:EPSG::4979"
<gml:pos>42.5463 -73.2512 26.3</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">850.24</gs:radius>
</gs:Sphere>
9.4.3
ERDB Root Discovery Provisioning
ERDB root discovery nodes are expected to be provisioned with polygons representing ERDB
service boundary areas.
These files must provide a linkage between service area and an ERDB URI. The format of the
provisioning file and constraints around area representation are described in the following
subsections.
Page 233 of 247

9-1-1 Services (i2)
9.4.3.1 ERDB Root Discovery Provisioning Files

The ERDB root discovery node is provisioned with files describing the GeoShape polygons
representing ERDB service coverage areas. ERDB operators are required to provide an XML file
to the ERDB root discovery operator which defines an ERDB area of coverage, and an
association to an ERDB URI through which ERDB routing requests can be made.
9.4.3.1.1 ERDB Boundary Definition Format
The format for the ERDB boundary definition element consists of two sections, a header,
describing the ERDB for which the file belongs, a creation date for the data in the file, an
effective date, and an expiry date. All times must be expressed in UTC. The second part of the
file is the polygon definition as described in Section D.1.
A sample ERDB boundary definition may look similar to that shown below.
Page 234 of 247

9-1-1 Services (i2)
<erdbBoundaryDefinition
xmlns="urn:nena:xml:ns:es:geoErdbRdo"
xsi:schemaLocation="urn:nena:xml:ns:es:geoErdbRdo
geoErdbRdo.xsd">
<erdbID>
<createDate>2006-10-01T13:00:00Z</createDate>
<expiryDate>2006-11-01T13:00:00Z</expiryDate>
<effectiveDate>2006-10-02T13:00:00Z</effectiveDate>
</erdbID>
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326"
<gml:exterior>
<gml:LinearRing>
<gml:pos>42.556844 -73.248157</gml:pos>
<gml:pos>42.549631 -73.237283</gml:pos>
<gml:pos>42.539087 -73.240328</gml:pos>
<gml:pos>42.535756 -73.254242</gml:pos>
<gml:pos>42.542969 -73.265115</gml:pos>
<gml:pos>42.553513 -73.262075</gml:pos>
<gml:pos>42.556844 -73.248157</gml:pos>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</erdbBoundaryDefinition>
9.4.4
ERDB Root Discovery Operation
Communication between a VPC and the ERDB root discovery server is performed using the v9
interface. This is a web services protocol that supports sending a single GeoShape object, Point
(2-D or 3-D), Circle, or Sphere from the VPC to the root discovery server. The response from the
root discovery server will be a list of zero or more ERDB URIs, along with a Percentage Overlap
Confidence (POC) value. The POC value describes the percentage of the initially provided
caller-location area (point plus uncertainty) overlapped with the corresponding ERDB service
area. This is illustrated in Figure 9-1-2 below.
If the location sent to the root discovery server is a 3 dimensional point, or a sphere, then the root
discovery server must project the shape into two dimensions prior to calculating the POC value.
This may be done by simply ignoring the altitude components.
The VPC should include the POC value and ERDB URI in event records generated for received
routing requests. This will assist ERDB and VPC operators in determining which areas and
boundaries are most susceptible to misrouting calls. Data for these areas can then be refined so
that improvements in routing data can be made.
Page 235 of 247

9-1-1 Services (i2)
Figure 9-2 Area of Overlap
The POC value is a value between 0 and 100, where 0 represents no overlap, and 100 represents
complete overlap. A value of 0 should never be returned by the root discovery node, unless
specific default handling capabilities are provisioned into it.
The POC is calculated by finding the area of overlap, Ao , between the caller area, Ac , and the
ERDB service area, SAerdb.
The list of ERDB URIs returned to the VPC by the root discovery node should be in descending
order by POC value. The highest POC valued ERDB URI should occur first in the list. It may be
possible that one or more ERDB URIs may have the same non-zero POC value, in which case all
the ERDB URIs will be returned in the list.
Page 236 of 247

9-1-1 Services (i2)
9.5
Web Services
A number of the new vx interfaces described in this document use Web Services. This section is
intended to serve as a high-level tutorial of Web Services.
A web service is a software application identified by a URI, whose interface and bindings are
capable of being identified, described and discovered by XML artifacts and supports direct
interactions with other software application using XML based messages via Internet-based
protocols.
(World Wide Web Consortium)
A web service is a collection of protocols and standards used for exchanging data between
applications. Software applications written in various programming languages and running on
various platforms can use web services to exchange data over the internet in a manner similar to
inter-process communications on a single computer.
9.5.1
9.5.2
Standards used
XML: All data to be exchanged is formatted with XML tags. This encoding can be
performed by Simple Object Access Protocol (SOAP) or XML-Remote Procedure Call
(RPC) (note: industry standards for security, interoperability, etc. are based on SOAP).
Common protocols: XML data can be transported between applications using common
protocols such as Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), and
Simple Mail Transfer Protocol (SMTP).
Web Services Description Language (WSDL): The public interface to the web service is
described by WSDL. This is an XML-based service description on how to communicate
using the web service. It describes the operations the service has available, the messages
the service will accept, and the protocol of the service.
Universal Description, Discovery, and Integration (UDDI): The web service information
is published using this protocol. It enables applications to look up web services
information in order to determine whether to use them.
SOAP: The service messaging layer of a web service. The messages are XML based.
The protocol consists of three parts: an envelope that defines a framework for describing
what is in a message and how to process it, a set of encoding rules for expressing
instances of application-defined datatypes, and a convention for representing remote
procedure calls and responses.
Key Points regarding Web Services
The key points to web services in providing emergency services are:
Web services are programming language and platform neutral. A web service can be
written in Microsofts .NET on a Windows platform and accessed via a UNIX Java
platform or other common development platforms.
Page 237 of 247

9-1-1 Services (i2)
Web services are industry standard. They were developed by the World Wide Web
Consortium and the standards are freely available.
For more information on WSDL see the following link:

http://www.w3schools.com/wsdl/default.asp
9.5.3
Substitution of Special Characters
The Web Services interfaces are XML-based and certain text characters have special meanings
to XML and HTML. As a result, these characters cannot be passed through the interface directly.
Instead, the client must substitute standard HTML character codes for these characters. The
following table lists the characters and the codes used to replace them.
Table 9-9-4 HTML Code Table
Character
HTML Code
&
(apostrophe)
<
>
(double quote)
&
'
<
>
"
Table 9-5: HTML Code Table
Page 238 of 247

9-1-1 Services (i2)
9.6
v7 Client Considerations/Recommendations
The v7 interface specification addresses only the messaging between a v7 client (e.g., a LIS) and
a v7 server (e.g., a VDB). This section is informative and presents suggestions and/or guidelines
that are outside the scope of the v7 interface standard. Following these guidelines will help a
VDB and v7 client developer ensure that their users can validate addresses quickly, and help
ensure that the v7 client is well behaved with respect to a v7 server.
9.6.1
Overview
A typical v7 client will provide a Graphical User Interface (GUI) to a user to collect addresses
for validation. The v7 client will use the data from the GUI to create and send v7 messages to the
VDB (the v7 server). The v7 client will receive the v7 response message, parse the message, then
use the parsed data to populate fields in the GUI presented to the User.
9.6.2
Wiremap LIS
The user for this type of v7 client will be the "administrator" of the wiremap LIS installation.
The administrator will need to validate addresses when the LIS is first installed. Whenever new
physical ports are wired, the administrator may need to validate addresses for those ports. Also
addresses will need to be re-validated on a periodic basis.
This solution assumes that the LIS presents web pages as the GUI to the LIS administrator.
Recommendation: The form presented to the LIS administrator should have distinct fields for
each part of the address, and those fields should match the fields in the underlying v7 messages.
Recommendation: The form should use drop-down menus for fields where the v7 interface
suggests the clients limit the data they send to relatively few values.
For example, if the v7 interface says that clients should limit the values submitted for
directionals to one of [e.g., N, S, E, W, NE, NW, SE, SW] it's best to use a drop-down menu on
the web page forms presented to the LIS administrator. Using drop-down menus helps minimize
the round-trip interactions required of the LIS administrator to validate an address.
Recommendation: For fields where the v7 interface suggests the clients limit the data they send
to a large but well known set of values, those fields should be validated prior to sending v7
messages.
For example, if the v7 interface says that clients should limit the values for submitted street
suffixes to those listed in country-specific Postal Standards, it would be impractical to try to
populate a web form drop-down with so many values. So it would be better to allow the LIS
administrator to enter suffixes free-form in a suffix field. Because the list is well known, the LIS
should validate the street suffix prior to sending a v7 message.
These validations could be client-side javascript, or validations running within the LIS web
server prior to sending the v7 message. The result of a validation should be a suggestion to
change the suffix prior to submitting for full validation. The LIS administrator should always be
able to proceed even if they don't accept this suggestion.
Page 239 of 247

9-1-1 Services (i2)
It is best for the LIS v7 implementation to do these types of simple validations, because the VDB
is not required to suggest alternatives. By doing these validations and making suggestions up
front, the LIS can insure a better user experience for the LIS administrator.
Recommendation: When the v7 response contains address alternatives, the GUI should display
the alternatives in the same order, indicating the first alternative is likely the best choice.
Page 240 of 247

9-1-1 Services (i2)
9.7
Call Routing Performance Guidelines
The information provided in this Appendix is offered as guidance to implementers of i2

architectures. The timing values are estimated, not measured.
People calling for help should not experience a long wait time before getting an indication that
the call has reached the PSAP. Consequently, implementers of i2 are encouraged to engineer the
network and elements in the IP Domain in such a way that emergency calls are routed in the
most efficient manner.
The design objective herein is to align with PSTN requirements that specify the maximum wait
time for call setup to be 10 seconds. In an i2 environment, and using SIP as an example, this
would be measured from the time the original INVITE is sent from the VEP, to the time the VEP
receives early media (i.e. ringing) from the ESGW. A call setup timer will be implemented to
measure the call setup time. However, it is assumed the VEP may initially not be able to
implement such a timer. An acceptable approach would then be to implement a special call setup
timer at the Call Server.
The following diagram provides the estimated setup times to deliver a call to the PSAP under
three possible routing schemes; one where the CS/Proxy routes the call, one where a Redirect
Server is involved and one where a Routing Proxy is involved. The number given on each line is
the time required to pass the information through the network. Incremental setup times at each
step are represented in the bottom part of the reference mark.
The following table lists the expected Total Call Processing Time at the various entities.
CS/Proxy
Redirect
Server
Routing
Proxy
VPC
ERDB
ESGW
SR
100ms
50ms
50ms
200ms
200ms
50ms
50ms
Table 9-6 Total Call Processing Time
l.
Page 241 of 247

9-1-1 Services (i2)
VEP
0
0ms
CS/Proxy
RS
1
100ms
100ms
75ms
2
275ms
100ms
100ms
4
775ms
5
975ms
100ms
100ms
25ms
ERDB
VPC
RP
100ms
ESGW
SR
PSAP
3
475ms
200ms
100ms
6
1.1s
100ms
1 sec IP Latency
50ms
6a
2.1s
100ms
ISUP
7
2.25s
50ms
50ms
2 secs
2 secs
CAMA
50ms
7
4.15s
2 secs
0
0ms
1
100ms
100ms
2
275ms
75ms
100ms
3
400ms
25ms
100ms
100ms
6
1.1s
7
1.225s
100ms
5
900ms
200ms
100ms
100ms
100ms
25ms
8
1.35s
100ms
1 sec IP Latency
50ms
8a
2.35s
100ms
ISUP
9
2.50s
50ms
50ms
2 secs
2 secs
CAMA
50ms
9
4.40s
2 secs
0
0ms
100ms
1
100ms
75ms
8
6.20s
4
600ms
100ms
25ms
8
4.30s
2
275ms
100ms
25ms
3
400ms
100ms
100ms
100ms
5
900ms
6
1.1s
25ms
100ms
10
4.55s
10
6.45s
4
600ms
200ms
100ms
100ms
7
1.225s
100ms
1 sec IP Latency
50ms
ISUP
7a
2.225s
100ms
8
2.375s
50ms
50ms
CAMA
2 secs
2 secs
8
4.25s
50ms
2 secs
9
4.425s
9
6.325s
Figure 9-3 Call Routing Performance
The following assumptions should be considered with the figure above.

Page 242 of 247

9-1-1 Services (i2)
Literal location (MSAG-validated civic or geodetic form) is assumed to be available to

the entity interacting with the VPC 39.
Congestion encountered using internet access is not considered in the performance. No
assumption is made that the Internet provides separate priority queues for voice calls.
Network connections assume Wide Area Networks (WANs).
Network time between the VPC and ERDB can be eliminated if VPC has access to the
information locally.
It is assumed that the VPC is preloaded with the information needed to determine the
appropriate ERDB 40. It is also assumed that the chosen ERDB has the routing
information that is being requested.
Delivery to the SR is expected to be either SS7 ISUP or traditional Centralized Automatic
Message Accounting (CAMA).
The SRDB is assumed to be on board the SR.
Delivery from the SR to the PSAP is assumed to be CAMA.
It is assumed that the VEP is not implementing a timer for a maximum wait time for call
setup at 10 seconds so, a special CS-based timer is assumed. Once the CS receives the
call from the IP endpoint, the call should be set up within that timeframe. This may
override SIP specified timers that allow up to 32 seconds.
Authentication/authorization at the ERDB, the VPC, the RS and the RP is assumed in
their respective processing times. No other authentication/authorization processing times
is included in this figure.
It is assumed agreements between the Call Server and the first Proxy exist when both
elements are locally operated by, or on behalf of the same VSP. No network and
authentication times are assumed.
IP Network Latency (IPL) can not be quantified so an additional 1 second is added to
each routing scheme to account for signaling and processes such as TCP and TLS setup
(when appropriate).
Processing times shown indicate the total processing time required to process each call.
Overall timers applicable to the setup:

The following timers and suggested values are based on the estimated times in the above figure.
Note that timers should be configurable so that values can be adjusted according to real-life
measurements.
M1. CS timer 10 seconds, maximum call setup time. If this timer expires, the CS may select a
contingency routing scenario, through a PSTN gateway for example. Tearing down the call
based on this timer is discouraged.
39 When an LK is supplied which requires the VPC to de-reference it at the LIS, add 1250ms (50ms processing, 200ms network
and 1 second IP Network Latency) to the total Call Setup Time.
40 When the RDS is involved to discover the ERDB, add 1250ms (50ms processing, 200ms network and 1 second IP Network
Latency) to the total Call Setup Time.
Page 243 of 247

9-1-1 Services (i2)
M2. CS timer for CS to VPC (v2) 4.6 seconds, maximum wait for response from VPC. If this
timer expires, the CS may select a contingency routing scenario, through a PSTN gateway
for example. Tearing down the call based on this timer is discouraged.
M3. RS timer for RS to VPC (v2) 4.35 seconds, maximum wait time for response from VPC.
If this timer expires, the RS shall return an error code over the v5 interface so the CS could
invoke a contingency routing scenario, through a PSTN Gateway for example. Tearing
down the call based on this timer is discouraged.
M4. RP timer for RP to VPC (v2) 4.475 seconds, maximum wait for response from VPC. If
this timer expires, the RP may select a contingency routing scenario, through a PSTN
gateway for example. Tearing down the call based on this timer is discouraged.
M5. CS timer for CS to RS (v5) 4.6 seconds, maximum wait for response from RS, including
VPC and ERDB interactions. If this timer expires, the CS may select a contingency routing
scenario, through a PSTN gateway for example. Tearing down the call based on this timer is
discouraged.
M6. VPC timer for VPC to ERDB (v8) 1.35 seconds, maximum wait for each ERDB query.
If this timer expires, the VPC shall retry the ERDB query until timer M7 expires.
M7. VPC timer (v8) 4.05 seconds, maximum overall wait time for any interactive responses
between a VPC and ERDB(s). If this timer expires, the VPC shall send an error message
(5XX) to the requesting entity (CS, RS or RP) over the v2 interface. The routing entity may
then invoke a contingency routing scenario, through a PSTN gateway for example. Tearing
down the call based on this timer is discouraged.
Average Expected Call Setup Times:
4 to 5 Seconds with SS7 to the SR and CAMA to the PSAP

6 to 7 Seconds with CAMA to the SR and CAMA to the PSAP
Call Setup times with applicable timers:

VEP-CS-Timer M2-CS-ESGW-SS7 SR-CAMA PSAP+IPL= 8100ms
VEP-CS-Timer M2-CS-ESGW-CAMA SR-CAMA PSAP+IPL= 10000ms
VEP-CS-RS-Timer M3-RS-CS-ESGW-SS7 SR-CAMA PSAP+IPL= 8100ms
VEP-CS-RS-Timer M3-RS-CS-ESGW-CAMA SR-CAMA PSAP+IPL= 10000ms
VEP-RP-Timer M4-RP-ESGW-SS7 SR-CAMA PSAP+IPL= 8100ms
VEP-RP-Timer M4-RP-ESGW-CAMA SR-CAMA PSAP+IPL= 10000ms
VEP-CS-Timer M5-CS-ESGW-SS7 SR-CAMA PSAP+IPL= 8100ms
VEP-CS-Timer M5-CS-ESGW-CAMA SR-CAMA PSAP+IPL= 10000ms
VEP-CS/RS/RP-Timer M7-CS/RP-ESGW-SS7 SR-CAMA PSAP+IPL= 8100ms
VEP-CS/RS/RP-Timer M7-CS/RP-ESGW-CAMA SR-CAMA PSAP+IPL= 10000ms
Overall Maximum call setup time (Timer M1) from time CS receives call 10 secs
Page 244 of 247

9-1-1 Services (i2)
9.8
Issues under Investigation
This Appendix provides a list of issues that are still under consideration in the VoIP Migratory
Work Group. The resolution of these issues may result in revisions to the i2 solution document.
The issues that are currently on the VoIP Migratory group agenda as potential topics for further
investigation are as follows :
Allowing VDB to return MSAG formatted address to LIS

Requirements on VESA operator
Requirements on ERDB/VDB discovery operator
Delivery of Class of Service over v-E2 interface
v0 Interface to Call Server
Redefinition of the v3 interface to be in line with Industry Standards
Support for mobile calls
Support for E9-1-1 Call Control Features
Support for ERDB Steering
Support for internationalization of i2 Solution
Support for an explicit indicator in v-E2 esposreq message identifying the location
information on which call routing determination was based.
Middle box acquisition and inserted location.
Sending of geocoded location information to the PSAP when original civic location was
invalid and the ERDB geo-coded the received invalid civic location for routing
determination purposes
Steering of queries between ERDBs.
Mechanism used at a routing proxy/redirect server to determine the identity of a VSP.
Page 245 of 247

9-1-1 Services (i2)
10 Previous Acknowledgments
Version 1, Approval Date, 12/16/2005
Members:
Nate Wilcox VoIP/Packet Technical
Committee Chair
Anand Akundi Work Group Leader and
Technical Editor
Nate Wilcox VoIP/Packet Technical Chair
Delaine Arnold
Ric Atkins
Erica Aubut
Tim Barry
Marc Berryman
Paul Binder
Patty Bluhm
Dean Bordens
Tom Breen
Tom Browne
Guy Caron
Larry Ciesla
Martin Dawson
Carol DeFazio
Martin Dolly
Jerry Eisner
Tom Hicks
Bill Horne
Dick Khan
Marc Linsner
Bill Marczac
Roger Marshall
Jeff Martin
Ken Maynard
Paul Mallett
Patti McCalmont
Dave Morris
Theresa Reese
Brian Rosen
John Rosenberg
John Savaglio
Carl Smith
Company
MicroData
MircoData
Arnold 9-1-1 Consulting
Tarrant County 9-1-1 District
State of Vermont 9-1-1
AT&T
Greater Harris County 9-1-1
T-Mobile
HBF Group
AT&T
AT&T
HBF Group
Bell Canada
Intrado
Andrew Corporation
ATT
Intrado
Intrado
Tarrant County 9-1-1
AT&T
Cisco
AT&T
TCS
TCS
Bexar Metro 9-1-1 Metro District
CSEC
Intrado
Verizon
Neustar
Lucent
AT&T
Intrado
Page 246 of 247

9-1-1 Services (i2)
Paul Stoffels
Maureen Stork
Chuck Thompson
Larry Truesdale
Greg Welenson
James Winterbottom
AT&T
Verizon Business
C.P. Thompson Limited
Nortel Networks
Vonage
Andrew Corporation
Page 247 of 247

NENA Interim VoIP Architecture For E-911 I2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NENA Interim VoIP Architecture For E-911 I2

Uploaded by

Copyright:

Available Formats

NENA Interim VoIP Architecture for

Enhanced 9-1-1 Services (i2)

NENA Interim VoIP Architecture for Enhanced 9-1-1 Services (i2)