NENA Interim VoIP Architecture for Enhanced Services (i2)

Size: px
Start display at page:

Download "NENA Interim VoIP Architecture for Enhanced 9-1-1 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: 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: 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

CLEARSPAN 911/E911 Overview

CLEARSPAN 911/E911 Overview CLEARSPAN 911/E911 Overview Revision 09012014-1 Proprietary Notice This document contains sensitive and proprietary information and company trade secrets that are critical to Aastra business. This information

More information

NENA. ESQK Guidelines for VoIP to E9-1-1 Connectivity. Technical Information Document (TID)

NENA. ESQK Guidelines for VoIP to E9-1-1 Connectivity. Technical Information Document (TID) NENA ESQK Guidelines for VoIP to E9-1-1 Connectivity Technical Information Document (TID) ESQK Guidelines for VoIP to E9-1-1 Connectivity Prepared by: National Emergency Number Association (NENA) Network

More information

NENA. ESQK Guidelines for VoIP to E9-1-1 Connectivity. Technical Information Document (TID)

NENA. ESQK Guidelines for VoIP to E9-1-1 Connectivity. Technical Information Document (TID) NENA ESQK Guidelines for VoIP to E9-1-1 Connectivity Technical Information Document (TID) ESQK Guidelines for VoIP to E9-1-1 Connectivity Prepared by: National Emergency Number Association (NENA) Network

More information

NENA Technical Standard for Reporting and Resolving ANI/ALI Discrepancies and No Records Found for Wireline, Wireless and VoIP Technologies

NENA Technical Standard for Reporting and Resolving ANI/ALI Discrepancies and No Records Found for Wireline, Wireless and VoIP Technologies NENA Technical Standard for Reporting and Resolving ANI/ALI Discrepancies and No Records Found for Wireline, Wireless and VoIP Technologies NENA Technical Standard for Reporting and Resolving ANI/ALI Discrepancies

More information

9-1-1 Glossary of Terms

9-1-1 Glossary of Terms 9-1-1 Glossary of Terms 9-1-1 A three-digit telephone number to facilitate the reporting of an emergency requiring response by a public safety agency. 9-1-1 Network Literally, the dedicated circuits, and

More information

The ESWG 12-month Consensus Report on Nomadic VoIP. Technical and Operating Impediments to

The ESWG 12-month Consensus Report on Nomadic VoIP. Technical and Operating Impediments to The ESWG 12-month Consensus Report on Nomadic VoIP Technical and Operating Impediments to 9-1-1/E9-1-1 Service Delivery in Canada 24 May 2006 Executive Summary The ESWG proposes to file, within six (6)

More information

NENA STANDARDS FOR E9-1-1 CALL CONGESTION MANAGEMENT

NENA STANDARDS FOR E9-1-1 CALL CONGESTION MANAGEMENT NENA STANDARDS FOR E9-1-1 CALL CONGESTION MANAGEMENT NENA 03-006 NENA-03-006 Prepared by: National Emergency Number Association (NENA) Network Technical Committee Published by NENA Printed in USA NENA

More information

Intrado V9-1-1 Services PSAP Methods and Procedures Version 2008.03.07

Intrado V9-1-1 Services PSAP Methods and Procedures Version 2008.03.07 Intrado V9-1-1 Services PSAP Methods and Procedures Version 2008.03.07 Notice Intrado V9-1-1 Services Program and Documentation 2008 by Intrado Inc. All Rights Reserved Printed in U.S.A. This software

More information

NENA Standards For Local Service Provider Interconnection Information Sharing

NENA Standards For Local Service Provider Interconnection Information Sharing NENA Standards For Local Service Provider Interconnection Information Sharing NENA-06-001 Updated August 2004 NENA Standards For Local Service Provider Prepared by: National Emergency Number Association

More information

ENP Study Group Wireless-VOIP 5-6-14

ENP Study Group Wireless-VOIP 5-6-14 ENP Study Group Wireless-VOIP 5-6-14 BROUGHT TO YOU BY: THE FLORIDA NENA EDUCATION COMMIT TEE Wireless 9-1-1 Evolution Similar to Wireline Basic 9-1-1 Call Flow (Voice Only): Wireless Basic 9-1-1 Cell

More information

Intrado V9-1-1 Services PSAP Methods and Procedures Version 2015.9.30

Intrado V9-1-1 Services PSAP Methods and Procedures Version 2015.9.30 Intrado V9-1-1 Services PSAP Methods and Procedures Version 2015.9.30 Notice Intrado V9-1-1 Services Program and Documentation 2005-2015 by Intrado Inc. All Rights Reserved Printed in U.S.A. This software

More information

The 4-1-1 on NG9-1-1 Part I of III

