ESBD_File_341047_Attachment A - Technical Requirements.pdf

RFP 23-204 ATTACHMENT A

TECHNICAL CHECKLIST

This Technical Checklist attachment is comprised of a series of tables. Each table contains specific requirements, applicable to a particular aspect of the associated solution, as indicated by the heading immediately preceding each table. The Respondent is required to clearly mark one (and only one) of the three right-most columns (Complies, Does Not Comply, Partially Complies) for each requirement, as follows:

• Complies – The proposed solution does, today (or will at the time of contract award), fully satisfy the requirement.

• Does Not Comply – The proposed solution does not, today (nor will it, at the time of contract award), substantially satisfy the requirement.

• Partially Complies – The proposed solution does, today (or will, at the time of contract award), substantially (though incompletely or, perhaps, in an alternate way) satisfy the requirement.

Following each table is a space for the Respondent to add additional information supporting, or elaborating upon, the compliance declaration for the requirements in the table. While there are no limitations on the extent of this additional information, such information should be focused on the specific requirements being addressed. Concise details and brevity are encouraged. If no additional information is being provided for a particular table of requirements, the Respondent should include a statement to that effect (e.g., “N/A,” “None,” “No details provided,” etc.) to confirm that the lack of supporting information is deliberate and not an oversight.

By checking this box, you acknowledge you have read and understand.

1.1 CHE Network

CHE Network is not included in the TriCOG purchase; however, requirements are included here for other entities that may purchase off this contract vehicle. Pricing for CHE Network will be negotiated at the time of purchase.

Requirements:

C o m p lie s

D o e s N o t

C o m p ly

P a rt ia lly

C m p

1. The solution shall align with NENA STA-010.3d-2021, NENA i3

Standard for Next Generation 9-1-1, (or its successor document, when ratified).

2. The solution shall have diverse entrance facilities for aggregation sites (if different than core sites), core sites, and hosted call-handling facilities.

RFP 23-204 Attachment A

Technical Checklist

Requirements:

o m p e s N o t

C o m rt m p

3. The primary (of at least two) connection into each facility shall be terrestrial (copper or optical circuit); secondary connection(s) may be wireless (e.g., long-term evolution [LTE], microwave, carrier-diverse fiber, etc.).

4. The solution shall offer network connectivity options to support call and data delivery to existing 9-1-1 authority or agency mobile command and control assets.

5. The solution shall use open standards.

6. The solution shall use customer-provided SIP uniform resource identifiers (URIs) for all calls and transfers.

7. The solution shall support and enforce quality of service (QoS) marking using Differentiated Service Code Point (DSCP).

8. The solution shall provide network traffic convergence of less than

54 milliseconds (ms).

9. The solution shall maintain a Mean Opinion Score (MOS) of 4.0.

10. The solution shall scale to support growth by 50% without replacement of any critical hardware component.

11. Failure of any single instance of a hardware or software element, or physical connection shall not impact overall solution performance.

12. All network-connected elements shall support at least two redundant network interfaces with automatic failover between them.

13. All powered devices shall include a minimum of two redundant power supplies (each shall be able to power the device alone) that would be connected to separate circuits OR be connected to a power-transfer device that allows a single power supply to be connected to two isolated power sources (i.e., circuits) with automatic, uninterrupted failover, in the event the primary circuit fails.

o m p e s N o t

C o m rt m p

14. The Respondent proposed solution(s) will meet the requirements in

Appendix B.2 – IP Network Measurement and Reporting

Requirements of this solicitation package.

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your solution addresses these requirements. Add additional lines as needed.

1.2 Security

C o m p e s N o t

C o m rt m p

1. The Respondent shall describe how its security in-depth approach embodies the best practices outlined in the latest version of NENA

75-001, NENA Security for Next-Generation 9-1-1 Standard (NG-

SEC), and whether security is treated as an integral function of each solution element from the initial design stage or if security is treated holistically as a separate overarching functional element of the solution.

2. The Respondent shall include an application security plan.

3. The solution shall utilize encryption in all communications across the CHE network.

4. The Respondent shall ensure that all components and/or functional elements providing call-handling and/or NG9-1-1 services, under a contract from this solicitation, carry credentials traceable to the national PSAP Credentialing Agency (PCA).

o m p e s N o t

C o m rt m p

5. The Respondent shall have a credentialing plan/process for external entities with staff requiring access to any elements or services provided as a part of any contract resulting from this procurement.

6. The Respondent shall perform proactive analysis of the system for vulnerabilities including independent security audits of the solution.

7. The Respondent shall have a defined continuity of operations

