NENA Interim VoIP Architecture for Enhanced Services (i2)

Transcription

1 NENA Interim VoIP Architecture for NENA , 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

2 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 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. NENA s 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 or: techdoccomments@nena.org Version 2, August 11, 2010 Page 2 of 247

3 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 Consulting Eric Arolick Telcordia Technologies Tim Barry AT&T Marc Berryman Greater Harris County Patty Bluhm Intrado Tom Breen AT&T Guy Caron Bell Canada Randall Gellens Qualcomm Ken Maynard Bexar Metro Metro District Theresa Reese Telcordia Technologies 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. Version 2, August 11, 2010 Page 3 of 247

4 TABLE OF CONTENTS 1 EXECUTIVE OVERVIEW PURPOSE AND SCOPE OF DOCUMENT REASON TO IMPLEMENT BENEFITS INTRODUCTION OPERATIONAL IMPACTS SUMMARY SECURITY IMPACTS SUMMARY DOCUMENT TERMINOLOGY REASON FOR ISSUE/REISSUE RECOMMENDATION FOR ADDITIONAL DEVELOPMENT WORK DATE COMPLIANCE ANTICIPATED TIMELINE COSTS FACTORS FUTURE PATH PLAN CRITERIA FOR TECHNICAL EVOLUTION COST RECOVERY CONSIDERATIONS ADDITIONAL IMPACTS (NON COST RELATED) INTELLECTUAL PROPERTY RIGHTS POLICY ACRONYMS/ABBREVIATIONS TECHNICAL DESCRIPTION GENERAL ASSUMPTIONS OVERVIEW OF INTERCONNECTION TO CONVENTIONAL E9-1-1 SYSTEMS DESCRIPTION OF FUNCTIONAL ELEMENTS User Agent (UA) VoIP Endpoint (VEP) Server Call Server Proxy or Proxy Server/Policy and Routing Server Redirect Server/Call Relay Server Emergency Services Gateway (ESGW) Emergency Service Zone Routing Data Base (ERDB) VoIP Positioning Center (VPC) Validation Data Base (VDB) Location Information Server (LIS) Root Discovery Service (RDS) DESCRIPTION OF DATA OBJECTS INTERFACE DEFINITIONS v0 LIS to VoIP Endpoint v1 VoIP Endpoint to Call Server/Proxy v2 Call Server or Routing Proxy or Redirect Server to VPC v3 VPC to LIS v4 Call Server/Routing Proxy to ESGW v5 Call Server/Proxy to Redirect Server v6 Call Server to Routing Proxy v7 LIS to VDB v8 VPC to ERDB Version 2, August 11, 2010 Page 4 of 247

5 v9 LIS/VPC to Root Discovery Operator v-e2 VPC to ALI DB LOCATION INFORMATION SCENARIOS Endpoint Stores Location LIS Stored Location Key CALL ROUTING SCENARIOS Basic Call Routing of VoIP Emergency Calls to ESGW Proxy Redirect Server Routing Proxy Routing Scenario ESGWRI-based Routing Translations CALL ROUTING FAILURE SCENARIOS Abnormal Conditions Detected at the Call Server/Proxy Abnormal Conditions Detected at the VPC Abnormal Conditions Detected at the ESGW Default Routing at the Selective Router Summary of Contingency/Default Routing LOCATION VALIDATION ROOT DISCOVERY SERVICE (RDS) Root Discovery Assumptions Root Discovery VDB Directory File Format ERDB directory file format ERDB Directory File Format Geodetic Coverage PSAP CALL CONTROL FEATURES Requirements ESGW Interworking Requirements SECURITY AUTHENTICATION MESSAGE INTEGRITY MESSAGE ENCRYPTION NETWORK ELEMENT SECURITY NETWORK LAYER SECURITY APPLICATION LAYER SECURITY LOCATION DATA SECURITY FUNCTIONAL REQUIREMENTS VSP CALL SERVER/PROXY Authentication and Authorization Performance Reliability and Availability ROUTING PROXY SERVER Authentication and Authorization Performance Reliability and Availability REDIRECT SERVER Authentication and Authorization Performance Reliability and Availability EMERGENCY SERVICES GATEWAY (ESGW) Version 2, August 11, 2010 Page 5 of 247

6 5.4.1 Authentication and Authorization Performance Reliability and Availability ESZ ROUTING DATABASE (ERDB) Receiving and Storing Routing Information Processing Routing Queries Authentication and Authorization Performance Reliability and Availability VOIP POSITION CENTER (VPC) Support for Emergency Call Routing Delivery of Location Information Authentication and Authorization Performance Reliability and Availability VALIDATION DATA BASE (VDB) Storage of MSAG Validation Perform Validation Authentication and Authorization Performance Reliability and Availability LOCATION INFORMATION SERVER (LIS) Detailed LIS Requirements LIS Query Protocol and Location Information Format Validated Address to PIDF-LO Mapping Authentication and Authorization Performance Reliability and Availability AUTOMATIC LOCATION IDENTIFICATION (ALI) DATABASE Authentication and Authorization Performance Reliability and Availability DETAILED INTERFACE SPECIFICATIONS V0 LIS TO VOIP ENDPOINT V1 VOIP ENDPOINT TO CALL SERVER V2 CALL SERVER/ROUTING PROXY/REDIRECT SERVER TO VPC v2 Message Definitions v2 Message Call Flows, Key Scenarios and Semantics v2 Interface Security V3 VPC TO LIS V4 - CALL SERVER/ROUTING PROXY TO ESGW v4 Interface Architecture v4 Interface Call Flow v4 Message Parameters Specification of the v4 interface v4 SIP Messages Examples Assumptions v4 Interface Security V5 CALL SERVER/PROXY TO REDIRECT SERVER Version 2, August 11, 2010 Page 6 of 247