The 4-1-1 on NG9-1-1 Part I of III The 4-1-1 on NG9-1-1 Part I of III Presented By Guy Churchouse, ENP, CCNA Voice, SSCA Director of Sales, Revcord Contents Overview... 2 Where We Were, Where We Are Now, And Where We Are Going... 2 Where

More information

NG9-1-1 System and PSAP Operational Features and Capabilities Requirements

NG9-1-1 System and PSAP Operational Features and Capabilities Requirements NG9-1-1 System and PSAP Operational Features and Capabilities Requirements NENA NG9-1-1 System and PSAP Operational Document 57-750, v1, June 14, 2011 Standards Advisory Committee Approval Date, March

More information

Bandwidth.com Compliance Letter Submitted by Steven Lacoff, VP of Product Management Referencing WC Docket No. 05-196

Bandwidth.com Compliance Letter Submitted by Steven Lacoff, VP of Product Management Referencing WC Docket No. 05-196 BANDWIDTH.COM COMPANY & VoIP SOLUTION OVERVIEW: Bandwidth.com is a telecommunications services company based out of Cary, NC targeting small-to-medium businesses (SMBs) exclusively with no consumer VoIP

More information

NOTE: Changes in technology and procedures occur frequently with VoIP. This information may not be completely up-to-date.

NOTE: Changes in technology and procedures occur frequently with VoIP. This information may not be completely up-to-date. Chapter 6 VoIP What is VoIP?... 1 County Coordinator Responsibility Data Maintenance... 4 County Coordinator Responsibility Deployment... 5 Telematics... 10 NGEN Next Generation E9-1-1 Network... 11 NOTE:

More information

Internet Engineering Task Force (IETF) Category: Informational. H. Tschofenig Nokia Siemens Networks B. Stark AT&T A. Kuett Skype January 2012

Internet Engineering Task Force (IETF) Category: Informational. H. Tschofenig Nokia Siemens Networks B. Stark AT&T A. Kuett Skype January 2012 Internet Engineering Task Force (IETF) Request for Comments: 6444 Category: Informational ISSN: 2070-1721 H. Schulzrinne Columbia University L. Liess Deutsche Telekom H. Tschofenig Nokia Siemens Networks

More information

Intrado Direct VPC Guide VoIP ALI Data Provisioning Process Version 2012.03.21

Intrado Direct VPC Guide VoIP ALI Data Provisioning Process Version 2012.03.21 Intrado Direct VPC Guide VoIP ALI Data Provisioning Process Version 2012.03.21 Notice Intrado Direct VPC Guide Program and Documentation 2006-2012 by Intrado Inc. All Rights Reserved Printed in U.S.A.

More information

E911 Services and the VoIP Environment

E911 Services and the VoIP Environment E911 Services and the VoIP Environment Wednesday, October 26 1:30 3:00 p.m. Veronese 2502 Technology Forum at TELECOM 05 Vonage E911 Deployment The Vonage History 2001 2003 Research and Development Market

More information

Glossary of Terms and Definitions

Glossary of Terms and Definitions Glossary of Terms and Definitions 911 Governing Authority 911 Governing Authority means a municipality or other state or local government agency, or an authorized agent of one or more municipalities or

More information

Intrado Emergency Routing Service (ERS) Canada Service Guide Version 2014.12.02

Intrado Emergency Routing Service (ERS) Canada Service Guide Version 2014.12.02 Intrado Emergency Routing Service (ERS) Canada Service Guide Version 2014.12.02 2014 Intrado Inc., Longmont, Colorado, USA - All rights reserved. This documentation may not be altered, copied, distributed,

More information

9-1-1 Services for Interconnected VoIP and Local Exchange Carriers

9-1-1 Services for Interconnected VoIP and Local Exchange Carriers WHITE PAPER 9-1-1 Services for Interconnected VoIP and Local Exchange Carriers Frequently Asked s 9-1-1 Services for Interconnected VoIP and Local Exchange Carriers Frequently Asked s 2 WHITE PAPER 9-1-1

More information

NENA/APCO. Operations Information Document (OID)

NENA/APCO. Operations Information Document (OID) NENA/APCO Best Practices Model for Third Party Emergency Medical Dispatch Services and PSAPs Operations Information Document (OID) NENA/APCO Best Practices Model for Providing Prepared by: National Emergency

More information

NENA VoIP E9-1-1 Deployment and Operational Guidelines Operational Information Document (OID)

NENA VoIP E9-1-1 Deployment and Operational Guidelines Operational Information Document (OID) 08/29/2014 for historical purposes. NENA VoIP E9-1-1 Deployment and Operational Guidelines Ar ch iv ed Operational Information Document (OID) NENA VoIP E9-1-1 Deployment and Operational Guidelines OID