(COOP) plan as well as a disaster recovery (DR) plan and make those plans available for review at customer’s request.

8. The solutions shall require multifactor authentication for any access to externally accessible portals, user interfaces (UIs), etc. (Policy

Routing Function [PRF] portal, reporting portal, system dashboards, etc.).

9. The Respondent shall describe security software update policy, frequency, and procedures.

10. The Respondent shall describe plan/approach for adopting evolving security best practices.

11. The Respondent shall complete the NG-SEC Audit Checklist, and submit for approval, as described in NENA 75-502, Next Generation

9-1-1 Security (NG-SEC) Audit Checklist.

For this procurement, the Respondent must comply with all requirements designated as Required “R” in column labeled

“Compliance Finding” in the Audit Checklist.

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your https://www.nena.org/resource/resmgr/Standards/NENA_75-502.1_NG-SEC_Audit_C.pdf

1.3 Documentation

The Respondent shall provide the documentation that follows for its proposed ESInet, NGCS, or both, as applicable.

Requirements:

C o m p e s N o t

C o m rt m p

1. The Respondent shall provide its proposed system design

(transitional and end state), including bandwidth requirements, power requirements, and network diagrams.

2. The Respondent shall provide as-built documentation depicting equipment diversity prior to acceptance testing.

3. The Respondent shall provide network interface specifications for interoperating with CHE.

4. The Respondent shall provide as-built solution design documentation to include configured parameters and policy-routing flow-downs (planned design and actual implemented design).

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

1.4 Monitoring and Alarming

C o m p e s N o t

C o m rt m p

1. The Respondent shall provide automated system monitoring and alarming in real- or near-real-time.

2. The Respondent shall provide event logging and reporting in real-or near-real-time.

o m p e s N o t

C o m rt m p

3. The Respondent shall provide ability to replicate customer-selected alerts to a third-party monitoring/reporting system.

4. The Respondent shall provide user-definable notification levels and recipients with text and email delivery options.

5. The Respondent shall provide an executive dashboard with (near) real-time updates of tickets and system status.

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

1.5 Network Operations Center/Security Operations Center

C o m p e s N o t

C o m rt m p

1. The Respondent shall provide 24 x 7 x 365 staffed network operations center (NOC)/security operations center (SOC) with hot

(preferred) or warm backup.

2. The Respondent shall provide the ability for users to submit, track, and modify tickets by phone, email, and direct information technology (IT) service management (ITSM) user access for incidents, problems, and changes.

3. The Respondent shall provide outward notifications and updates of customer tickets through phone, email, and text.

4. The Respondent shall provide fully documented escalation procedures with contact information for all primary and secondary responsible personnel at all levels of escalation.

o m p e s N o t

C o m rt m p

5. The Respondent shall provide reason for outage (RFO) reports and regulatory compliance according to Federal Communications

Commission (FCC) standards.

6. Preliminary RFO reports are due to the customer within five business days of the initial report of an issue; final root-cause analysis within 30-calendar days of root cause determination.

7. The Respondent shall provide a media contact for any outage or service failure. The media contact information shall be updated quarterly by the Respondent.

8. The Respondent shall provide a government/regulatory contact for any outage or service failure. The government/regulatory contact shall be updated quarterly by the Respondent.

9. The Respondent shall provide a service management contact for any outage or service failure.

10. The Respondent shall provide its documented and maintained

COOP plan.

11. The Respondent shall provide access to technical and executive staff for escalations.

12. The Respondent shall provide NOC/SOC staff trained or experienced with 9-1-1 issues with regular refresher/update training plan.

13. The Respondent shall provide the ability to access and troubleshoot, diagnose, and repair network remotely.

14. The Respondent shall provide the ability and commitment to support the troubleshooting of all service affecting issues, even when it is determined that the root cause of the issue is outside the scope of the Respondent’s solution or service. (e.g., provide call traces and log analysis to assist in troubleshooting a third-party

CHE location display issue).

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2 CALL-HANDLING REQUIREMENTS

Adopted Standards: The Respondent shall describe the proposal’s compliance with the adopted standards listed in this solicitation package, Section 4, Industry Standards.

By checking this box, you acknowledge you have read and understand.

2.1 Common Call-Handling Requirements – Architecture

C o m p e s N o t

C o m rt m p

1. To simplify the procurement process and minimize the number of

CHE options to be supported across the region, the customer requires any Respondent providing a proposal in response to the

CHE portion of this RFP to support the deployment of its solution as host–remote. Other deployment models will not be considered.

To be clear, a proposal that is not a host–remote solution will not be considered.

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.2 Industry Standards Evolution

C o m p e s N o t

C o m rt m p