7 6.6.1 Technical Description v5 Interface Call Flow v5 Message Parameters Specification of the v5 Interface SIP Exchange Example v5 Security Requirements V6 CALL SERVER TO ROUTING PROXY INTERFACE v6 Interface Architecture v6 Interface Call Flow v6 Message Parameters Specification of the v6 interface v6 SIP Message Examples v6 Interface Security v6 Interface Assumptions V7 LIS TO VDB v7 Message Definitions v7 Message Flows, Key Scenarios and Semantics v7 Interface Security V8 INTERFACE - VPC TO ERDB v8 Message Definition v8 Message Flows, Key Scenarios and Semantics Security V9 INTERFACE LIS/VPC TO RDS v9 Messages Definitions v9 Message Flows, Key Scenarios and Semantics v9 Interface Security V-E2 INTERFACE ALI TO VPC v-e2 Message Definitions Emergency Services Protocol (ESP) Parameters v-e2 Message flows, Key Scenarios and Semantics v-e2 Interface Security ROLES AND RESPONSIBILITIES RESPONSIBILITIES Caller VoIP Service Provider Redirect Operator Routing Proxy Operator LIS Operator ESGW Operator Selective Router (SR) Operators PSAP Operators ALI Operator VPC Operator Credential Authority Routing Number Authority (RNA) Master Street Address Guide (MSAG) Source Validation Database (VDB) Operator Emergency Routing Database (ERDB) Operator Root Discovery Operator (RDO) Version 2, August 11, 2010 Page 7 of 247

8 Administrator RECOMMENDED READING AND REFERENCES EXHIBITS (INFORMATIVE) POTENTIAL ALI CHANGES Purpose Overview Potential Changes Required to Support i2 Solution RULES FOR ADDRESS ABBREVIATION Resources for Abbreviation Matching MSAG TO POSTAL ADDRESS COMPARISON ERDB DISCOVERY USING GEODETIC INFORMATION Polygon Definition Endpoint (Subscriber) Location Representation ERDB Root Discovery Provisioning ERDB Root Discovery Operation WEB SERVICES Standards used Key Points regarding Web Services Substitution of Special Characters V7 CLIENT CONSIDERATIONS/RECOMMENDATIONS Overview Wiremap LIS CALL ROUTING PERFORMANCE GUIDELINES ISSUES UNDER INVESTIGATION PREVIOUS ACKNOWLEDGMENTS Version 2, August 11, 2010 Page 8 of 247

9 1 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 i 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 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 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: Version 2, August 11, 2010 Page 9 of 247

10 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. 2 Introduction 2.1 Operational Impacts Summary Operational impacts include: 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 caller s 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. 2.2 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 system (v0/v1) and several are between elements that are considered to be within the 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". Version 2, August 11, 2010 Page 10 of 247

11 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 Approval Date Reason For Changes Original 12/06/2005 Initial Document 2 8/11/2010 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 Version 2, August 11, 2010 Page 11 of 247

12 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 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 call and data delivery, it is a requirement to maintain the same level or improve on the reliability and service characteristics inherent in present 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 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 NENA s technical standards and other generally accepted base characteristics of E9-1-1 service 2. Service parity for all potential 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 Version 2, August 11, 2010 Page 12 of 247

13 5. Documented procedures, practices, and processes to ensure adequate implementation and ongoing maintenance for 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 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 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 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 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 [39] - NENA Master Glossary of Terminology located on the NENA web site for a complete listing of terms used in NENA documents. Version 2, August 11, 2010 Page 13 of 247

14 The following Acronyms are used in this document: Acronym Description ** N)ew (U)pdate ERT Emergency Route Tuple N ESGWRI Emergency Services Gateway Route Identifier N Version 2, August 11, 2010 Page 14 of 247

15 3 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 infrastructure (e.g. SR provider, ALI provider, etc.), although the i2 architecture does not preclude providers of 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. Version 2, August 11, 2010 Page 15 of 247

16 The ERDB and VDB service must be provided by the same operating entity. The authority will determine the single ERDB/VDB provider that will service a specific geographic area. For example, a State 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 , 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 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, for the UK, etc.). Version 2, August 11, 2010 Page 16 of 247

17 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. Version 2, August 11, 2010 Page 17 of 247

18 VoIP End Point Call Server/ Proxy v1 v0 LIS IP domain Routing Proxy & Redirect Server(s) v6 v5 v4 v3 v2 v2 v9 v4 PSTN Gateway ESGW(s) VPC VPC VPC v8 PSTN ERDB Emergency Services Provider Network v-e2 Used for contingency routing and non-e9-1-1-enabled PSAP E9-1-1 Selective Router(s) SRDB ALI PSAP v9 v7 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. Version 2, August 11, 2010 Page 18 of 247

19 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 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 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). Version 2, August 11, 2010 Page 19 of 247

20 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 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 caller s 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 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 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 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. Version 2, August 11, 2010 Page 20 of 247