More information

NENA IP Capable PSAP Features And Capabilities Standard

NENA IP Capable PSAP Features And Capabilities Standard NENA IP Capable PSAP Features And Capabilities NENA IP Capable PSAP Features and Capabilities Document 58-001 Prepared by: National Emergency Number Association (NENA) VoIP PSAP Operations Features / Capabilities

More information

Telephone numbers for Relay Users (TRU) Brian Rosen NeuStar

Telephone numbers for Relay Users (TRU) Brian Rosen NeuStar Telephone numbers for Relay Users (TRU) Brian Rosen NeuStar NPAC is the database Direct Dial, Hearing to Deaf/HoH Alternate Provider Hearing to Deaf/HoH Direct Dialed Deaf/HoH to Hearing Deaf/HoH to Hearing

More information

Emergency caller location in an internet world

Emergency caller location in an internet world Emergency caller location in an internet world Roundtable on European Emergency Number 112 Sofia, Bulgaria March 6 th 2009 www.andrew.com Christophe.Fondin@andrew.com Why does one need a E112 caller location

More information

PRIVATE SWITCH (PS) E-9-1-1 DATABASE STANDARD

PRIVATE SWITCH (PS) E-9-1-1 DATABASE STANDARD PRIVATE SWITCH (PS) E-9-1-1 DATABASE STANDARD NENA-06-003 NENA Prepared by: National Emergency Number Association (NENA) Data Technical Committee, Private Switch Data Subcommittee Published by NENA Printed

More information

Priority Access to PSAPs. Informational Packet

Priority Access to PSAPs. Informational Packet Priority Access to PSAPs Informational Packet March 7, 2007 General Motors, [GM] and the stylized logo GM; OnStar, and the stylized logo OnStar all rights reserved OnStar Seeking Priority Access to PSAPs

More information

All-IP Network Emergency Call Support

All-IP Network Emergency Call Support GPP S.R0-0 Version.0 Version Date: October 00 All-IP Network Emergency Call Support Stage Requirements COPYRIGHT GPP and its Organizational Partners claim copyright in this document and individual Organizational

More information

LOCATION DATA MANAGEMENT: THE ESSENTIAL GUIDE TO ALI MANAGEMENT BEST PRACTICES

LOCATION DATA MANAGEMENT: THE ESSENTIAL GUIDE TO ALI MANAGEMENT BEST PRACTICES LOCATION DATA MANAGEMENT: THE ESSENTIAL GUIDE TO ALI MANAGEMENT BEST PRACTICES Selecting a Service Provider www.intrado.com 2014, Intrado Inc. All rights reserved. The content of this guidebook may not

More information

White Paper. Is VoIP Without E9-1-1 Worth the Risk? Challenges, Approaches, and Recommendations for VoIP Service Providers

White Paper. Is VoIP Without E9-1-1 Worth the Risk? Challenges, Approaches, and Recommendations for VoIP Service Providers TeleCommunication Systems, Inc. www.telecomsys.com Is VoIP Without E9-1-1 Worth the Risk? Challenges, Approaches, and Recommendations for VoIP Service Providers Notices 2004 TeleCommunication Systems,

More information

EXPLOITING SIMILARITIES BETWEEN SIP AND RAS: THE ROLE OF THE RAS PROVIDER IN INTERNET TELEPHONY. Nick Marly, Dominique Chantrain, Jurgen Hofkens

EXPLOITING SIMILARITIES BETWEEN SIP AND RAS: THE ROLE OF THE RAS PROVIDER IN INTERNET TELEPHONY. Nick Marly, Dominique Chantrain, Jurgen Hofkens Nick Marly, Dominique Chantrain, Jurgen Hofkens Alcatel Francis Wellesplein 1 B-2018 Antwerp Belgium Key Theme T3 Tel : (+32) 3 240 7767 Fax : (+32) 3 240 8485 E-mail : Nick.Marly@alcatel.be Tel : (+32)

More information

Application Notes for BT Wholesale/HIPCOM SIP Trunk Service and Avaya IP Office 8.0 Issue 1.0

Application Notes for BT Wholesale/HIPCOM SIP Trunk Service and Avaya IP Office 8.0 Issue 1.0 Avaya Solution & Interoperability Test Lab Application Notes for BT Wholesale/HIPCOM SIP Trunk Service and Avaya IP Office 8.0 Issue 1.0 Abstract These Application Notes describe the procedures for configuring

More information

Chapter 2 PSTN and VoIP Services Context