1. As industry standards evolve, the Respondent’s solution shall be upgraded to maintain conformance with the current version of established industry standards. The Respondent’s solution shall support new call-handling and security industry standards within 18 months of ratification of applicable industry standards.

Conformance requirements apply also to the supporting standards referenced within each standard.

2. As solution updates are made to maintain conformance, the solution shall not abandon services, features, or functionality in place at the time of the solution upgrade. The Respondent must divulge and justify any performance or feature changes prior to the upgrade and report them to the affected customer(s) for approval and further dissemination.

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.3 i3 Conformance

The Respondent’s solution shall be an i3-conformant call-handling system.

Requirements:

C o m p e s N o t

C o m rt m p

1. The solution shall conform to the latest published/ratified version of

NENA-STA-010.3d-2021, NENA i3 Standard for Next Generation

9-1-1.

2. The solution shall interface with any NENA i3-conformant NGCS and ESInet.

o m p e s N o t

C o m rt m p

3. The Respondent shall provide the number of its operational call-handling installations that utilize Presence Information Data Format

Location Object (PIDF-LO), HTTP1-enabled location delivery

(HELD), Location-to-Service Translation (LoST), Additional Data

Repository (ADR) queries, and other i3 protocols.

4. The solution shall function in a legacy 9-1-1 network environment during the transition to NGCS and ESInet stages.

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.4 Call-Handling Technical Support

C o m p e s N o t

C o m rt m p

1. The Respondent shall provide a 24 x 7 NOC/SOC for reporting and escalating software and hardware issues beyond Tier 2.

2. The Respondent shall provide a redundant/secondary/backup

NOC/SOC or equivalent support capabilities and capacity in the event the primary center is offline or otherwise unusable.

3. The Respondent shall provide a NOC/SOC COOP plan that provides for situations when NOC/SOC staff are unable to work onsite (such as the COVID-19 pandemic environment).

1 Hypertext Transfer Protocol

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.5 Solution Validation

C o m p e s N o t

C o m rt m p

1. At the discretion of the customer(s), the Respondent shall ensure independent third-party validation of all mandatory solution requirements and feature functionality prior to cutover of the site.

2. The solution shall provide transparency and access to all SIP messaging, call detail records (CDRs), key performance indicators

(KPIs) (e.g., MOS, delay, jitter, and packet loss at ingress and egress of delivering network), call logs, and any other data determined to be necessary in order to verify compliance with contractual obligations or to troubleshoot issues.

3. The Respondent shall provide documentation of completed results from acceptance testing.

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.6 Multi-Tenant Capability

The Respondent’s solution shall support partitioning of tenants’ (i.e., agencies’) call-handling resources.

o m p e s N o t

C o m rt m p

1. All customer PSAPs shall be able to create their own unique set of configurations (e.g., agent identifications [IDs], roles, permissions, and groups, screen layouts, speed-dial catalogs, management information system [MIS] reports, system status screen layouts, etc.) that are not accessible to any other PSAP configured in the solution.

2. Authorized customer administrative personnel shall have full visibility into the enterprise, including configuration control and reporting.

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.7 Integrated Text-to-9-1-1

The Respondent’s solution shall support an integrated short message service (SMS)-based text-to-9-1-1 solution via SIP/Message Session Relay Protocol (MSRP).

Requirements:

C o m p e s N o t

C o m rt m p

1. The Respondent shall explain how text calls are received, queued, answered, and tracked in the system.

2. The Respondent shall explain disposition of attached multimedia and how text calls are handled by the MIS.

3. The Respondent shall explain how text calls are transferred and shared, as well as any limitations.

o m p e s N o t

C o m rt m p

4. The Respondent shall provide examples of the applicable UIs (e.g., screenshots).

5. The Respondent shall provide the ability to text from 9-1-1.

6. The solution shall be able to accept SMS delivery via ESInet connection (i.e., not require a separate connection for SMS delivery).

7. The Respondent shall describe SMS foreign language translation capability.

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your solution addresses these requirements. Describe if your solution accepts SMS message from alarm companies. Add additional lines as needed.

2.8 Real-Time Text

The Respondent shall provide pricing for this functionality in the Options tab of the Pricing Matrix.

The Respondent’s solution shall support real-time text.

Requirements:

C o m p e s N o t

C o m rt m p

1. The Respondent shall describe plans for supporting real-time text-to-9-1-1 sessions as a part of its solution or explain its roadmap to offer this feature in the future.

2. If not currently developed, the Respondent shall provide details of when this capability will be included in the proposed solution as a no-charge upgrade/deliverable.

o m p e s N o t

C o m rt m p

