Prepared for: Federal Communications Commission CMS Alliance to Modernize Healthcare Federally Funded Research and Development Center Building a Center of Expertise for the FCC’s Telecommunications Relay Service (TRS) Health Improvement Activities Contract No. HHSM-5000-2012-000081 Task Order No. FCC15D0002 VRS Auto-Routing Proof-of-Concept Prototype Cookbook Final Draft For Pubic Release – In Accordance with Data Rights Version 0.5 [Cookbook Section Only] September 29, 2015 This technical data was produced for the U.S. Government under Contract Number HHSM-500-2012-000081, Task Order FCC15D0002, and is subject to Federal Acquisition Regulation Clause 52.227-14, Rights in Data-General. For further information, please contact The MITRE Corporation, Contracts Office, 7515 Colshire Drive, McLean, VA 22102-7539 (703) 983-6000. The views, opinions, and/or findings contained in this report are those of The MITRE Corporation and should not be construed as official government position, policy, or decision unless so designated by other documentation. Approved for Public Release No. 15-3092; Disbribution Unlimited. © 2015, the MITRE Corporation. All Rights Reserved. MITRE 7515 Colshire Drive McLean, Virginia 22102 For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission VRS Auto-Routing Proof-of-Concept Prototype Cookbook i Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights Record of Changes No. Date Reference A=Add M=Modify D=Delete Description of Change 0.1 May 29, 2015 A Initial Annotated Table of Contents 0.2 July 21, 2015 All M Cookbook Section Only 0.3 August 19, 2015 M Revised configuration files in subsections 2.4.1–9 Updated document based on comments from version 0.2 0.4 August 27, 2015 All A/M/D Incorporate comments to version 0.3 0.5 September 29, 2015 November 5, 2015 All A/M/D Final draft, with replacement of Executive Summary by Foreword; revisions throughout. Approved for Public Release For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission VRS Auto-Routing Proof-of-Concept Prototype Cookbook i Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights Foreword The FCC Telecommunications Relay Service (TRS) COE Project promotes the Commission’s goal to foster innovations that advance functionally equivalent telecommunications. Toward that end, the project ensures that the Telecommunications Relay Service employs improved technology for persons who are deaf, hard of hearing, deaf-blind, and/or have speech disabilities. The FCC has embraced a research-based approach to achieve this goal by engaging The MITRE Corporation to conduct independent engineering assessments that promote and demonstrate TRS’s functional equivalence. MITRE is independently assessing voice telephone services, video access services, and Internet Protocol (IP)-based captioning technology; improvements to TRS efficiency; solutions for direct communication between people with communication disabilities and other telephone users; and the effectiveness, efficiency, and consumer response to current and future approaches for delivering TRS. Recently, the FCC directed MITRE to prototype an innovation for auto call routing (ACR): enabling direct calling from a Video Relay Service (VRS) customer to an American Sign Language (ASL)-trained agent for call handling. MITRE is testing and validating that the ACR prototype can scale from a single ASL-trained agent to call centers serving larger agencies. MITRE has successfully demonstrated the feasibility of auto-routing a VRS user’s call into a federal call center to reach a customer service representative with VRS capabilities. The demonstration considered a call center scale equivalent to the Social Security Administration (SSA), FCC, Equal Employment Opportunity Commission (EEOC), Internal Revenue Service (IRS), and Centers for Medicare & Medicaid Services (CMS). Specifically, the FCC tasked MITRE to: 1. Develop a proof-of-concept, or prototype, to provision Auto Call Routing (ACR) at the FCC (single agent) and then a larger agency effort (for example SSA, supporting 10+ agents), and identify relevant technologies, protocols, and/or procedures that enable a VRS user to: a. Call directly into the agency using a standard customer 1-800 service number b. Be routed automatically to an ASL-trained agent for call handling c. Manage a queue of multiple incoming calls routed to multiple ASL-trained agents d. Support the successful handling of that call (formal Demonstration) 2. Identify specific emerging technologies, trends, and approaches that: a. Support recognizing the source of the incoming call (from a VRS) b. Include the capability to automatically route that incoming call to a VRS-trained handler c. Identify direct communication alternatives for incorporation into technology challenges and other acquisition strategies For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept ii Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights 3. Conduct demonstrations for the FCC and other federal agencies, such as the EEOC and SSA, and prepare a demonstration of the Auto Call Routing operational prototype for several federal agencies at the White House Conference Center in the Eisenhower Executive Office Building. For the ACR, MITRE developed and tested a core function of call center Private Branch Exchange (PBX) functions, including the auto call routing based on agent queues, incoming dialed number, and call management. MITRE also built an Integrated ASL Video Response (IAVR) capability. MITRE researched, edited configuration files, scripted the dial plan for incoming call flow, and tested currently available open source video telephony and call management technologies needed to support direct call center response and queue management for up to ten (10) simultaneous direct video calls. These calls originate from deaf and hard-of- hearing individuals using a standard videophone with real-time video connection to an ASL- trained agent within an organization’s call center. MITRE is also testing multiple vendor and open source products across current platforms, including computer-based video, desktop integration, and handheld mobile video over secure wireless, hotspot, and traditional secure network connections. Testing of core ACR functions covers provider endpoint video phones, open source softphones, commercially licensed softphones, and desktop telephony applications. In addition, MITRE drafted this implementation guide to provide a specific technical “cookbook” section for guiding and assisting developer teams with the setup, configuration, and test of the ACR proof of concept. The primary audience for this document is the standard call center technical team. Specific configuration sections are included for the senior systems engineer and identifies core network, programming, and computing infrastructure skills, experience, and competencies that should also form part of the audience and team. The ACR cookbook’s detailed instructions address the configuration of an open source Session Initiation Protocol (SIP) PBX using the MITRE-developed direct video call (DVC) ACR Proof of Concept. The cookbook facilitates replicating the auto-routing configuration, which enables a direct video call from a vendor endpoint device to an ASL-proficient customer service representative’s desktop. The ACR cookbook describes how to integrate the ACR prototype with current call center workflow to provide an independent, on-demand service. The ACR cookbook provides the context and technical descriptions of the components (open source, off the shelf, licensed, and/or uniquely built/configured) to support the on-demand service. Its examples of the setup/configuration steps, scripts, programs, and command sequences will support a specific set of use cases and tests. The cookbook also supplies documentation for implementing the recommended approach successfully within the agency call center. MITRE and the FCC jointly decided to make the ACR cookbook a publicly released document. It may be downloaded from the TRS-COE.org portal for use by commercial entities and in open source forums. For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission VRS Auto-Routing Proof-of-Concept Prototype Cookbook i Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights Table of Contents 1. Introduction .................................................................................................................. 1 1.1 Background ......................................................................................................................1 1.2 Purpose .............................................................................................................................1 1.3 Goals .................................................................................................................................1 1.4 Development Approach ....................................................................................................2 1.5 Supplemental Documentation ..........................................................................................3 1.6 Dependencies ...................................................................................................................4 1.7 Document Organization ...................................................................................................4 2. Primary Cookbook Sections ........................................................................................ 6 2.1 Conceptual Review ..........................................................................................................6 2.1.1 Conceptual System Overview ...............................................................................7 2.2 Requirements ..................................................................................................................12 2.3 Design .............................................................................................................................15 2.4 Configuration .................................................................................................................16 2.4.1 Filename: enum.conf: .........................................................................................18 2.4.2 Filename: rtp.conf: ..............................................................................................19 2.4.3 Filename: http.conf: ............................................................................................19 2.4.4 Filename: queues.conf: .......................................................................................19 2.4.5 Filename: manager.conf......................................................................................20 2.4.6 Filename: extensions.conf ..................................................................................20 2.4.7 Filename: sip.conf ...............................................................................................23 2.4.8 Filename: [network:interfaces.d] eth0.cfg: .........................................................25 2.4.9 SIP Proxy Files ...................................................................................................26 2.5 Test Planning ..................................................................................................................27 2.5.1 Test Planning: Actionable Items .........................................................................27 2.6 Release Plan ...................................................................................................................27 2.7 Shared Services ..............................................................................................................29 2.7.1 Develop the Near-term Tactical Plans ................................................................29 2.7.2 Task-Specific Prioritization and Baseline Metrics .............................................29 3. Proposed Next Steps................................................................................................... 32 Appendix A. IETF RFC .................................................................................................. 34 Appendix B. Extensions File ........................................................................................... 35 Appendix C. SIP.CONF .................................................................................................. 58 Appendix D. Queues ........................................................................................................ 69 Appendix E. Detailed Recommendations by Topic Area ............................................ 82 For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept ii Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights E.1 Requirements and Design (RD) .....................................................................................82 E.2 Security (S) .....................................................................................................................83 E.3 Connectivity (C) .............................................................................................................84 E.4 Disaster Recovery and Business Continuity (DRBC) ....................................................85 Appendix F. Proposed Stacks ......................................................................................... 90 Appendix G. Notional Level of Effort ............................................................................ 97 Appendix H. Essentials of the IPT and IPPD ............................................................... 98 Appendix I. Test Strategy ............................................................................................. 102 I.1 Virtual Machine Configuration and Storage Infrastructure .........................................102 I.2 Test Data Approach ......................................................................................................106 I.3 Authorization and Authentication ................................................................................110 I.4 Virtual Machine Capacity Growth ...............................................................................110 I.5 Call Center Deployment Plan .......................................................................................111 I.6 Change and Configuration Management Tasks ...........................................................112 I.7 Testing Facility Service Desk Tasks ............................................................................113 Appendix J. Sample Test Matrix ................................................................................. 117 Acronyms ........................................................................................................................ 124 List of References ........................................................................................................... 128 For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission VRS Auto-Routing Proof-of-Concept Prototype Cookbook i Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights List of Figures Figure 1. Standard Asterisk Overview ............................................................................................ 7 Figure 2. Notional POC Baseline.................................................................................................... 8 Figure 3. IPPD Iterative Process ................................................................................................... 99 List of Tables Table 1. Notional Example: Service Performance Metrics for Availability and Reliability .......... 9 Table 2. Workflow Requirements ................................................................................................. 14 Table 3. Specific Use Case Settings ............................................................................................. 17 Table 4. Proposed Risk Mitigation ............................................................................................... 87 Table 5. POC-supported System Platforms and Middleware Components in the Development Environment – NOTIONAL ..................................................................... 93 Table 6. POC-supported System Platforms and Middleware Components in the Test Environment – NOTIONAL ........................................................................................... 94 Table 7. POC-supported System Platforms and Middleware Components in the Operational Environment – NOTIONAL ........................................................................................... 95 Table 8. Supported Tools for All Environments – NOTIONAL .................................................. 96 Table 9. Sample Test Matrix ....................................................................................................... 119 For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 1 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights 1. Introduction 1.1 Background At the request of the Federal Communications Commission (FCC), The MITRE Corporation (MITRE) drafted a Direct Video Connectivity (DVC) Auto-Routing Proof of Concept in support of the FCC’s Telecommunications Relay Service (TRS) Health Improvement Activities. This auto-routing proof of concept enables direct calling from deaf and hard of hearing individuals to an American Sign Language (ASL)-trained agent within the organization’s call center for call handling using a video capable phone with real-time video connection. The MITRE Project Team explored, researched, and tested a variety of current video telephony technologies as a functionally equivalent means of two-way communication with real-time video. MITRE is testing the multiple vendor and open source products across current platforms, including computer-based video, desktop, and handheld mobile video over wireless, Wi-Fi, and traditional network connections. 1.2 Purpose The purpose of this document is to provide a detailed guide on the configuration of an open source Session Initiation Protocol (SIP) Private Branch Exchange (PBX) to develop a Direct Video Connectivity (DVC) Auto-Routing Proof of Concept, and support a direct call from deaf and hard of hearing individuals using a video capable phone with real-time video connection directly to an ASL-trained agent within an agency, company, or organization’s call center for call handling. MITRE has prepared this proof of concept cookbook to describe the recommended approach for explaining a specific configuration and implementation of auto-routing a direct video call from a user endpoint to a customer service representative (CSR). It contains examples of the setup/configuration steps, scripts, programs, and command sequences used to run a specific set of use cases and tests. 1.3 Goals The primary goals for creating this proof of concept and the associated cookbook are: ? Identify specific emerging technologies, trends, and approaches that support the expected types of incoming calls; be able to automatically route the incoming call as a direct communication to an ASL-trained point of contact within an agency, organization, or company ? Acquire and configure relevant enabling technologies in the MITRE test laboratory, and develop a prototype using the Open Source Asterisk PBX software as a baseline ? Demonstrate an alternative direct contact provision for deaf and hard of hearing video users to a designated ASL agent at an agency, organization, or company; this technology For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 2 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights will support a new service and provide more efficient and additional access to existing methods. ? Research and identify relevant technologies, protocols, and/or procedures that enable a deaf or hard of hearing user to call directly into the agency using a standard customer service number and automatically route the call to an ASL-trained agent at an agency, organization, or company ? Analyze the results of the innovations through iterative usability testing to identify alternatives and make assessments based on the testing results ? Provide technology, security, and process recommendations ? Document results and proof-of-concept lessons learned from initial requirements and use case analysis, and deliver the documented results to the FCC for review and comment in the form of a “cookbook” 1.4 Development Approach To ensure efficient use of resources, it is essential to understand what activities are necessary and how they affect the product and each other. The proof of concept is based on open source as a development model and promotes universal access via a free license to a product’s design or blueprint, and universal redistribution of that design or blueprint, including subsequent improvements to it.1 Open source refers to a computer program in which the source code is available to the general public for use and/or modification from its original design. Open-source code is meant to be a collaborative effort, where programmers improve upon the source code and share the changes within the community. The open-source model is based on a decentralized model of production. A main principle of open source software development is peer production, with products such as source code, “blueprints”, and documentation available to the public at no cost. As part of the development process for the Cookbook, the MITRE team researched and reviewed extensive materials, including: ? Open Source Asterisk PBX documentation ? Existing Open Source SIP and PBX operations and maintenance (O&M) policies ? Procedures documentation of production systems ? Existing operational documents for direct video calls and call center operations MITRE also interviewed several Open Source SIP and PBX subject matter experts (SME) to gain insight into the policies and procedures for operating and maintaining production systems. MITRE based the proof of concept auto-routing prototype and demonstration on unified communications and the Internet Protocol (IP) PBX architecture2. MITRE extended the baseline 1 http://opensource.org/ 2 http://www.asterisk.org/get-started/applications/pbx For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 3 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights using modular functions such as the automated attendant, video and voice messaging, and call queuing. The communications platforms continue to expand beyond email, instant messaging, video conferencing, desktop sharing, Short Message Service (SMS), and mobile telephony. MITRE implemented an Integrated Product Team (IPT) and Integrated Process and Process Development (IPPD) approach to the proof of concept. The approach includes the following activities (further defined and explained in Appendix H. , Essentials of the IPT and IPPD): ? Understanding the requirements ? Outlining the approach ? Planning the effort ? Allocating resources ? Executing and tracking the plan 1.5 Supplemental Documentation MITRE relied on the following supplemental documentation to support the recommended approach detailed in this cookbook: ? A Business Requirements Document (BRD) helps to shape the business requirements. Developed in concert with the cookbook, the BRD includes diagrams of workflows, a responsibility matrix, and detailed mapping of the As-Is work stream to the best practice. (Please see subsection 2.2, Requirements.) ? Asterisk™: The Definitive Guide, Fourth Edition, by Russell Bryant, Leif Madsen, and Jim Van Meggelen, Copyright 2013 ? The Asterisk Cookbook, by Russell Bryant, Leif Madsen, Copyright 2013 ? The Asterisk Guru, http://www.asteriskguru.com/ ? Asterisk, The Definitive Guide, http://asteriskdocs.org/en/3rd_Edition/asterisk-book- html-chunk/index.html ? Asterisk Quick Start Guide: http://www.asterisk.org/sites/asterisk/files/mce_files/documents/asterisk_quick_start_gui de.pdf ? Asterisk Step-by-step Installation, http://www.voip-info.org/wiki/view/Asterisk+Step-by- step+Installation ? Asterisk, http://www.asterisk.org/ ? iTRS ENUM Database, https://www.neustar.biz/services/network-routing-and- addressing/itrs-enum-database ? Asterisk Project Documentation, https://wiki.asterisk.org/wiki/display/AST/Include+Statements ? Current Asterisk News, http://www.venturevoip.com/news.php ? Appendix A - Internet Engineering Task Force (IETF) Request for Comments (RFC) For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 4 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights 1.6 Dependencies MITRE recommends addressing the following dependencies to implement the proof of concept properly: ? Executive Support – Sponsor leadership must be solidly behind an implementation, or needed changes will not happen at the business unit, program, or system levels. ? Cultural Change – The Sponsor must understand and agree that a change in strategy or culture is needed. Changing an organization requires shifting resources from some areas into others. Stakeholders must be willing to make the change.3 ? Business Process Reengineering – Effective redesign of business processes requires optimizing business processes to achieve dramatic improvements in productivity, cycle times, and quality.4 ? Technology Enablement – Robust connectivity and the use of agile computing services are two primary technical elements essential to success of this proof of concept. ? Continuous Improvement – A project team should continually seek opportunities to improve services and meet the needs of its customers. ? Resource Realignment – Information technology (IT) requirements continue to grow. Accommodating these requirements typically means moving financial and personnel resources from duplicated programs, systems, and workflows to new shared approaches within and between agencies. Adoption Strategy – The IPT should clearly state who is accountable, what the performance targets are, and how each transition will occur by using a roles and responsibility (RACI) matrix with assignments tasks. 1.7 Document Organization This document is organized as follows: Section Description Section 2: Primary Cookbook Sections Provides a high-level description of the Conceptual Review, Requirements, Design, Configuration, Testing, Release Plan, and Shared Services sections of the Cookbook. Section 3: Proposed Next Steps Provides a high-level summary of the recommendations in the Cookbook. Appendix A: IETF Request for Comment Presents a list of Internet Engineering Task Force resources. Appendix B: SIP.CONF Presents the Session Initiation Protocol configuration file. 3 http://guides.wsj.com/management/innovation/how-to-change-your-organizations-culture/ 4 http://www.bain.com/publications/articles/management-tools-business-process-reengineering.aspx For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 5 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights Section Description Appendix C: Extension Files Presents the Extensions configuration files for the video auto-routing proof of concept use case. Appendix D: Queues Presents the Queues code file. Appendix E: Detailed Recommendations by Topic Presents requirements recommendations in the areas of Requirements and Design, Security, Connectivity, and Disaster Recovery and Business Continuity. Appendix F: Proposed Stacks Provides an overview of the development and test environment stacks for the use case. Appendix G: Notional Levels of Effort Provide a notional level of effort example on previous experience using open source software, subject matter experts, and access to development and test environments. Appendix H: Essentials of the IPT and IPPD Presents a description of the IPT and IPPD. Appendix I: Test Strategy Provides a test strategy for the video auto-routing proof of concept. Appendix J: Sample Test Matrix Provides a sample text matrix for the video auto- routing proof of concept use case. Acronyms Defines the acronyms used in this document List of References Lists the sources used in preparing this document For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 6 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights 2. Primary Cookbook Sections There are seven primary subsections to the core cookbook: 1. Conceptual Review: Develop an overall understanding of the Open Source Asterisk PBX software, operating system, endpoint devices, and call center workflow 2. Requirements: Develop a core set of realistic, accurate, and traceable requirements for the auto-routing proof of concept 3. Design: Draft an initial design of the workflow based on the core set of requirements 4. Configuration: Configure the key variables, settings, and control logic 5. Test Planning: Draft test plan and use cases 6. Release Plan: Draft plan for release and implementation 7. Shared Services: Develop tactical plans for managing the impact of the development and test infrastructure and the call center facilities The project team is the primary audience for this document. There are specific configuration sections for the senior systems engineer with core network, programming, and computing infrastructure skills, experience, and competencies. The proof of concept is based on the open source development model, which promotes universal access via a free license to a product’s design or blueprint, and universal redistribution of that design or blueprint, including subsequent improvements to it.5 Appendix F, Proposed Stacks, provides an overview of the development and test environment stacks that should be reviewed to aid in the decision to build the development and test platform for the proof of concept. 2.1 Conceptual Review The conceptual review phase includes additional research, planning, and recommendations about the following key areas: ? Concept of Channels and Dial Plans ? Core Modules ? End User Devices ? Call Center Workflow ? User ASL agent Desktop ? Visual Interactive Voice Response (IVR) ? Automatic Call Distribution (ACD)/IVR/Dialer Infrastructure Systems 5 http://opensource.org/ For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 7 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights ? Application Design – Design Business Rules, Workflows, and Routing Strategies ? Availability ? Scalability ? Geographic Coverage The primary setup includes a basic dial plan and support for a variety of endpoint destinations (e.g., cell phone, VoIP endpoint, remote PBX) 2.1.1 Conceptual System Overview A traditional implementation of the Asterisk PBX (as shown in Figure 1) supports an out-of-the box installation and configuration. The primary setup includes a basic dial plan and endpoint devices. 6 Figure 1. Standard Asterisk Overview As depicted in Figure 2, the current POC baseline builds off of the standard Asterisk SIP flow and supports a SIP Proxy Server (e.g., Kamailio, http://www.kamailio.org) to manage the SIP traffic. The Asterisk PBX servers are configured with specific inbound call queues and extensions. The POC baseline establishes a direct video communication workflow that introduces multiple devices that communicate primarily over the SIP protocol. “The SIP proxy acts as a router between the external peers, internal peers and the soft PBX. The soft PBX is a server running 6 http://astbook.asteriskdocs.org/en/2nd_Edition/asterisk-book-html/figs/web/ast2_1501.png For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 8 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights Asterisk. It is important to note that the soft PBX does not connect directly to the public Internet and none of the internal users connect directly to the soft PBX. SIP proxy servers are generally more stable and more secure than a software version of a PBX, and provide more connectivity options, including support for IPv6, TLS and WebRTC.”7 Figure 2. Notional POC Baseline After testing an initial setup, the secure configuration (e.g., port 5061) and Secure RTP (SRTP) are added and tested to produce a more secure configuration as part of a supporting confidentiality, integrity, and privacy. 7 http://rtcquickstart.org/guide/multi/rtc-architecture.html For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 9 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights 2.1.1.1 Performance Characteristics The performance characteristics include such topics as bandwidth, computer or video phone CPU performance, resolution quality, and frame rate.8 A primary objective is to set a minimum standard for connectivity and preempt challenges from low-quality wireless or remote communication channels that do not provide sufficient bandwidth. During the test phase, an engineer can capture traffic traversing a network connection from an endpoint device to the PBX. As congestion is most likely to occur in infrastructure bottlenecks such as WAN interfaces, last-mile connections, and the end-user interfaces, the focus is to analyze the data captured in order to identify, classify, and mark the applications/protocols. The test engineer will also identify strategic locations to capture the data to provide the best current view of traffic flow. The data collected can also be used for capacity planning. 2.1.1.2 Availability and Reliability The standard definition of availability is the percentage of time a system is considered ready to use when tasked, while reliability is the probability of zero failures over a defined time interval.9 Evaluating and updating performance metrics for availability and reliability depends on several considerations: ? Leveraging government/industry best practices ? Expectations of increased effectiveness in service delivery ? Increased availability/reliability based on improved technology ? Performance history Table 1 presents a notional table used to document availability and reliability metrics, and their relative priority High = H, Medium = M, and L = Low) based on notional services and their current requirements Table 1. Notional Example: Service Performance Metrics for Availability and Reliability Service (Notional) Priority (H,M,L) Current Requirement Availability (New Metric) Reliability (New Metric) Connectivity Services – Authentication H Connectivity Services – DNS H 8 http://eeweb.poly.edu/faculty/yongliu/docs/infocom2014.pdf 9 http://www.mitre.org/publications/systems-engineering-guide/acquisition-systems-engineering/integrated- logistics-support/reliability-availability-and-maintainability For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 10 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights Service (Notional) Priority (H,M,L) Current Requirement Availability (New Metric) Reliability (New Metric) Connectivity Services – Dynamic Host Configuration Protocol (DHCP) M Connectivity Services – Network & Internet Access M Connectivity Services – Network Performance (Tier I and II) M Connectivity Services – Remote Access VPN M Connectivity Services – Site Surveys L The typical performance measures for assessing and reporting the availability of a service or component operate on the following assumptions: ? Priority (and associated metrics) for core services across different networks will vary based on Providers and the end user’s connection. ? Providers will be measured at the same priority as services they feed downstream to endpoints. 2.1.1.3 Interoperability, System Interconnection / Information Sharing Endpoint devices that use the Internet for network transport allow users to connect from various access points for Voice over Internet Protocol (VoIP) voice services. An encoder converts the network user’s voice, data, or even video to a digital IP -based packet format for transmission. The IP-based formatting and addressing structure provides interoperability. The FCC requirement specifies that all of the appropriate users are addressed correctly, and traffic passes through the router to the appropriate end-user devices on the Internet.10 The distinction between Communications Services and Enterprise Services can create ambiguity. To clarify, Communications Services consist of such basic capabilities as access, connection establishment, and packet routing. Communications Services typically are offered in voice, video, and data networks... Specific elements such as switches, gateways, routers, and firewalls support the provision of Communications Services. Directories, ACDs, and IVRs are examples of elements that enable Enterprise Services. 10 https://transition.fcc.gov/pshs/techtopics/tech-ip-interop.html For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 11 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights 2.1.1.3.1 Communications Services Communications Services provide interconnectivity among applications, systems, and people. This layer is implemented both inside the sponsor enterprise—for example, the Local Area Network (LAN)—and external to the sponsor enterprise (for example, a public telephone network carrier). Included in this layer are data networks [metropolitan area networks (MAN) and wide area networks (WAN)], voice networks, video networks, and wireless networks. This layer also includes telephone switches, gateways, automatic call distribution, network routers and switches, firewalls, and network security monitoring systems. The focus of Communications Services is on the secure, reliable transport of voice, video, or data between endpoints. It includes the protection and integrity of information in transit, the protection of communication systems from external disruptions, and response to network issues and incidents. 2.1.1.3.2 Enterprise Services Enterprise Services comprise a set of common capabilities deployed across the enterprise. These services are shared IT infrastructure components that mediate relationships between applications throughout the enterprise. Higher-level communications support functions are classified as Enterprise Services rather than Communication Services. These support functions include call routing based on caller information and the location of employees with the necessary skills to handle the call. Similarly, computer telephony integration functions, such as interfaces to databases to support screen pops, are also classified as Enterprise Services. The rationale for these classifications is that the higher-level functions require platforms and data to operate, while the communications transport does not. Web Application Services provide a Web-based application execution environment that allows implementation and management of information pages and call center business applications modules. Distributed application services provide capabilities that allow call center applications to communicate via synchronous or asynchronous mechanisms, including distributed objects such as Enterprise JavaBeans (EJB), .NET remoting, and remote procedure call. Directory services provide call center-centric repositories of information that can be accessed through a common application-programming interface (API) such as Lightweight Directory Access Protocol (LDAP). Messaging services provide mechanisms for the reliable and secure transport of commands and data between call center application programs. Messaging service capabilities include message queuing, guaranteed delivery, transaction support, and character code translation. Messaging services also provide for load balancing and fault tolerance among server processes and systems. Workflow services provide a means for defining and controlling the flow of call center information among users and automated functions in support of business processes. Logging services provide mechanisms to record nominal and exceptional call center events as required by legislation, sponsor business rules, and enterprise systems management. For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 12 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights Telephony and computer-telephony integration (CTI) services provide the ability to exchange control information among telephone switches, voice response units, and application programs to support customer service and telephone call center self-service systems. Data access services define interfaces and formats for exchanging call center information among applications, including but not limited to, markup languages. Software engineering services cover the technology associated with building/changing call center software systems as well as technical solutions supporting management issues, such as testing, modeling, and versioning. 2.1.1.4 Provisions for Security, Privacy, Integrity, and Contingency The security requirements, including the Information Security Acceptable Risks Safeguards and any security requirements in the design, should provide information on system access, generally accepted security principles, and specific application security requirements. The design should also provide security requirements that include encryption of call setup and payload. Because this is part of the effort that extends beyond the initial release of the POC, there are several areas to emphasize: ? The Open Source technical architecture should have a cross-reference for each of the configurations denoting security requirements and providing information on how the design complies with the requirements for a vulnerability assessment. The cross- reference can provide a security compliance checklist that can be reused with additional implementations of the technical architecture. ? The design should specify POC configuration information to cross-reference the configuration settings necessary to maintain all hardware and software proposed in the technical architecture. A baseline configuration can provide a reliable starting point for guiding an installation or making updates to a baseline release. ? The design should include a processing view that provides operational requirements that include intrusion detection and monitoring specifications. ? The design should include a Protocol view that depicts all port assignments on all hardware for each processing layer (e.g., SIP Proxy, Asterisk PBX, Directory Services, and Database Services). Each open source application and server uses protocol ports at the network (transport) layer to manage communication channels between programs. The design should depict all ports used by hardware and software to help with the installation and configuration, and to assist with determining risk. 2.2 Requirements In the requirements phase, the project team researches each of the following areas, and prepares a statement of objectives and requirements. The requirements include the technical, operational, and functional needs of the specific use case in the proof of concept as follows: ? Multi-purpose signaling SIP server – SIP Router/Switch, SIP Registrar For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 13 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights – Application Server – Redirect Server – Load Balancer / Dispatcher – Back-to-Back User Agent – Presence Server, IM Server – Session Border Controller – SIP Front-End – Network Address Translation (NAT) Traversal Server – IP Gateway [(Short Message Service (SMS), Extensible Messaging and Presence Protocol (XMPP)] ? User, Administration, and Provisioning Portal ? PSTN (public switched telephone network) Gateway ? Media Server ? Media Proxy or Real-Time Protocol (RTP) Proxy for NAT Traversal ? Fundamental Accounting ? Call Detail Records (CDR) (storing and reporting) ? Monitoring Tools [OrderlyQ (Linux based) (http://www.orderlyq.com/) and AstChannelIsLive (Windows) (http://sourceforge.net/projects/astchannelslive/files/AstChannelsLive_5.0.2/)] ? User End Point Device and Softphone configurations ? Firewall Setting (Firewall and NAT devices must be SIP Aware) ? An understanding of Network Address Translation, Session Traversal Utilities for NAT (STUN), Traversal Using Relays around NAT (TURN), and Interactive Connectivity Establishment (ICE) For the current release of the POC, the source code and scripts are updated to support the following requirements: ? Standard PBX functions associated with the out-of-the-box Asterisk configuration files, including: – Call queuing – Call routing – Database integration – Number discovery – Local and remote agents – Video message on hold ? Adapted to support Provider endpoint device (e.g., ZVRS Z-20) ? Interactive Voice and Video Response: Video IVR Navigation via DTMF dial pad For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 14 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights ? Dial by name: Option to allow direct dialing to a specific ASL agent via extension ? Call detail records: Aggregate information on completed/abandoned calls (call time, length, call-back info, video mail, location, etc.) ? Basic monitoring: Dashboard overview for supervisors with call center metrics / performance management tools (such as queue info, interactions in progress, ASL agent statistics, etc.) Table 2 presents an initial capture of workflow requirements that demand additional planning, scoping, and discussion to guide a representative level of effort to extend the functionality of the POC. Table 2. Workflow Requirements Count Type Requirement 1 Contact Center ASL agent UX Transfer customer from one CSR to a specified queue. (A companion requirement, the transfer of a customer from a specific queue to a specific CSR, is premised on skills-based routing.) 2 Contact Center ASL agent UX Transfer customer into a voice queue inserting an interpreter 3 Contact Center ASL agent UX Visual alerting options for when receiving an incoming call [screen flash, toaster-style pop-up, Universal Serial Bus (USB) strobe light, etc.] 4 Contact Center ASL agent UX Switch outgoing video inputs among different feeds— webcam, screen sharing, image library 5 Contact Center ASL agent UX Enhanced Caller ID with info pulled from iTRS database / telco carrier / IP address / Customer Relationship Management (CRM) (caller’s name, phone number, city/state, etc.) 6 Contact Center ASL agent UX Video Whiteboard—ability to superimpose text/numbers onto outgoing video feed 7 Contact Center ASL agent UX Ability to transfer/escalate calls to another ASL agent or number (Warm, Tepid & Cold transfers) 8 Contact Center ASL agent UX Text chat with callers and fellow ASL agents ([IM or Real Time Text (RTT)] 9 Contact Center ASL agent UX 3-way video calling (VRS interpreter, supervisor, etc.) / A-B-C line switching 10 Contact Center ASL agent UX Accept Dual Tone Multi-Frequency (DTMF) dial pad input [confirmation numbers, Social Security Numbers (SSN) etc.] 11 Contact Center ASL agent UX Ability to quickly search for and pull up reference info (factsheets, call scripts, etc.) 12 Caller UX Visual IVR Navigation via DTMF dial pad 13 Caller UX Dynamic on-hold screen, including ACD wait time estimates, etc. For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 15 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights Count Type Requirement 14 Caller UX Ability to select and view videos via Video IVR—e.g., FCC video announcements made in ASL 15 Caller UX Display ASL agent’s name/ID/email address onscreen for caller 16 Caller UX Option to allow direct dialing to a specific ASL agent via extension 17 Caller UX Smart queueing, allows caller to leave video mail and/or request call-back 18 Contact Center Administration Visual IVR with ability to display different elements in rotation (images, videos, etc.) 19 Contact Center Administration An ability to support customization of ACD call flow routing rules 20 Contact Center Administration Automatic/predictive dial-out for idle ASL agents to fulfill call-back requests 21 Contact Center Administration Aggregate info on completed/abandoned calls (call time, length, call-back info, video mail, location, etc.) 22 Contact Center Administration Call recording/monitoring capabilities (incl. date/time stamp and caller ID information) 23 Contact Center Administration Computer/telephony integration API so Caller ID info “pops” into CRM automatically—displaying previous calls, caller information and notes as needed 24 Contact Center Administration Supervisor notification when callers have to wait beyond a configurable amount of time 25 Contact Center Administration Dashboard overview for supervisors with call center metrics / performance management tools (queue info, interactions in progress, ASL agent statistics, etc.) 26 Contact Center Administration Capability to listen in on calls, “whisper” to ASL agents (via translucent/separate video feed?), park calls and jump into calls if needed 27 Contact Center Administration Call disposition coding so calls can easily be categorized (e.g., info requests, complaints, referrals, and crazy individuals) 28 Contact Center Administration Video Conference bridge to allow for multi-party calls 29 Contact Center Administration RTT modem gateway to accept TTY/TDD calls, for ASL agent cross-utilization 30 Contact Center Administration Bridge to VRS to accommodate hearing callers if necessary (i.e., 3-way call with telecom carrier support) 2.3 Design The design phase requires the project team to define each Asterisk module, function, and capability that is active for the specific use case in this proof of concept. The modular and functional decomposition activities are integral to provide a cross-reference and traceability to the requirements and objectives. For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 16 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights From an architectural standpoint, Asterisk consists of many different modules. This modularity provides flexibility in the design of a SIP Auto-Routing system. From a system administration perspective, each module selected and loaded provides different capabilities to the system. For example, one module might allow the system to communicate with SIP, while another might add call-reporting capabilities. Asterisk has a core that interacts with many modules. Modules called channel drivers provide channels that follow a specific dial plan to execute programmed logic and facilitate communication between devices or programs external to the core. The channels often use bridging infrastructure to interact with other channels. The PBX core is the essential component that provides the primary infrastructure. The PBX core has many functions: it reads the configuration files, including dial plan, and loads all the other modules and distinct components that provide greater functionality. The dial plan contains a list of instructions to handle incoming and outgoing calls on the system. The following design checklist can be used to evaluate the success of a modular design. Each question should be answered in the affirmative.11 ? Does the design identify clearly defined modules? ? Does each module have a clearly defined purpose? (Can you summarize it in one sentence?) ? Is each module's interface sufficiently abstract that you do not need to think about its implementation in order to understand it? Does it hide its implementation details from other modules? ? Have you subdivided modules as far as usefully possible? ? Have you verified that different modules do not replicate functionality? ? Have you isolated those aspects of the design that are most hardware specific, complex, or otherwise likely to change? Appendix E, Detailed Recommendations by Topic Area, provides detail of design, and to some degree, operational, requirements. 2.4 Configuration The configuration section will specifically deal with configuration files needed to operate the Asterisk PBX server. These files are in the following appendices: ? Appendix B – SIP.CONF ? Appendix C – Extensions File ? Appendix D – Queues 11 http://www.mcs.anl.gov/~itf/dbpp/text/node40.html For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 17 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights The reader should refer to the Conceptual Review section for an overview of the main architecture components; however, the majority of Asterisk’s features and functionality are separated outside of the core into various modules. Each module has distinct functionality, but sometimes relies on another module or modules. Asterisk provides capability to load modules automatically and manually. Module load order can be configured before load-time, or modules may be loaded and unloaded during run-time. The configuration file for Asterisk’s module loader is modules.conf. It is read from the typical Asterisk configuration directory. The configuration consists of one large section called “modules” with possible directives configured within, including: ? Timing Interfaces ? Asterisk Built-in mini-HTTP Server ? Logging Configuration ? Asterisk Command Line Interface (CLI) Configuration ? Configuring the Asterisk Module Loader ? Configuring Localized Tone Indications ? Video Telephony Table 3 presents a summary of the specific proof-of-concept settings for the primary use case. It is important to research each Variable Assignment and assign a Variable Value for the test setup, and eventually for a live test from different endpoint devices and sponsor’s customer service desktops. Table 3. Specific Use Case Settings Variable Description Variable Assignment Examples Vendor Call Center registered number 703-570-1234 (replace with assigned number) Numbers to be used for softphone end user devices 703-265-5710 to 703-265-5720 (replace with selected numbers) Public Domain Name Service (DNS) ec2-54-86-14-195.compute-1.cloudserver.com (an example of a Linux server domain name, replace) Transport UDP Video Codec H.263, H.264 Audio Codec Ulaw/PCMA (µ-law Algorithm/Pulse Code Modulation alaw) Customer Service Representative (CSR) designated number 703-265-5721 to 703-265-5725 (replace) To register device as a video capable CRS dial [*10], to unregister dial [*15] For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 18 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights Variable Description Variable Assignment Examples To register device as an audio- capable CSR dial [*20], to unregister dial [*25] Google Stun Server stun.l.google.com:19302 (an example of a production STUN server, replace) The following subsections are detailed examples of specific configuration files and the configuration variable assignments that should be edited by the project team system engineer SME. This section of the document is used in a software development and testing life-cycle process. It is intended as part of the research, experiment, discovery, and test phase; it is not, however, intended as a production guide or to edit or update operational or live configuration files to an active production system. This section of the cookbook assumes the following tasks and supporting activities are in place prior to editing the configuration files: ? Read and review the resources in the previous section, Supplemental Documentation; these documents have the required research, lessons learned, commands, and code examples to create, test, and run a baseline instance of the Operating System, the Asterisk Server, and the endpoint devices. ? Design and document a dial plan workflow with realistic phone extensions. This draft dial plan and the associated workflow with extensions have the primary steps necessary to establish the baseline call routes. ? Establish a working and replicable development and test (dev/test) environment. The dev/test environments require simple, working change management and configuration management processes. These processes are useful to track and review code changes, maintain traceability to the test cases and requirements, and manage the level of effort associated with changes. – These environments require minimum connectivity and bandwidth requirements to support endpoint devices, primary proxy and PBX servers, and CSR desktops. The specifications are documented in the supplemental reading. – Prior to editing the following files, make a backup copy, and use the comment (‘;’) liberally to document your inline code changes. There are eight (8) configuration files that need changes to implement and test the auto-routing workflow. 2.4.1 Filename: enum.conf: ENUM: The bridge between the switched telephony network and the Internet (E.164 Number to URI Mapping) translates telephone numbers into Internet addresses. ENUM Configuration for resolving phone numbers over DNS, set the following: search => itrs.us Reference the following iTRS documentation: ? Internet-based Telecommunications Relay Service (iTRS) Customer User Guide For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 19 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights – Document: iTRS_User_Guide_5.0_v1.1 ? NeustarTM Addressing & Routing iTRS Provisioning Interface Guide – Document: iTRS_PI_Guide_5.0_v1.1 ? NeustarTM Addressing & Routing iTRS Query Interface Guide – Document: iTRS_QI_Guide_5.0_v1.1 2.4.2 Filename: rtp.conf: The configuration of Asterisk Real Time Protocol (RTP) media channels. RTP is used for SIP communications. RTP start and RTP end configure start and end addresses: rtpstart=10000 rtpend=20000 Interactive Connectivity Establishment (ICE) is used to facilitate Network Address Traversal and communications involving hosts on private network installations located behind firewalls. Enable ICE support: icesupport=true icesupport=yes 2.4.3 Filename: http.conf: To provide secure communications, enable the HTTP/HTTPS interface: enabled=yes In addition to enabled=yes, you need to explicitly enable Transport Layer Security (TLS), define the port to use, and have a certificate stored. The CA certificate must be known to all the clients to ensure certificate legitimacy. Set the path to the certificate file (*.pem): tlscertfile=/etc/ssl/certs/asterisk.pem Set the path to private key file (*.pem): tlsprivatekey=/etc/ssl/certs/asterisk.pem 2.4.4 Filename: queues.conf: These are the global settings for call queues, Queue Timing Options and Weight Queue Options. The frequency to announce queue position and/or estimated holdtime to caller (0=off): announce-frequency = 5 The absolute minimum time between the start of each queue position and/or estimated holdtime announcement min-announce-frequency = 2 For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 20 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights How often to make any periodic announcement (see periodic-announce) periodic-announce-frequency=10 ; To announce the Queue position, set to “yes": announce-position = yes Each member of this call queue is listed on a separate line in the form technology/dial string; “member” means a normal member of a queue. A Priority Queue (Queue Weighting) is needed to add people to a queue at a higher priority than that given to other callers. Perhaps the caller has already spent time waiting in a queue, and an ASL agent has taken some information but realized the caller needed to be transferred to another queue. In this case, to minimize the caller’s overall wait time, it is desirable to transfer the call to a priority queue that has a higher weight (and thus a higher preference), so it will be answered quickly. An optional penalty may be specified after a comma, such that entries with higher penalties are considered last. An optional member name may also be specified after a second comma, which is used in log messages as a “friendly name”. Multiple interfaces may share a single member name. An optional state interface may be specified after a third comma. The sample configuration section name is: [StandardQueue](!)(general) [VideoQ_GenQuest_1](StandardQueue) [VideoQ_Complaint_1](StandardQueue) 2.4.5 Filename: manager.conf This is a reference to the Asterisk Manager Interface (AMI), and provides third party application call management support and PBX event supervision. Use the "manager show commands" at the CLI to list available manager commands and their authorization levels. Note that you should not enable the AMI on a public IP address. If needed, block this TCP port with iptables (or another FW software) and reach it with IPsec, SSH, or SSL vpn tunnel. To make the manager interface available over http/https, set the Asterisk http server to enabled in http.conf: "enabled"=yes "webenabled"=yes. 2.4.6 Filename: extensions.conf The Asterisk dial plan includes statements to allow a developer to split up the functionality into smaller sections, and then have Asterisk search multiple contexts for a dialed extension. Most commonly, this functionality is used to provide security boundaries between different classes of callers. It is important to remember that when calls come into the Asterisk dial plan, they are directed to a particular context by the channel driver. Asterisk then begins looking for the dialed For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 21 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights extension in the context specified by the channel driver. By using include statements, other contexts in the search for the dialed extension are included.12 include => record_studio include => Company1_QueueLoginLogout Set the call workflow to Company 1, edit the proxy numbers and provide an ENUM lookup: exten => _17034369338,n,Set(sipuri=${ENUMLOOKUP(${CALLERID(num)},,,,itrs.us)}) exten => _17034369338,n,GotoIf($["${sipuri}" = "" ]?VoiceQ_GenQuest_1,start,1:VideoQ_GenQuest_1,start,1) exten => _17034369339,n,AGI(queue_feedback.agi) Set the play_key_video: exten => num1,1,Playback(number_1-recording0) exten => num1,n,Goto(company1_video_caller_query,start,100) Set the IVR and determination or proper Video Q: [company1_video_caller_query] exten => start,1,(start) exten => start,n,Verbose(2,${CALLERID(num)} entering the Company1 skill query for proper queue.) exten => start,n,Wait(3) exten => start,n,Playback(quiet_1sec) exten => start,20,Playback(welcome-recording1) exten => start,21,Playback(4_GeneralQuestions-recording1&5_Complaints- recording0&9_to_Repeat_menu-recording0) Note: there is a separate section that explains the video sources and the video playback exten => start,n,SendImage(/var/lib/asterisk/images/asterisk-intro) Echo the key press back to caller: exten => start,n,GotoIf($["${digito}" = "0" ]?play_key_for_video,num10,1) Set the Company1 Q details for VIDEO Queue -1: [VideoQ_GenQuest_1] exten => start,1,Verbose(2,${CALLERID(num)} entering the VIDEO queue) exten => start,n,Set(qinfo=${QUEUE_VARIABLES(VideoQ_GenQuest_1)}) ; get the QUEUE information. returns 0 f successful exten => start,n,Set(CALLERID(num)=${CALLERID(num):0:40}) ; to cover for a bug that only allowed for 40 bytes exten => start,n,Set(CALLERID(name)=${CALLERID(name):0:40}) exten => start,n,Set(ACTUALTO=sip:${CALLERID(num)}) exten => start,n,Set(ACTUALFROM=sip:${EXTEN}) 12 https://wiki.asterisk.org/wiki/display/AST/Include+Statements For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 22 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights exten => start,n,Macro(sendIMmacro,"You are in the General Questions (video) Queue. There are $[${QUEUECALLS}+1] calls ahead of you. The average wait is about ${QUEUEHOLDTIME} minutes",${ACTUALTO},${ACTUALFROM}) Load up the variables that will be accessed from the queue app by the macro that is passed: exten => start,n,Set(_MYARG1="You are now connected to an (video) agent who can handle your questions. Thank you.") Execute the queue and pass the macro: exten => start,n,Queue(VideoQ_GenQuest_1,t,,,,,sendIM_Q_macro,video-gosub) Establish VIDEO Queue -2: [VideoQ_Complaint_1] exten => start,1,Verbose(2,${CALLERID(num)} entering the VIDEO queue) exten => start,n,Set(qinfo=${QUEUE_VARIABLES(VideoQ_GenQuest_1)}) ; get the QUEUE information. returns 0 f successful exten => start,n,Macro(sendIMmacro,"You are in the Complaints (video) Queue. There are $[${QUEUECALLS}+1] calls ahead of you. The average wait is about ${QUEUEHOLDTIME} minutes",${ACTUALTO},${ACTUALFROM}) Define the subroutines that are passed to the queue application calls. GoSub allows you to execute a specific block (context or section) of dialplan as well as pass and return information via arguments to/from the scope of the block. Whereas Macro has issues with nesting, GoSub does not and GoSub should be used wherever you would have used a Macro. [video-gosub] exten => s,1,Verbose("Here we are in a subroutine GeneralQ! Playback audio and video") exten => s,n,Answer() exten => s,n,Wait(3) exten => s,n,Playback(customer_selected_GeneralQ-recording1) exten => s,n,Return() Set the Asterisk command AddQueueMember Synopsis: Dynamically adds queue members Options: queuename - The name of the queue to add a member to interface - The interface to add to the queue, if not specified, uses the current interface penalty - Integer greater than or equal to 0, available members with lower penalties will get calls first Establish Company1 agent registration: [Company1_QueueLoginLogout] exten => *10,1,Verbose(2,Logging in skill-1 VIDEO General queue member) exten => *10,n,Set(MemberChannel=${CHANNEL(channeltype)}/${CALLERID(num)}) exten => *10,n,AddQueueMember(VideoQ_GenQuest_1,${MemberChannel}) exten => *10,n,Wait(2) exten => *10,n,Playback(quiet_1sec) For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 23 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights exten => *10,n,Playback(your_are_the_rep_in_general-recording0) ;,skip exten => *10,n,Hangup() Define the Demonstration with a provider assigned number. These are the numbers that a person will call from an endpoint device to a CSR desktop: [incoming_from_provider] include => VideoQ_GenQuest_1 exten => _7035705868,1,Answer() exten => _7035705868,n,Goto(company1_video_caller_query,start,2) include => VideoQ_company2 TEST the IVR Q skill-based: exten => _7035705174,n,Goto(company1_video_caller_query,start,2) 2.4.7 Filename: sip.conf It is useful to visualize the relationship between the channel configuration files (sip.conf) and the dial plan (extensions.conf). The dial plan is the heart of an Asterisk system: it controls how call logic is applied to any connection from any channel. Both the relevant channel configuration file and the extensions.conf file play a role in most calls routed through the system. When a call comes into Asterisk, the identity of the incoming call is matched in the channel configuration file for the protocol in use (e.g., sip.conf). The channel configuration file also handles authentication and defines where that channel will enter the dial plan. Once Asterisk has determined how to handle the channel, it will pass call control to the correct context in the dial plan. The context parameter in the channel configuration file tells the channel where it will enter the dial plan (which contains all the information about how to handle and route the call).13 ACD demo- support the SIP trunk to our SIP proxy server: transport=tcp,udp ; Set the default transports. The order determines the primary default transport. srvlookup=yes ; Enable DNS SRV lookups on outbound calls localnet=172.31.16.0/255.255.240.0 ; RFC 1918 addresses externaddr=54.86.14.195 ; use this address. nat=force_rport CODECs represent mathematical algorithms for encoding (compression) and decoding (decompression) media streams. Asterisk uses CODEC modules to both send and receive media (audio and video). Asterisk also uses CODEC modules to convert (or transcode) media streams between different formats. 13 http://www.asteriskdocs.org/en/3rd_Edition/asterisk-book-html-chunk/DeviceConfig_id216341.html For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 24 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights Asterisk supports video telephony in the core infrastructure. Internally, it’s one audio stream and one video stream in the same call. Some channel drivers and applications have video support, but not all. Asterisk supports the following video codecs and file formats. Establish a template for the preferred codecs: [my-codecs](!) ; disallow=all allow=ilbc allow=g729 allow=gsm allow=g723 allow=ulaw Establish one for ulaw-only: [ulaw-phone](!) disallow=all allow=ulaw Establish Company 1 assignments: [company1_phone](!) type=peer transport=udp secret=moie host=dynamic ; This device needs to register directmedia=no ; Typically set to NO if behind NAT allow=all allow=ulaw allow=h263 allow=h263p allow=vp8 allow=h264 registertrying=yes ; Send a 100 Trying when the device registers. context=company1 callcounter = yes ; Enable call counters on devices. This can be set per qualify=yes busydetect=yes videosupport=yes ; Turn on support for SIP video. You need to turn this dtmfmode=rfc2833 For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 25 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights Define the following support for instant messaging: accept_outofcall_message=yes outofcall_message_context=IM auth_message_requests=yes [7032655700](company1_phone) regexten=7032655700 ; When they register, create extension 1234 callerid=<7032655700> [7032655701](company1_phone) regexten=7032655701 ; When they register, create extension 1234 callerid=<7032655701> Establish a TEST path from provider number: [provider_test_phone_tcp](!) type=friend transport=tcp directmedia=no host=208.94.16.194 nat=force_rport directmedia=no ; Typically set to NO if behind NAT disallow=all allow=ulaw allow=h263 allow=h264 context=incoming_from_provider videosupport=yes ; Turn on support for SIP video. You need to turn this dtmfmode=rfc2833 accept_outofcall_message=yes outofcall_message_context=IM auth_message_requests=yes [7035705868](provider_test_phone_tcp) regexten=7035705868 ; When they register, create extension [7035705174](provider_test_phone_tcp) regexten=7035705174 ; When they register, create extension 2.4.8 Filename: [network:interfaces.d] eth0.cfg: Define a primary network interface so that Asterisk can connect and communicate through the operating system: For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 26 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights auto eth0 iface eth0 inet dhcp dns-nameservers 156.154.59.227 dns-nameservers 172.31.0.2 dns-search ec2.internal 2.4.9 SIP Proxy Files Define SIP Proxy host specific configuration files and initialization parameters to start and stop services: # Kamailio startup options # # Set to yes to enable kamailio, once configured properly. RUN_KAMAILIO=yes Review user and group assignments to meet security requirements: # User to run as #USER=kamailio # Group to run as #GROUP=kamailio Updates to the Asterisk SIP.CONF file: [Kam-ACD-sip-proxy] type=friend host=52.2.224.220 fromdomain=54.86.14.195 port=5060 transport=udp videosupport=yes disallow=all allow=ulaw allow=h263 allow=h264 context=company1 directmedia=yes insecure=port,invite dtmfmode=rfc2833 nat=force_rport qualify=yes For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 27 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights Maintain the ICE and STUN to address issues with NAT: ;icesupport=true ;stunaddr=stun.l.google.com:19302 2.5 Test Planning The following are the key objectives and guiding principles of the Test Planning Phase: ? Leverage existing facilities resources for the Proof of Concept application projects ? Initiate infrastructure enhancements, including virtualization ? Initiate test data preparation activities ? Deploy core service management processes and enable support tools ? Design standard service offerings to customers ? Establish a presence in a Vendor/Infrastructure as a Service (IaaS) Cloud Computing Facility as a short-term measure ? Support for the development of the Acquisition Strategy to support IaaS To achieve these objectives, significant actionable items have been identified and are presented in the following subsections. These actionable items are organized by technical area referenced in Appendix I, Sample Test Matrix. 2.5.1 Test Planning: Actionable Items The test plan action items can provide baseline activities for the development of a test project plan. This test plan can guide the approach and focus on specific test areas and issues. The actionable items can also be used to connect specific areas of the test scope and objectives to improve “the testability of the item under test”.14 The detailed subsections comprise the actionable items for guiding the IPT and are referenced in Appendix H, Test Strategy. 2.6 Release Plan The project team will draft a release plan with the following content: 1. Project Context a. Compressed Schedule b. Integration Testing done in Production Environment c. No real “production” implementation 2. Status of Operational Readiness Review (ORR) artifacts 14 http://istqbexamcertification.com/what-is-the-purpose-and-importance-of-test-plans/ For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 28 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights a. Operations Manual b. Test Summary Report c. System Accreditation Form d. Companion Guide e. Version Description Document f. Implementation Plan 3. Project Timeline a. Snapshot of major milestones b. Impact of current timeline on various activities – Stress Testing, Integration Testing, etc. 4. Status of Integration Testing a. What has been tested and results (high level) b. What has not been tested (high level) c. Review of open Change Requests – identify showstoppers and anticipated time to resolve 5. Status of remaining development activities and system testing 6. Help Desk Readiness 7. Operations Readiness a. Stability of system (components staying up?) b. Availability of monitoring tools and trained resources c. Operations and Maintenance (O&M) documentation status d. Escalation procedures defined (near-term) e. Stress Test results/decisions 8. Security Readiness a. Administrative Safeguards b. Physical Safeguards c. Technical Safeguards 9. Outstanding Risks and Concerns a. Finishing integration and stress testing b. How to elevate changes to production without impact to production users c. Lack of proactive monitoring tools and automated responses 10. Next Steps For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 29 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights 2.7 Shared Services The shared services approach to an auto-call routing workflow is to provide the right services to the right subject matter expert at the right time. This approach supports ASL-qualified subject matter experts to support multiple domains across agencies, companies, and organizations from geographically diverse locations. Customers can leverage this approach to optimize resources and drive better end-user experience (e.g., equivalency for deaf and hard of hearing users, shorten wait times during periods of heavy call loads). 2.7.1 Develop the Near-term Tactical Plans This activity develops the near-term, tactical plans for managing the impact of the development and test infrastructure and the call center facilities on the entire computing environment. The plans should include current, strategic, transitional, business impacts, financial, and fund source requirements. These requirements may include: ? Hardware Plan ? Software Plan ? Business Applications Plan ? Facilities Plan ? Network Connectivity and Traffic Plan ? Human Resource Allocation Plan ? Communications Plan ? Security Plan ? Business Requirements/Impact Analysis Plan ? Transition/Migration Plan ? Performance Management and Auditing Plan ? Business Continuity Plan ? Data Management/Data Quality Plan To manage the risk for this activity, the effort should coordinate the business leadership and the participation for informed IT planning to reduce the chance for the interruption of services. 2.7.2 Task-Specific Prioritization and Baseline Metrics The first activity should develop a detailed task-specific plan for the development and test infrastructure and the call center facilities. The plan should include sections that delineate roles to: For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 30 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights ? Develop program policy, strategic, and tactical plans ? Define performance expectations and performance measures, and manage vendor contractors ? Define project/communication plans to manage infrastructure and call center facilities transition/cost, the associated vendor contractors, and the business partners The prioritization plan should include a methodology to account for the performance measures and scorecards. The results should become part of a Service Delivery Portfolio to include: ? A ”lean” Program Management Office (PMO) for the transition period ? A problem reporting process and trouble ticket system ? Operational procedures ? A Communications Plan ? Monitoring tools ? A cross-reference to applicable Service Delivery Targets ? Network standards and topology, including call center connectivity, Network Operation Center (NOC) administration and remote management ? Provisioning interim (temporary) services ? Equipment redirection and retirement plans ? A service continuity and contingency plan To manage the risk for this activity, the effort should account for the full and adequate understanding of the complexities and interdependencies of provisioning equipment for virtualization and consolidation of development and test infrastructures. The second activity should consider that the decision-makers are well informed on agency impacts and service delivery (e.g., network connectivity limitations or delays). A governance structure should be leveraged or established to ensure key decisions on infrastructure, architecture, networking, and strategic goals for implementation, culture, and funding. The expected outcome for this activity is a task-specific prioritization plan for the development and test infrastructures and call center facilities. To manage the risk for this activity, the effort should provide a continuous communication loop to the key decision-makers to ensure reporting, assessment, and mitigation of risk. Decision- makers and the governance structure should be kept informed of the risks, impact, and exposure if one or more sections of the contingency plan are executed. The third activity is to draft a business continuity plan. A business continuity plan is vital because the ACR proof of concept introduces new workflow and dependencies on ASL-qualified subject matter experts to handle the direct video calls. The expected outcome for this activity is a business continuity plan to support the development and test infrastructures and call center facilities. For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 31 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights The risk to an agency, company, or organization is a gap in ASL-qualified SMEs during an incident or event that causes a disruption in service. For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 32 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights 3. Proposed Next Steps This document provides an approach and guide to replicate the ACR configuration. Its guidance helps the engineering team tailor the resultant configuration to the customer’s/agency’s requirements and needs (i.e., the outcome results in more than a replication of the MITRE ACR POC). MITRE recommends the following actions to implement the proof of concept with other agencies, organizations, and companies: ? Require change control for development and test environment configurations ? Develop a prioritized list of tool changes that would integrate capabilities, reduce risk, and improve team productivity ? Develop regression testing and mature manual test processes ? Formalize a Change Control Board (CCB) structure and operation. Implement a Change Advisory Board (CAB) to analyze each proposed change and provide extensive information about the background, potential problems, and possible solutions with pros and cons. ? Define and document the Change Management Process to generate accurate and complete information about change dependencies ? Manage and track Change Requests (CR) to ensure that the impact of a proposed change is clearly understood across other projects that are related to the changes requested (such as infrastructure upgrades to current call center operations) ? Conduct Impact Analysis to place greater emphasis on the impact of proposed changes and ensure the interdependencies are clearly listed for review ? Update or draft a Concept of Operations to introduce the POC to production services and review interdependencies and impact to schedules ? Modify release cycle and documentation. Assign appropriate personnel to implement a release management plan and template for all releases. ? Create a document repository and designate ownership. Develop a SharePoint site to serve as the template repository. ? Create a communications and shakeout plan. Formalize the release process with a standard deployment and shakeout plan. ? Perform root cause analysis. Develop a methodology for root cause analysis and assist the testing team with root cause analysis after a release. ? Create a schedule of regular meetings, working sessions, and facilitated technical exchanges to define, update, and document user needs and system requirements For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 33 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights ? Capture design, development, and testing lessons learned from each release ? Develop a test and integration process to streamline, measure, and compare for optimized user work processes ? Develop an interim process to assess, compare, and document the end-user workflow and end-user input with regard to new requirements For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 34 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights Appendix A. IETF RFC The following Requests for Comments (RFC) are associated with Session Initiation Protocol (SIP) but are not listed in this Appendix: 3261, 3265, 3853, 4320, 4916, 5393, 5621, 5626, 5630, 5922, 5954, 6026, 6141, 6665, 6878, 7462, 7463. RFC 3428: Session Initiation Protocol (SIP) Extension for Instant Messaging https://tools.ietf.org/html/rfc3428 RFC 2833: RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals https://tools.ietf.org/html/rfc2833 RFC 2543: SIP: Session Initiation Protocol https://tools.ietf.org/html/rfc2543 RFC 3550: RTP: A Transport Protocol for Real-Time Applications https://tools.ietf.org/html/rfc3550 RFC 3605: Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP) https://tools.ietf.org/html/rfc3605 RFC 3986: Uniform Resource Identifier (URI): Generic Syntax https://tools.ietf.org/html/rfc3986 RFC 4904: Representing Trunk Groups in TEL/SIP Uniform Resource Identifiers (URIs) https://tools.ietf.org/html/rfc4904 RFC 4961: Symmetric RTP/RTP Control Protocol (RTCP) https://tools.ietf.org/html/rfc4961 RFC 5245: Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols https://tools.ietf.org/html/rfc5245 RFC 5527: Combined User and Infrastructure ENUM in the e164.arpa Tree https://tools.ietf.org/html/rfc5527 RFC 5630: The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP) https://tools.ietf.org/html/rfc5630 RFC 6116: The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) https://tools.ietf.org/html/rfc6116 RFC 3551: RTP Profile for Audio and Video Conferences with Minimal Control For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 35 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights Appendix B. Extensions File ; extensions.conf - the Asterisk dial plan ; ; Static extension configuration file, used by ; the pbx_config module. This is where you configure all your ; inbound and outbound calls in Asterisk. ; ; This configuration file is reloaded ; - With the "dialplan reload" command in the CLI ; - With the "reload" command (that reloads everything) in the CLI ; ; The "General" category is for certain variables. ; [general] ; ; If static is set to no, or omitted, then the pbx_config will rewrite ; this file when extensions are modified. Remember that all comments ; made in the file will be lost when that happens. ; ; XXX Not yet implemented XXX ; static=yes ; ; if static=yes and writeprotect=no, you can save dial plan by ; CLI command "dial plan save" too ; writeprotect=yes ;was no ; ; If autofallthrough is set, then if an extension runs out of ; things to do, it will terminate the call with BUSY, CONGESTION ; or HANGUP depending on Asterisk's best guess. This is the default. ; ; If autofallthrough is not set, then if an extension runs out of ; things to do, Asterisk will wait for a new extension to be dialed ; (this is the original behavior of Asterisk 1.0 and earlier). ; ;autofallthrough=no ; ; ; ; If extenpatternmatchnew is set (true, yes, etc), then a new algorithm that uses ; a Trie to find the best matching pattern is used. In dialplans ; with more than about 20-40 extensions in a single context, this ; new algorithm can provide a noticeable speedup. ; With 50 extensions, the speedup is 1.32x For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 36 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights ; with 88 extensions, the speedup is 2.23x ; with 138 extensions, the speedup is 3.44x ; with 238 extensions, the speedup is 5.8x ; with 438 extensions, the speedup is 10.4x ; With 1000 extensions, the speedup is ~25x ; with 10,000 extensions, the speedup is 374x ; Basically, the new algorithm provides a flat response ; time, no matter the number of extensions. ; ; By default, the old pattern matcher is used. ; ; ****This is a new feature! ********************* ; The new pattern matcher is for the brave, the bold, and ; the desperate. If you have large dialplans (more than about 50 extensions ; in a context), and/or high call volume, you might consider setting ; this value to "yes" !! ; Please, if you try this out, and are forced to return to the ; old pattern matcher, please report your reasons in a bug report ; on https://issues.asterisk.org. We have made good progress in providing ; something compatible with the old matcher; help us finish the job! ; ; This value can be switched at runtime using the cli command "dial plan set extenpatternmatchnew true" ; or "dial plan set extenpatternmatchnew false", so you can experiment to your hearts content. ; ;extenpatternmatchnew=no ; ; If clearglobalvars is set, global variables will be cleared ; and reparsed on a dialplan reload, or Asterisk reload. ; ; If clearglobalvars is not set, then global variables will persist ; through reloads, and even if deleted from the extensions.conf or ; one of its included files, will remain set to the previous value. ; ; NOTE: A complication sets in, if you put your global variables into ; the AEL file, instead of the extensions.conf file. With clearglobalvars ; set, a "reload" will often leave the globals vars cleared, because it ; is not unusual to have extensions.conf (which will have no globals) ; load after the extensions.ael file (where the global vars are stored). ; So, with "reload" in this particular situation, first the AEL file will ; clear and then set all the global vars, then, later, when the extensions.conf ; file is loaded, the global vars are all cleared, and then not set, because ; they are not stored in the extensions.conf file. ; clearglobalvars=no ; ; User context is where entries from users.conf are registered. The ; default value is 'default' For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 37 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights ; ;userscontext=default ; ; You can include other config files, use the #include command ; (without the ';'). Note that this is different from the "include" command ; that includes contexts within other contexts. The #include command works ; in all asterisk configuration files. ;#include "filename.conf" ;#include ;#include filename.conf ; ; You can execute a program or script that produces config files, and they ; will be inserted where you insert the #exec command. The #exec command ; works on all asterisk configuration files. However, you will need to ; activate them within asterisk.conf with the "execincludes" option. They ; are otherwise considered a security risk. ;#exec /opt/bin/build-extra-contexts.sh ;#exec /opt/bin/build-extra-contexts.sh --foo="bar" ;#exec ;#exec "/opt/bin/build-extra-contexts.sh --foo=\"bar\"" ; ; The "Globals" category contains global variables that can be referenced ; in the dialplan with the GLOBAL dialplan function: ; ${GLOBAL(VARIABLE)} ; ${${GLOBAL(VARIABLE)}} or ${text${GLOBAL(VARIABLE)}} or any hybrid ; Unix/Linux environmental variables can be reached with the ENV dial plan ; function: ${ENV(VARIABLE)} ; [globals] CONSOLE=Console/dsp ; Console interface for demo ;CONSOLE=DAHDI/1 ;CONSOLE=Phone/phone0 IAXINFO=guest ; IAXtel username/password ;IAXINFO=myuser:mypass TRUNK=DAHDI/G2 ; Trunk interface ; ; Note the 'G2' in the TRUNK variable above. It specifies which group (defined ; in chan_dahdi.conf) to dial, i.e. group 2, and how to choose a channel to use ; in the specified group. The four possible options are: ; ; g: select the lowest-numbered non-busy DAHDI channel ; (aka. ascending sequential hunt group). ; G: select the highest-numbered non-busy DAHDI channel ; (aka. descending sequential hunt group). ; r: use a round-robin search, starting at the next highest channel than last ; time (aka. ascending rotary hunt group). For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 38 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights ; R: use a round-robin search, starting at the next lowest channel than last ; time (aka. descending rotary hunt group). ; TRUNKMSD=1 ; MSD digits to strip (usually 1 or 0) ;TRUNK=IAX2/user:pass@provider ;FREENUMDOMAIN=mydomain.com ; domain to send on outbound ; freenum calls (uses outbound-freenum ; context) ; ; WARNING WARNING WARNING WARNING ; If you load any other extension configuration engine, such as pbx_ael.so, ; your global variables may be overridden by that file. Please take care to ; use only one location to set global variables, and you will likely save ; yourself a ton of grief. ; WARNING WARNING WARNING WARNING ; ; Any category other than "General" and "Globals" represent ; extension contexts, which are collections of extensions. ; ; Extension names may be numbers, letters, or combinations ; thereof. If an extension name is prefixed by a '_' ; character, it is interpreted as a pattern rather than a ; literal. In patterns, some characters have special meanings: ; ; X - any digit from 0-9 ; Z - any digit from 1-9 ; N - any digit from 2-9 ; [1235-9] - any digit in the brackets (in this example, 1,2,3,5,6,7,8,9) ; . - wildcard, matches anything remaining (e.g. _9011. matches ; anything starting with 9011 excluding 9011 itself) ; ! - wildcard, causes the matching process to complete as soon as ; it can unambiguously determine that no other matches are possible ; ; For example, the extension _NXXXXXX would match normal 7 digit dialings, ; while _1NXXNXXXXXX would represent an area code plus phone number ; preceded by a one. ; ; Each step of an extension is ordered by priority, which must always start ; with 1 to be considered a valid extension. The priority "next" or "n" means ; the previous priority plus one, regardless of whether the previous priority ; was associated with the current extension or not. The priority "same" or "s" ; means the same as the previously specified priority, again regardless of ; whether the previous entry was for the same extension. Priorities may be ; immediately followed by a plus sign and another integer to add that amount ; (most useful with 's' or 'n'). Priorities may then also have an alias, or For Pubic Release – In Accordance with Data Rights Final Draft Federal Communications Commission Auto-Routing Proof-of-Concept 39 Version 0.5 [Cookbook Section Only] September 29, 2015 For Pubic Release – In Accordance with Data Rights ; label, in parentheses after their name which can be used in goto situations. ; ; Contexts contain several lines, one for each step of each extension. One may ; include another context in the current one as well, optionally with a date ; and time. Included contexts are included in the order they are listed. ; Switches may also be included within a context. The order of matching within ; a context is always exact extensions, pattern match extensions, includes, and ; switches. Includes are always processed depth-first. So for example, if you ; would like a switch "A" to match before context "B", simply put switch "A" in ; an included context "C", where "C" is included in your original context ; before "B". ; ;[context] ;exten => someexten,{priority|label{+|-}offset}[(alias)],application(arg1,arg2,...) ; ; Timing list for includes is ; ;