Chapter 2 PSTN and VoIP Services Context Chapter 2 PSTN and VoIP Services Context 2.1 SS7 and PSTN Services Context 2.1.1 PSTN Architecture During the 1990s, the telecommunication industries provided various PSTN services to the subscribers using

More information

Next Generation 112 Explained

Next Generation 112 Explained Next Generation 112 Explained Riga 18 of April 2012 Presented by Cristina Lumbreras Prepared with the help of Hannes Tschofenig Agenda 1. What is a Next Generation Network? 2. Next Generation Emergency

More information

Application Notes for Configuring Intelepeer SIP Trunking with Avaya IP Office 7.0 - Issue 1.0

Application Notes for Configuring Intelepeer SIP Trunking with Avaya IP Office 7.0 - Issue 1.0 Avaya Solution & Interoperability Test Lab Application Notes for Configuring Intelepeer SIP Trunking with Avaya IP Office 7.0 - Issue 1.0 Abstract These Application Notes describe the procedures for configuring

More information

ERS Canada Service Guide. Version 2016.04.05

ERS Canada Service Guide. Version 2016.04.05 ERS Canada Service Guide Version 2016.04.05 Contents 1. Introduction... 2 2. Service Features... 2 2.1. Call Flow... 2 2.2. Service Components... 3 2.3. Connectivity... 3 2.4. Maintenance and Support...

More information

MODELLING OF INTELLIGENCE IN INTERNET TELEPHONE SYSTEM

MODELLING OF INTELLIGENCE IN INTERNET TELEPHONE SYSTEM MODELLING OF INTELLIGENCE IN INTERNET TELEPHONE SYSTEM Evelina Nicolova Pencheva, Vessela Liubomirova Georgieva Department of telecommunications, Technical University of Sofia, 7 Kliment Ohridski St.,

More information

NENA Information Document on: The Effect of Mass Calling Events on Legacy SR to PSAP Trunking

NENA Information Document on: The Effect of Mass Calling Events on Legacy SR to PSAP Trunking NENA Information Document on: The Effect of Mass Calling Events on Legacy SR to PSAP Trunking NENA Information Document on The Effect of Mass Calling Events on Legacy SR to PSAP Trunking NENA-INF-002.1-2012

More information

Contents Introduction Why Fax over IP? How Real-time Fax over IP works Implementation with MessagePlus/Open Summary. About this document

Contents Introduction Why Fax over IP? How Real-time Fax over IP works Implementation with MessagePlus/Open Summary. About this document Fax over IP Contents Introduction Why Fax over IP? How Real-time Fax over IP works Implementation with MessagePlus/Open Summary About this document This document describes how Fax over IP works in general

More information

Presence SIMPLE Architecture

Presence SIMPLE Architecture Presence SIMPLE Architecture Approved Version 1.1 27 Jun 2008 Open Mobile Alliance OMA-AD-Presence_SIMPLE-V1_1-20080627-A OMA-AD-Presence_SIMPLE-V1_1-20080627-A Page 2 (21) Use of this document is subject

More information

Application Notes for Configuring Broadvox SIP Trunking with Avaya IP Office - Issue 1.0

Application Notes for Configuring Broadvox SIP Trunking with Avaya IP Office - Issue 1.0 Avaya Solution & Interoperability Test Lab Application Notes for Configuring Broadvox SIP Trunking with Avaya IP Office - Issue 1.0 Abstract These Application Notes describe the procedures for configuring

More information

Avaya IP Office 8.1 Configuration Guide

Avaya IP Office 8.1 Configuration Guide Avaya IP Office 8.1 Configuration Guide Performed By tekvizion PVS, Inc. Contact: 214-242-5900 www.tekvizion.com Revision: 1.1 Date: 10/14/2013 Copyright 2013 by tekvizion PVS, Inc. All Rights Reserved.

More information

Internet Standards - Emergency Services

Internet Standards - Emergency Services Internet Standards - Emergency Services Hannes Tschofenig (Chair IETF ECRIT Working Group) Mail comments to Hannes.Tschofenig@nsn.com and/or ecrit@ietf.org. Architectural Considerations Layer 7 VoIP, Inc.

More information

VERIZON COMMENTS REGARDING STAFF S LATEST DRAFT RULES FOR MULTILINE TELEPHONE SYSTEM ( MLTS ) 911 CALLS

VERIZON COMMENTS REGARDING STAFF S LATEST DRAFT RULES FOR MULTILINE TELEPHONE SYSTEM ( MLTS ) 911 CALLS VERIZON COMMENTS REGARDING STAFF S LATEST DRAFT RULES FOR MULTILINE TELEPHONE SYSTEM ( MLTS ) 911 CALLS Thank you for the opportunity to review Staff s draft revised proposed rules for Multiline Telephone

More information