3. The Respondent shall ensure that if a caller backspaces or deletes characters, it is captured in the call record detail and analytics.

4. The Respondent shall describe its capability to capture emojis as sent in the call record detail and analytics.

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.9 Artificial Intelligence and Machine Learning

The Respondent shall provide pricing for this functionality in the Options tab of the Pricing Matrix.

Requirements:

C o m p e s N o t

C o m rt m p

1. The Respondent shall describe the artificial intelligence

(AI)/machine learning (ML) capabilities of the proposed CHE system.

2. The Respondent shall describe plans to introduce/enhance AI/ML capabilities into the proposed CHE solution.

3. The Respondent shall describe opportunities to apply AI/ML technologies and techniques to the analysis of multimedia content delivered to the PSAP.

4. The Respondent shall describe opportunities for applying artificial intelligence (AI)/machine learning (ML) technologies and techniques for intelligent, dynamic, and automatic call overflow and rerouting.

5. The Respondent shall describe its ability to recognize telephony denial of service (TDoS)/distributed denial of service (DDoS) bad-actors and quarantine the unwanted traffic from the state’s PSAPs’ call queues.

6. The Respondent shall describe its ability for the customer to integrate third-party AI/ML application providers into the service.

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.10 User Profiles

C o m p e s N o t

C o m rt m p

1. The Respondent shall provide user profile settings, which are retained between logins, during upgrades, and between sessions

(i.e., logoff and return next day).

2. Profiles shall be stored within the call-handling system and be available from any workstation on the same call-handling system.

3. The solution shall be capable of establishing skills-based profiles.

4. Access to call-handling assets (e.g., trunks, lines, queues, speed dials, configurations, screen layouts, etc.) may be controlled by a user’s profile.

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.11

2.12 Redundancy, Reliability, Availability

The Respondent’s proposed solution shall satisfy the redundancy, availability, and diversity requirements that follow.

Requirements:

C o m p e s N o t

C o m rt m p

1. The solution shall automatically (i.e., without manual intervention) transfer or failover core processing functionality upon detection of a problem that impacts the system’s ability to meet the 99.999% service level requirement (SLR).

2. During such an event, call-handling capacity and performance shall not be degraded.

3. It shall be possible to manually switch core-processing functionality back to its normal operating state, as well as to have the system automatically recover and resync once the problem is corrected.

4. The Respondent shall provide a detailed description of how the solution achieves 99.999% availability.

5. Core-processing functionality may be distributed across two or more call-handling centers (CHCs) provided (at the tenant customer’s discretion) by either the Respondent or the customer(s) to provide automatic load balancing and failover functionality.

6. Each CHC shall have sufficient configured capacity to support

125% of busy-hour 9-1-1 call volume and call-mapping functionality for all PSAPs served by that call-handling system.

7. The solution shall support the use of laptops as fully functional call-handling workstations with virtual private network (VPN) capability to provide remote call-taking via any broadband network.

8. The Respondent shall describe the solution’s hot-seating capabilities (i.e., the ability for a telecommunicator from one PSAP or agency to login at a workstation at a different PSAP or agency, provided both PSAPs/agencies are co-tenants on the same system, and have their “home” assets [e.g., trunks, lines, queues, speed dial lists, screen layouts, map, etc.] available at the other PSAP).

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.13 Security

C o m p e s N o t

C o m rt m p

1. The solution shall comply with NENA 75-001, NENA Security for

Next-Generation 9-1-1 Standard (NG-SEC). The Respondent shall detail how its solution addresses the requirements of the following sections of the standard:

a. Section 6 – General Security.

b. Section 7 – Safeguarding Information Access.

c. Section 9 – Network and Remote Access Security Guidelines.

2. The Respondent shall describe its CHE security software update policy, frequency, and procedures (include frequency of antivirus updates).

3. The Respondent shall describe approach to allowing independent system security audits including any policy restrictions.

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.14 Long-term Availability

The Respondent shall commit to long-term availability.

Requirements:

C o m p e s N o t

C o m rt m p

1. The Respondent shall provide 12 months’ (minimum) advance written notification to the customer for any end-of-life (EOL) or end-of-support (EOS) component, with a plan for how the affected component(s) will be replaced without affecting service.

2. The proposed solution shall be supported by the manufacturer(s) for a minimum of five years (plus any optional contract extensions) from the date of full system acceptance by the customer(s).

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.15 CAD Interoperability

C o m p e s N o t

C o m rt m p

1. The solution shall support the CAD system interface as described in

NENA-STA-027.3-2018, NENA E9-1-1 PSAP Equipment

Standards.

2. The solution shall support both serial and IP-based connections.