Application Notes for Avaya IP Office 7.0 Integration with Skype Connect R2.0 Issue 1.0

Application Notes for Avaya IP Office 7.0 Integration with Skype Connect R2.0 Issue 1.0 Avaya Solution & Interoperability Test Lab Application Notes for Avaya IP Office 7.0 Integration with Skype Connect R2.0 Issue 1.0 Abstract These Application Notes describe the steps to configure an Avaya

More information

Looking Beyond Data Synchronization for Mission Critical GIS Data

Looking Beyond Data Synchronization for Mission Critical GIS Data Looking Beyond Data Synchronization for Mission Critical GIS Data Table of Contents Preface... 2 Background Information... 3 Introduction... 4 Area of Focus #1: Locally Authoritative GIS Data Development

More information

NAT TCP SIP ALG Support

NAT TCP SIP ALG Support The feature allows embedded messages of the Session Initiation Protocol (SIP) passing through a device that is configured with Network Address Translation (NAT) to be translated and encoded back to the

More information

Requirements & Reference Models for ADSL Access Networks: The SNAG Document

Requirements & Reference Models for ADSL Access Networks: The SNAG Document Technical Report TR-010 Requirements & Reference Models for ADSL Access Networks: The SNAG Document June 1998 Abstract: This document outlines architectural requirements and reference models for ADSL services

More information

Next Generation 9-1-1

Next Generation 9-1-1 Next Generation 9-1-1 Briefing to the North Dakota Public Safety and Transportation Committee October 15, 2009 Agenda Overview of Next Generation 9-1-1 Review of the North Dakota NG9-1-1 Planning Report

More information

Interoperability Test Plan for International Voice services (Release 6) May 2014

Interoperability Test Plan for International Voice services (Release 6) May 2014 INTERNATIONAL INTERCONNECTION FORUM FOR SERVICES OVER IP (i3 FORUM) Workstream Technical Aspects Workstream Operations Interoperability Test Plan for International Voice services (Release 6) May 2014 Interoperability

More information

WHITE PAPER NON-GEOGRAPHIC E-911 SERVICES FOR SIP TRUNKING

WHITE PAPER NON-GEOGRAPHIC E-911 SERVICES FOR SIP TRUNKING WHITE PAPER NON-GEOGRAPHIC E-911 SERVICES FOR SIP TRUNKING NON-GEOGRAPHIC E-911 SERVICES FOR SIP TRUNKING Executive Summary Voice over Internet Protocol (VoIP) is emerging as the new standard for voice

More information

Preparatory Meeting for Phase 2 of Philippine National ENUM Trial

Preparatory Meeting for Phase 2 of Philippine National ENUM Trial Preparatory Meeting for Phase 2 of Philippine National Trial IP Telephony Group Advanced Science and Technology Institute Department of Science and Technology December 12, 2005 NCC-CICT Dialing Scheme

More information

XML Document Management Architecture

XML Document Management Architecture XML Document Management Architecture Candidate Version 2.0 02 Dec 2010 Open Mobile Alliance OMA-AD-XDM-V2_0-20101202-C OMA-AD-XDM-V2_0-20101202-C Page 2 (30) Use of this document is subject to all of the

More information

Understanding Lync 911 for Enterprises

Understanding Lync 911 for Enterprises Understanding Lync 911 for Enterprises Introduction Microsoft Lync delivers a complete Enterprise Voice solution through an easy-to-use interface. Enhanced 911 (E911) support is a critical component of

More information

NENA Standard for Enhanced 9-1-1 (E9-1-1) Default Routing Assignments and Functions

NENA Standard for Enhanced 9-1-1 (E9-1-1) Default Routing Assignments and Functions NENA Standard for Enhanced 9-1-1 (E9-1-1) Default Routing Assignments and Functions NENA Standard for E9-1-1 NENA 03-008, Version 1, January 19, 2008 Prepared by: National Emergency Number Association

More information

NENA Recommended Standards For Local Service Provider Interconnection Information Sharing

NENA Recommended Standards For Local Service Provider Interconnection Information Sharing This document was replaced with version 2 on 8/1/2004 and being archived for historical purposes. NENA Recommended Standards For Local Service Provider Interconnection Information Sharing INTRODUCTION

More information

SIP: Ringing Timer Support for INVITE Client Transaction

SIP: Ringing Timer Support for INVITE Client Transaction SIP: Ringing Timer Support for INVITE Client Transaction Poojan Tanna (poojan@motorola.com) Motorola India Private Limited Outer Ring Road, Bangalore, India 560 037 Abstract-The time for which the Phone

More information

Geographic Information Systems (GIS)