3. The solution shall support a bi–directional interface with CAD systems.

4. The Respondent shall detail the process to import and export phone book data from the CHE into CAD and vice versa.

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.16 Location Information Server/Location Database

C o m p e s N o t

C o m rt m p

1. The solution should support interface(s) with the Location

Information Server (LIS) and Location Database (LDB) as defined in

NENA-STA-010.3d-2021, NENA i3 Standard for Next Generation

9-1-1, (or its successor document, once published).

2. The Respondent should describe how the proposed solution will address any transition period, during which both legacy automatic location identification (ALI) services and i3-compliant LDB/LIS services may need to be accessed by the Respondent’s call-handling solution.

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.17 PSAP Hardware

C o m p e s N o t

C o m rt m p

1. All PSAP hardware (e.g., monitors, keyboards, mice, headsets, phones) must be new and covered by (extended) manufacturer o m p e s N o t

C o m rt m p warranty for no less than five years from the date the device is placed into operation.

2. Whenever supported by the device manufacturer, all servers, switches, routers, firewalls, and other devices within the solution shall be configured with redundant power supplies and redundant network interfaces.

3. The Respondent shall work with interested PSAPs to interface/integrate host-remote positions in their existing mobile command and control assets with wireless ESInet connectivity to the NGCS for call delivery.

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.18 Human-Machine Interface (HMI)

C o m p e s N o t

C o m rt m p

1. The solution shall comply with NENA 54-750, NENA/APCO Human

Machine Interface & PSAP Display Requirements (ORD), and provide an explanation of any areas of non-compliance with the standard.

2. If a call is default-routed or otherwise diverted to a destination other than the normally intended destination, the call-handling solution shall recognize and present the originally intended destination and the reason why the call was diverted (reference sections 3.3.CC of

NENA 54-750).

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.19 Distinctive Ring Tones

C o m p e s N o t

C o m rt m p

1. The solution shall provide a ring tone for 9-1-1 calls that is distinctly different than the ring tones for administrative calls and text messages.

2. The solution shall provide a ring tone for text messages that is distinctly different than the ring tones for administrative and 9-1-1 calls.

3. The solution shall support user-selected, distinctive ring tones for each automatic call distribution (ACD) queue or call type.

4. The solution shall provide distinctive ring tones to be customized by agent role or login.

5. The solution shall provide distinctive ring tones for multimedia messages

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.20 Conference Controller (Voice or Text)

For the purposes of this section only, the term caller shall mean the person(s) communicating with 9-1-1 via telephone or text messaging. Respondents must clarify if the proposed solution allows conferencing of both text and voice or only like communication methods.

The Respondent shall support the conferencing capabilities that follow.

Requirements:

C o m p e s N o t

C o m rt m p

1. The conference controller shall enable the telecommunicator to add an outside caller or inside caller to an in-progress “live” call while remaining on the line, with no limitation as to what type of call the telecommunicator is handling.

2. The conference controller shall automatically control the audio levels (automatic gain control [AGC]) of the calling parties so that no degradation of voice quality occurs.

3. The original telecommunicator shall be able to mute/unmute (i.e., disable/enable the microphone of) or block the text messages of any party on the conference.

4. The original telecommunicator shall be able to deafen/undeafen

(i.e., disable/enable the earpiece/speaker of) any party on the conference without muting that party’s audio (i.e., allow the telecommunicator to speak to others on the conference, without that party hearing, while still able to hear that party).

5. The original telecommunicator shall be able to select and drop any party from the conference.

6. The original telecommunicator, or any of the conference parties, shall be able to drop out of the conference without disconnecting the original caller.

7. The conferencing feature shall support, at a minimum, any combination of up to six parties.

8. The Respondent shall describe its options for supporting multimodal conference functionality.

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.21 Call Monitoring

C o m p e s N o t

C o m rt m p

1. The solution shall allow authorized PSAP personnel to listen quietly to another telecommunicator’s live conversation.

2. The monitoring feature shall be controlled by the authorized personnel’s credentials.

3. Monitoring shall include the option as to whether the telecommunicator being monitored is made aware (visually or audibly) when their call is being monitored.

4. Monitoring shall not degrade the audio quality of the call.

5. The Respondent shall describe its options, or plans, for supporting a call-monitoring-like functionality for text-to-9-1-1 sessions.

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.22 Call Barge-In

C o m p e s N o t

C o m rt m p

1. The solution shall allow authorized PSAP personnel to listen quietly and mute/unmute (barge-in) while listening to another telecommunicator’s live conversation.

2. The feature shall be activated by utilizing a mouse or an easily invoked keyboard command.