Geographic Information Systems (GIS) What is GIS? Geographic Systems (GIS) Integration of hardware, software, and data for capturing, managing, analyzing, and displaying all forms of geographically referenced information. ~ Esri Digital map

More information

Location Information Interoperability of CAP and PIDF-LO for Early Warning Systems

Location Information Interoperability of CAP and PIDF-LO for Early Warning Systems Location Information Interoperability of CAP and PIDF-LO for Early Warning Systems Karl Wolf Vienna University of Technology karl.wolf@student.tuwien.ac.at ABSTRACT The Common Alerting Protocol (CAP) is

More information

Application Notes for Configuring Cablevision Optimum Voice SIP Trunking with Avaya IP Office - Issue 1.1

Application Notes for Configuring Cablevision Optimum Voice SIP Trunking with Avaya IP Office - Issue 1.1 Avaya Solution & Interoperability Test Lab Application Notes for Configuring Cablevision Optimum Voice SIP Trunking with Avaya IP Office - Issue 1.1 Abstract These Application Notes describe the procedures

More information

NENA Standard. Generic Requirements for an Enhanced 9-1-1 Selective Routing Switch. NENA-03-005 January 2004 (Original Issue)

NENA Standard. Generic Requirements for an Enhanced 9-1-1 Selective Routing Switch. NENA-03-005 January 2004 (Original Issue) NENA Standard Generic Requirements for an Enhanced 9-1-1 Selective Routing Switch NENA-03-005 January 2004 (Original Issue) Prepared by: National Emergency Number Association (NENA) Network Technical Committee

More information

Next Generation 9-1-1 Request for Proposal (i3 Functionality and Emergency Service IP Network) RFP # NCT-2011-23 ADDENDUM #3 12-May-10

Next Generation 9-1-1 Request for Proposal (i3 Functionality and Emergency Service IP Network) RFP # NCT-2011-23 ADDENDUM #3 12-May-10 Next Generation 9-1-1 Request for Proposal (i3 Functionality and Emergency Service IP Network) RFP # NCT-2011-23 ADDENDUM #3 12-May-10 This addendum provides answers to questions received in writing as

More information

Cisco Emergency Responder 9.0

Cisco Emergency Responder 9.0 Data Sheet Cisco Emergency Responder 9.0 Cisco Unified Communications Solutions unify voice, video, data, and mobile applications on fixed and mobile networks, enabling easy collaboration every time from

More information

Media Gateway Controller RTP

Media Gateway Controller RTP 1 Softswitch Architecture Interdomain protocols Application Server Media Gateway Controller SIP, Parlay, Jain Application specific Application Server Media Gateway Controller Signaling Gateway Sigtran

More information

1. Public Switched Telephone Networks vs. Internet Protocol Networks

1. Public Switched Telephone Networks vs. Internet Protocol Networks Internet Protocol (IP)/Intelligent Network (IN) Integration Tutorial Definition Internet telephony switches enable voice calls between the public switched telephone network (PSTN) and Internet protocol

More information

Session Initiation Protocol (SIP)

Session Initiation Protocol (SIP) Session Initiation Protocol (SIP) An Alcatel Executive Briefing August, 2002 www.alcatel.com/enterprise Table of contents 1. What is SIP?...3 2. SIP Services...4 2.1 Splitting / forking a call...4 2.2

More information

ACCELERATOR 6.3 ASTERISK 1.4 INTEGRATION GUIDE

ACCELERATOR 6.3 ASTERISK 1.4 INTEGRATION GUIDE ACCELERATOR 6.3 ASTERISK 1.4 INTEGRATION GUIDE October 2014 Tango Networks, Inc. phone: +1 469-229-6000 3801 Parkwood Blvd, Suite 500 fax: +1 469-467-9840 Frisco, Texas 75034 USA www.tango-networks.com

More information

SERIES A : GUIDANCE DOCUMENTS. Document Nr 3

SERIES A : GUIDANCE DOCUMENTS. Document Nr 3 DATRET/EXPGRP (2009) 3 - FINAL EXPERTS GROUP "THE PLATFORM FOR ELECTRONIC DATA RETENTION FOR THE INVESTIGATION, DETECTION AND PROSECUTION OF SERIOUS CRIME" ESTABLISHED BY COMMISSION DECISION 2008/324/EC

More information

ETSI TS 184 011 V3.1.1 (2011-02) Technical Specification

ETSI TS 184 011 V3.1.1 (2011-02) Technical Specification TS 184 011 V3.1.1 (2011-02) Technical Specification Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Requirements and usage of E.164 numbers in NGN and

More information

Need for Signaling and Call Control

Need for Signaling and Call Control Need for Signaling and Call Control VoIP Signaling In a traditional voice network, call establishment, progress, and termination are managed by interpreting and propagating signals. Transporting voice