3. This feature shall not degrade the audio quality of the call.

4. This feature shall be configurable to provide a tone to announce the barge-in.

5. The telecommunicator or supervisor is then part of a three-way call with the caller and original telecommunicator.

6. The Respondent shall describe options or plans for supporting a barge-in-like capability for text-to-9-1-1 sessions.

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.23 Callback

The Respondent’s solution shall support the callback capabilities that follow.

Requirements:

C o m p e s N o t

C o m rt m p

1. Callback of any 9-1-1 “call” (i.e., wireline, wireless, telecommunications device for the deaf/teletypewriter [TDD/TTY], text, and VoIP callers) shall be based on the calling party number.

o m p e s N o t

C o m rt m p

2. The solution shall utilize the calling party number (CPN) of a 9-1-1 caller to invoke the callback process.

3. The solution shall call back wireless or VoIP 9-1-1 calls utilizing the caller’s telephone number, located within the PIDF-LO fields, and automatically recognize +1 calls.

4. The solution shall use the Caller ID (CID) information to allow a callback to an administrative caller.

5. Any required dialing prefix digit(s) insertion/deletion (e.g., adding +9 or removing the area code) shall be automatic and not require manual input.

6. The callback function shall require only a single mouse click.

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.24 Abandoned Calls

C o m p e s N o t

C o m rt m p

1. The solution shall provide a visual and audible indication for abandoned calls.

2. The solution shall display the number of abandoned calls from the same callback number.

3. The solution shall clear the abandoned call count display upon successful callback and answer of the telephone number.

o m p e s N o t

C o m rt m p

4. The solution shall provide a configurable option allowing for an automatic response to an abandoned call.

5. The solution shall provide each individual agency with the ability to configure the automatic-callback option to be enabled or disabled by the agency.

6. The solution shall allow the system to automatically attempt to return a call and/or text message to an abandoned call, and to prompt the recipient of the call to take an action (e.g., press 1 to notify the agency that no assistance is needed; press 2 to be routed to 9-1-1).

7. The solution shall provide abandoned call reports as part of its MIS.

8. The solution shall support policy routing of abandoned calls

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.25 Repeat Callers

C o m p e s N o t

C o m rt m p

1. The solution shall provide a caller history feature that displays the date and time of the last 50 to 100 previous calls from the same number and include notes provided by the telecommunicator(s) who handled the previous calls.

2. The solution shall identify the repeat-call condition to the telecommunicator.

o m p e s N o t

C o m rt m p

3. The solution shall allow agencies to specify that new calls from the same caller (within a configurable period of time) shall be routed to the same telecommunicator who handled previous call(s), if that telecommunicator is available.

4. The Respondent shall describe capabilities for identifying and managing abusive repeat callers (e.g., non-service initialized [NSI] wireless phones, TDoS, location).

5. The Respondent shall describe system capability to allow call history printing from a snapshot as well as to retrieve printable call history reports, and advise how long call history data will be available for access/reference by the customer and member

PSAPs.

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.26 Real-time Queries

C o m p e s N o t

C o m rt m p

1. Telecommunicators shall have the ability to query telephone numbers, in real time, with a date/time range to retrieve call information for all calls—9-1-1 and non-9-1-1—received from a telephone number.

2. Telecommunicators do not have to be on an active 9-1-1 call to retrieve this information.

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.27 Speed Dials

C o m p e s N o t

C o m rt m p

1. The solution shall provide separate and multiple speed-dial lists for each group:

a. System wide (enterprise);

b. PSAP/Agency (local operations); and

c. Personal (by role or login ID).

2. The system administrator shall maintain the enterprise-wide speed-dial list.

3. The PSAP-wide speed-dial list is managed by the local system administrator at the PSAP.

4. Telecommunicators shall have the capability to maintain their own personal speed-dial lists.

5. The solution shall provide access to speed dials with a minimum of mouse click actions.

6. The solution shall provide a hierarchical organization of speed dials

(up to at least five levels deep), in which a list entry may refer to a single speed dial or another list.

7. The solution shall allow alphanumeric entries (e.g., 1-888-911-

HELP).

8. The solution shall allow extra digits or codes necessary to automatically dial a number and complete a call based on the line type (e.g., long distance access, personal identification numbers

[PINs], and star-code transfers).

o m p e s N o t

C o m rt m p

9. Telecommunicators shall not need to take any action to immediately access speed-dial list changes. (i.e., reboot or refresh login)

10. The solution shall associate content (files, links, etc.) with a speed-dial entry to include images, video, floorplans, comments, etc.

The Respondent shall describe if and how this content is searchable.