More information

Feature and Technical

Feature and Technical BlackBerry Mobile Voice System for SIP Gateways and the Avaya Aura Session Manager Version: 5.3 Feature and Technical Overview Published: 2013-06-19 SWD-20130619135120555 Contents 1 Overview...4 2 Features...5

More information

T5.4: Routing, Location-based Information and Caller ID

T5.4: Routing, Location-based Information and Caller ID T5.4: Routing, Location-based Information and Caller ID Table of content Introduction... 2 Terminology... 2 IP-based emergency services access... 3 Emergency Call Identification... 4 Call Routing... 5

More information

NENA Technical Requirements Document On Model Legislation

NENA Technical Requirements Document On Model Legislation NENA Technical Requirements Document On Model Legislation NENA Technical Requirements Document on Model Legislation, Standards Advisory Board Approval Date, January 13, 2011 NENA Executive Board Approval

More information

AMENDMENT NO. 1. to the INTERCONNECTION AGREEMENT. between

AMENDMENT NO. 1. to the INTERCONNECTION AGREEMENT. between AMENDMENT NO. 1 to the INTERCONNECTION AGREEMENT between VERIZON NORTH INC., F/K/A GTE NORTH INCORPORATED AND CONTEL OF THE SOUTH, INC., D/B/A VERIZON NORTH SYSTEMS and ALLBAND COMMUNICATIONS COOPERATIVE

More information

SBC 1000 / SBC 2000 Series Configuration Guide (For Microsoft Lync Server 2013)

SBC 1000 / SBC 2000 Series Configuration Guide (For Microsoft Lync Server 2013) Configuration Guide SBC 1000 / SBC 2000 Series Configuration Guide (For Microsoft Lync Server 2013) For use with AT&T s IP Flexible Reach Enhanced Features Service on MIS, MPLS PNT or AT&T VPN Disclaimers

More information

NENA Call Answering Standard/Model Recommendation

NENA Call Answering Standard/Model Recommendation NENA Call Answering NENA Call Answering Document 56-005 June 10, 2006 Prepared by: National Emergency Number Association (NENA) Standard Operating Procedures Committee, Calltaking Working Group Published

More information

plantemoran.com Enterprise E911 A Primer

plantemoran.com Enterprise E911 A Primer plantemoran.com Enterprise E911 A Primer Why Worry About E911? Why Worry? Increased capabilities of IP Telephony: Enhanced networking capabilities Quick & Easy phone MAC s Share Trunk Groups Single Virtual

More information

SIP Essentials Training

SIP Essentials Training SIP Essentials Training 5 Day Course Lecture & Labs COURSE DESCRIPTION Learn Session Initiation Protocol and important protocols related to SIP implementations. Thoroughly study the SIP protocol through

More information

WiMAX Forum Network Requirements

WiMAX Forum Network Requirements Requirements for WiMAX VoIP Services (WVS) Phase- WMF Approved (0-0-0) WiMAX Forum Proprietary Copyright 0 WiMAX Forum. All Rights Reserved. 0 0 0 0 Copyright Notice, Use Restrictions, Disclaimer, and

More information

Application Notes for Configuring Avaya IP Office 9.0 with HIPCOM SIP Trunk Issue 1.0

Application Notes for Configuring Avaya IP Office 9.0 with HIPCOM SIP Trunk Issue 1.0 Avaya Solution & Interoperability Test Lab Application Notes for Configuring Avaya IP Office 9.0 with HIPCOM SIP Trunk Issue 1.0 Abstract These Application Notes describe the procedures for configuring

More information

3GPP TS 24.623 V8.1.0 (2008-09)

3GPP TS 24.623 V8.1.0 (2008-09) TS 24.623 V8.1.0 (2008-09) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Extensible Markup Language (XML) Configuration Access Protocol

More information

Integrating Avaya Aura Presence Services with Microsoft OCS

Integrating Avaya Aura Presence Services with Microsoft OCS Integrating Avaya Aura Presence Services with Microsoft OCS 6.1 Service Pack 5 December 2012 Contents Chapter 1: Introduction... 5 Overview - OCS/Lync integration... 5 The Presence Services server and

More information

Implementing Intercluster Lookup Service

Implementing Intercluster Lookup Service Appendix 11 Implementing Intercluster Lookup Service Overview When using the Session Initiation Protocol (SIP), it is possible to use the Uniform Resource Identifier (URI) format for addressing an end

More information

Building a Scalable Numbering Plan

Building a Scalable Numbering Plan Building a Scalable Numbering Plan Scalable Numbering Plan This topic describes the need for a scalable numbering plan in a VoIP network. Dial Plans Dial plans contain specific dialing patterns for a user

More information

Integration of GSM Module with PC Mother Board (GSM Trunking) WHITE/Technical PAPER. Author: Srinivasa Rao Bommana (srinivasrao.bommana@wipro.

Integration of GSM Module with PC Mother Board (GSM Trunking) WHITE/Technical PAPER. Author: Srinivasa Rao Bommana (srinivasrao.bommana@wipro. (GSM Trunking) WHITE/Technical PAPER Author: Srinivasa Rao Bommana (srinivasrao.bommana@wipro.com) Table of Contents 1. ABSTRACT... 3 2. INTRODUCTION... 3 3. PROPOSED SYSTEM... 4 4. SOLUTION DESCRIPTION...

More information

This specification this document to get an official version of this User Network Interface Specification

This specification this document to get an official version of this User Network Interface Specification This specification describes the situation of the Proximus network and services. It will be subject to modifications for corrections or when the network or the services will be modified. Please take into

More information

How to Configure the Avaya IP Office 6.1 for use with Integra Telecom SIP Solutions

How to Configure the Avaya IP Office 6.1 for use with Integra Telecom SIP Solutions How to Configure the Avaya IP Office 6.1 for use with Integra Telecom SIP Solutions Overview This document provides a reference for configuration of the Avaya IP Office to connect to Integra Telecom SIP

More information

End-2-End QoS Provisioning in UMTS networks

End-2-End QoS Provisioning in UMTS networks End-2-End QoS Provisioning in UMTS networks Haibo Wang Devendra Prasad October 28, 2004 Contents 1 QoS Support from end-to-end viewpoint 3 1.1 UMTS IP Multimedia Subsystem (IMS)................... 3 1.1.1

More information

Session Initiation Protocol (SIP) The Emerging System in IP Telephony

Session Initiation Protocol (SIP) The Emerging System in IP Telephony Session Initiation Protocol (SIP) The Emerging System in IP Telephony Introduction Session Initiation Protocol (SIP) is an application layer control protocol that can establish, modify and terminate multimedia

More information

Next Generation 9-1-1 (NG9-1-1)

Next Generation 9-1-1 (NG9-1-1) Plan for Next Generation 9-1-1 (NG9-1-1) prepared for State of Maine Emergency Services Communication Bureau January 2011 ARCHITECTURE ENGINEERING COMMUNICATIONS TECHNOLOGY AVIATION CIVIL CONSTRUCTION

More information

Enterprise Voice and Online Services with Microsoft Lync Server 2013

Enterprise Voice and Online Services with Microsoft Lync Server 2013 Course 20337B: Enterprise Voice and Online Services with Microsoft Lync Server 2013 Course Details Course Outline Module 1: Voice Architecture This module introduce Enterprise Voice features of Lync Server

More information

White paper. SIP An introduction

White paper. SIP An introduction White paper An introduction Table of contents 1 Introducing 3 2 How does it work? 3 3 Inside a normal call 4 4 DTMF sending commands in sip calls 6 5 Complex environments and higher security 6 6 Summary

More information

Interim Solution to route emergency calls from corporate networks

Interim Solution to route emergency calls from corporate networks Interim Solution to route emergency calls from corporate networks Jos Speeckaert VP Interconnect Voxbone This document is copyright 2010 VOXBONE. All rights reserved. Agenda About Voxbone Routing issues

More information

IP Office Technical Tip

IP Office Technical Tip IP Office Technical Tip Tip no: 188 Release Date: September 27, 2007 Region: GLOBAL Verifying IP Office SIP Trunk Operation IP Office back-to-back SIP Line testing IP Office Release 4.0 supports SIP trunking.

More information

Introduction to VoIP Technology

Introduction to VoIP Technology Lesson 1 Abstract Introduction to VoIP Technology 2012. 01. 06. This first lesson of contains the basic knowledge about the terms and processes concerning the Voice over IP technology. The main goal of

More information

System Description and Requirements Document

System Description and Requirements Document Next Generation 9-1-1 (NG9-1-1) System Initiative System Description and Requirements Document Washington D.C. October 10, 2007 Version 2.0 Introduction Enterprise Over. Cap. Use Cases Func. Act./ Req.

More information

Oracle Communications Network Charging and Control. Session Initiation Protocol (SIP) Protocol Implementation Conformance Statement Release 5.0.

Oracle Communications Network Charging and Control. Session Initiation Protocol (SIP) Protocol Implementation Conformance Statement Release 5.0. Oracle Communications Network Charging and Control Session Initiation Protocol (SIP) Protocol Implementation Conformance Statement Release 5.0.2 July 2014 Copyright Copyright 2014, Oracle and/or its affiliates.

More information