11. The solution shall allow display of speed dials in either list form or graphical form (i.e., as a grid of clickable buttons, icons, graphics, and/or images).

12. When a speed dial or list is assigned to a button that appears in the telecommunicator UI, the solution shall allow for the display (in a popup window) of a user-selectable set of fields when the mouse pointer hovers over the button.

13. The Respondent shall describe how additional information is entered and associated with an entry.

14. The Respondent shall describe search functionality; search-as-you-type capability is preferred.

15. The Respondent shall describe options for uploading and using user-provided icons/graphics/images for speed-dial buttons.

16. The Respondent shall support speed-dial entries/buttons that are dynamically populated with agencies (e.g., law enforcement, fire/rescue, emergency medical services [EMS], poison control, animal control) and services (e.g., towing, language translation) based on the caller’s location.

17. The solution shall support a minimum of eight speed-dial entries per service area (analogous to a legacy emergency service zone

[ESZ]).

18. The solution shall support intelligent manipulation of the dialed digits (e.g., area code removal for 7-digit local dialing, adding ‘+1’ for 11-digit dialing, etc.).

o m p e s N o t

C o m rt m p

19. The Respondent shall describe all methods of speed-dial import and export (e.g., comma-separated values [CSV], Structured Query

Language [SQL], eXtensible Markup Language [XML], etc.).

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.28 Automatic Call Distribution

C o m p e s N o t

C o m rt m p

1. The solution shall permit trained and authorized customer staff to provision ACD-related queues, routing, and telecommunicator skill settings, as needed.

2. The solution shall support, at a minimum, the following ACD next-available-telecommunicator selection algorithms on a per-queue basis:

a. Longest idle.

b. Top down.

c. Round robin.

d. Ring all.

3. The solution shall provide the ability to change roles without having to log out and log back in.

o m p e s N o t

C o m rt m p

4. The solution shall display to a telecommunicator the number of calls in each queue.

5. The solution shall toggle between “ready” and “not ready.” While ready, telecommunicators can receive calls presented through the

ACD queues. Conversely, ACD calls are not presented to telecommunicators who are not ready.

6. The solution shall provide the option to require a telecommunicator to select from an agency-defined list of reasons when changing their status to “not ready.”

7. In a “longest idle” ACD environment, switching to “not ready” shall not reset the timer used to determine “longest idle” status.

8. The solution shall provide a configurable option of forced

(automatic) answer of ACD calls, which connects 9-1-1 callers to the next available telecommunicator, without any action needed on the part of the telecommunicator.

Optionally, forced answer can provide an audible alert to the telecommunicator prior to connecting the 9-1-1 caller to the

9. The solution shall provide an optional, automatic, and configurable

“wrap up” period following the end of a call. During this period, the telecommunicator is considered unavailable for ACD calls and may perform post-call tasks without interruption. Once the wrap up period expires, the telecommunicator is automatically made available for ACD calls.

10. The solution shall support the ability of each telecommunicator to record automatic greetings, in their own voice, for each queue or call type. This enables consistent call answering, as well as giving the telecommunicator a notification of the type of call they are about to handle.

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.29 Real-time Statistics

C o m p e s N o t

C o m rt m p

1. The solution shall provide an option to each PSAP for one or more wall-mounted monitor/television displays for presenting real-time call information as configured by the PSAP.

2. Display information shall include, at a minimum:

a. Name of queue or call type/category.

b. Number of calls in queue or call type/category.

c. Longest call-in queue or call type/category.

d. Number of telecommunicators logged in.

e. Number of telecommunicators available for calls.

f. Number of telecommunicators not ready.

3. The solution shall support configurable thresholds for color and audible alerts.

An example of the kind of display being requested is shown below.

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.30 Call Mapping

In the event that the Respondent’s call-handling solution does NOT include call location mapping as a no-charge feature included in the base version of its solution, the Respondent is asked to provide separate pricing for a call location mapping solution that is fully integrated with the call-handling solution, and which meets the requirements below.

Requirements:

C o m p e s N o t

C o m rt m p

1. The HMI shall display emergency event location and calling device location information on a map display.

2. The map display configuration (e.g., map scale, base map data, iconography, caller/event location display rules) shall be determined by the user’s profile/role.

o m p e s N o t

C o m rt m p

3. The HMI shall provide the ability to display updated location (from

CHE re-bids) on the map display in real time.

4. The HMI shall display x-, y-, and z-axis location data received by value or reference.

5. The HMI shall display the uncertainty estimate and estimated positional accuracy for x-, y-, and z-axis location information.

6. The HMI solution shall convert 3D (x-, y-, and z-axis) information back to 2D (x, y) data if required for the CAD, sometimes known as flattening.

7. The HMI solution will implement the NENA 3D GIS specification within 18 months of becoming available, including implementing

“fallback” to 2D capabilities for queries to any direct or recursive

Emergency Call Routing Function (ECRF) that does not have 3D support.

8. The HMI shall provide the ability to accept or reject the update request results.

9. If previous calls/incidents are shown on the display, the HMI shall provide the ability to configure how long previous calls/incidents will remain on the display before being automatically removed/hidden.

10. The HMI shall provide the ability to draw and label, modify, and delete geometric shapes or points on the map display.

11. The HMI shall provide the ability to make such dynamic features private (i.e., visible only to the creating agent), visible to specific groups (i.e., roles, agencies), or visible to all users.

12. Such dynamic features shall be able to be captured and stored for easy reuse.

13. The HMI shall have the ability to “zoom” the map display.

14. Zoom parameters (e.g., default zoom level when call arrives;

appearance of various features, information, iconography, and o m p e s N o t

C o m rt m p layers at different zoom levels) shall be configurable based on user role.

15. Zoom history shall make it possible to return to the previous zoom level with a single click (up to ten steps back).

16. It shall be possible to return to the default zoom level with a single click.

17. The HMI shall provide the capability to pan the display.

18. Pan history shall make it possible to return to the previous pan location with a single click (up to ten steps back).

19. It shall be possible to return to the current call location with a single click.

20. The HMI shall provide the ability to set default GIS layers that are visible based on user login/role, and to manually select/unselect individual GIS layers for display.

21. The HMI shall provide the ability to search for a location using either: a) geo-coordinates, b) civic addresses, or c) common place name.

22. The HMI shall display location search results to the

23. If multiple results are returned, each shall include a confidence/match-score and clicking on a result shall re-center the map on the selected location.

24. The HMI shall provide the ability to retrieve location information (i.e., address and geo-coordinates) by clicking on a point on the map display.

25. The HMI shall provide the ability to designate a location as a call/incident location by clicking on a point on the map or selecting it from the list of search results.

o m p e s N o t

C o m rt m p

26. The HMI shall provide the capability to display the emergency response agencies associated with a caller’s location on the map

27. The HMI shall provide the ability to display the emergency response agencies associated with an emergency location on the map

28. The HMI shall provide the ability to graphically display the accuracy/uncertainty associated with a given calculated position.

29. The HMI shall support the ability to represent calls on the map with different icons based on class of service/type of call (e.g., wireline, wireless, VoIP, SMS).

30. The HMI shall support the representation of additional location information for a call based on call type/class of service (e.g., wireless, SMS, VoIP).

31. The HMI shall provide the ability to answer and manage calls directly from the map.

32. The Respondent shall describe how its solution integrates with GIS and other intelligent safety platforms on the same display.

33. The HMI shall accept standard Esri GIS data formats (geodatabase, shapefile, REST services).

34. The HMI allows for remote update capability through a real-time connection to the customer data rather than requiring the customer to push a batch data upload to system (Consume REST services).

35. The Respondent shall describe the process for updating map data and aerial imagery.

36. The HMI shall integrate Google or other platforms that provide street-level views.

Use this space to elaborate on the compliance responses to the requirements in the table above. Include any additional information (diagrams, graphs, screenshots, etc.) you think is needed to describe how your

2.31 Training

C o m p e s N o t

C o m rt m p

1. Proposals shall include options for both train-the-trainer (superuser) and end-user models with different training content for telecommunicator staff versus supervisors and/or administrators.

2. Proposals shall include options for onsite training and remote, virtual training for the customer and member PSAPs.

3. Proposals shall include web-based, self-paced on demand training for both superuser and end-user models.

4. Operational training on the MIS functions and call-handling and mapping features and functionality will be provided to all telecommunicators and superusers.

5. Training for superusers shall also include monitoring, reporting, system health, and performance (MIS) components.

6. Training for superusers shall also include GIS and mapping administration.

7. Proposals shall include options for PSAP-specific training at each

PSAP and train-the-trainer instruction for regional training personnel.

8. Training schedules shall accommodate 24 x 7 shifts.

9. All training materials shall be available in digital form.

o m p e s N o t

C o m rt m p

10. The customer(s) reserve the right to record all training sessions and make available to staff online for refresher and new-agent training at no additional charge.

11. Training services shall include an onsite trainer/coach in each

PSAP for a minimum of four hours for each different shift immediately following cutover (on-the-job training/coaching).

12. The Respondent shall provide a summary/syllabus and duration of each training class so that PSAPs can coordinate…