Signature Authorizing Vendor RFP Response Date

36. 
    INFRASTRUCTURE AND Environment
    

Departments

Below are some of the major departments within City of Coronado.

DEPARTMENTS

Administrative Services

City Manager’s Office

City Clerk’s Office

Community Development

Fire Services & Lifeguard

Public Services & Engineering

Police Services

Library Services

Recreation and Golf Services

Current Voice Infrastructure

City of Coronado currently utilizes three (3) AT&T PRI circuits, one at each of facilities listed below:

1. 
   City Hall
   
2. 
   Police Services
   
3. 
   Fire Services
   

For remote sites, the City currently uses NEC IPS 2000 DMR (Rls SC-3655 N1-0003.00 M – Series 3800 R13) equipment to provide communication services with a combination of digital and IP sets over 100 pair copper cable, City-owned fiber optic cable, and WAN circuits to all sites in a “hub and spoke” WAN architecture back to the primary PBX. This provides PSTN connectivity to all sites and 4-digit internal dialing to all sites. Current remote site telephone hardware will be replaced in this project and the Vendor must provide survivable branch switches as further described below.

The City currently utilizes Microsoft Office 365 Exchange Unified Messaging (UM) as their voice mail platform. The NEC PBX has an integration with a Dialogic card that does a Time Division Multiplexing (TDM) to SIP conversion and an Audiocodes M1k gateway that connects to Office 365 Exchange Online for the integration.

The following is a summary of the telephony hardware currently in place at City of Coronado for its sixteen (16) sites:

• 
  The existing core NEC telecommunications infrastructure at City of Coronado is a hybrid time division multiplex (TDM) and voice over internet protocol (VOIP), with several sites using Voice over Internet Protocol (VoIP) phones.
  
• 
  NEC Dterm Series Digital and IP phones
  

IT Infrastructure Overview

37. 
    Wide Area Network (WAN)
    

1. 
   City Hall 1825 Strand Way 
   
2. 
   Police Services - 700 Orange Ave
   
3. 
   Public Services - 101 B Ave
   

• 
  Community Center (1845 Strand Way)
  

• 
  Tennis Center (1501 Glorietta Blvd), Marina (1715 Strand Way), and Clubroom/Boathouse (1985 Strand Way) buildings are connected to City Hall via dark and lit fiber (1Gbps).
  
• 
  Library and Fire are connected to Police Services via dark and lit fiber (1Gbps).
  
• 
  Lifeguard Tower/service building (920/930 Ocean Blvd), Fire building at the Cays (101 Grand Caribe Causeway), Golf Administration (2000 Visalia Row) are connected to Police via Spectrum Cable metro-E 5Mbps connections.
  
• 
  Golf Maintenance building (649 Glorietta Blvd) is connected to City Hall via an ipSec tunnel over the Internet (via AT&T DSL).
  
• 
  Senior Center (1019 7th) – will be connected to Police Services via dark and lit fiber (1Gbps).
  

38. 
     Local Area Network (LAN)
    

39. 
    IT Environment
    

• 
  Datacenter – Primary data center is located at the Police services facility equipped with a generator and hardened physical security. Backup datacenter is located at City Hall. VMware and SAN infrastructure exist at each location.
  
• 
  Email – the City recently completed a migration to Microsoft Office 365 for Email and Unified Messaging.
  
• 
  Server Virtualization – VMware 6.0 on (3) Dell hosts. Approximately 74 virtual servers.
  
• 
  SAN/NAS – 40 TB Nimble Storage and a 42TB Dell EqualLogic Backup SAN
  
• 
  Server Racks – 1 X 4 post cabinet at City Hall and 2 x 4 post cabinet at Police Services.
  
• 
  Server – Dell PowerEdge R730s is the preferred server model
  
• 
  Internet - Cox (100Mbps) and redundant Time Warner (100Mbps) with 1Gpbs Ethernet handoff at Police Services.
  
• 
  Firewall – Redundant Palo Alto 3020 firewalls are located at Police Services.
  
• 
  UPS – APC Symmetra 12KVA and Mitsubishi 24KVA at Datacenter(s), APC 500VA and Smart UPS 2000 in telephone closets.
  

40. 
    Desktop Environment
    

41. 
    The City will require a test of any software that will be loaded on the desktop with our standard system images to ensure compatibility. Describe any known compatibility issues with any of the software or hardware above.
    

VoIP Compatible Network

It is understood that the current network infrastructure will not fully support an implementation of the VoIP platform envisioned. However, all network infrastructure will be upgraded in order to meet best practices for a VoIP deployment. The vendor can make the following assumptions in order to configure their proposed solution:

42. 
    The City’s current preference is to run the VoIP network on a converged backplane with the telephone connected to a Power over Ethernet (PoE) LAN switch through the wall jack, and the computer connected to the telephone. This is contingent on the ability of the telephones to provide an IP address, separate VLAN, and different QoS prioritizations to voice and data. If you cannot support this requirement, please explain your workaround solution below.
    
43. 
    Cabling:
    

1 x 4 Pair Category 3 drop per office/cubicle for analog/TDM telephones/devices

All cable will be certified and labeled prior to the deployment of the new phone system.

44. 
    The City network will support the following as a minimum (we have also noted desired performance in parenthesis, although this level will not be guaranteed):
    

Average Jitter <80ms (40ms)

Packet Loss <1% (0.1%)

Peak WAN utilization <80% (50%)

45. 
    Internet based IP-VPN, with no QoS, connectivity to remote workers using either VoIP desk phones or softphones.
    
46. 
    The City will provide access LAN equipment to include 10/100/1000 Ethernet, Power over Ethernet (PoE), Quality of Service (QoS), Layer 2 switching, VLAN support, and basic port based security.
    
47. 
    UPS Battery Backup, power, cooling, patch panels, and MDF to IDF inter-connectivity, as required.
    

48. 
    Vendor Information
    

49. 
    Provide a brief (two or three paragraphs) overview and history. Describe the organization of your company.
    

50. 
    Please state how many years your company has been installing this manufacturer, this system, and this particular model. Please summarize your certifications, sales volume, Distributor tier and any special recognition awarded by the system manufacturer of each component (phone system, voicemail, ACD, data network, Microsoft, etc.) you are proposing.
    

51. 
    How many installations does the Vendor have with this same system and version as proposed in this project and installed within 100 miles from Coronado City Hall located at 1825 Strand Way, Coronado, CA 92118?
    

52. 
    How many offices does the Vendor have? Does Vendor have a local office? If not, how will the Vendor provide sales, installation, warranty and maintenance support to the City?
    

53. 
    The City prefers that the project manager and lead engineer for this project be based within a 100-mile drive to Coronado City Hall or within a 2-hour flight to SAN. Please state your intended compliance. Please summarize your process for training and certifying Project Managers, Lead Engineers, and Lead Technicians.
    

54. 
    Briefly summarize the typical Scope of Work, Project Plan, and process for deploying a solution such as the one described in this RFP. (1-2 paragraph maximum, details can be provided in following sections.)
    

55. 
    Briefly describe Vendor’s standard procedures for cutover coverage, trouble identification/reporting, and punch list resolution. (1-2 paragraph maximum, details can be provided in following sections.)
    

56. 
    Briefly describe Vendor’s standard procedures for warranty and maintenance coverage, who would provide maintenance labor and hardware, and how repairs would be provided. (1-2 paragraph maximum, details can be provided in following sections.)
    

System Manufacturer Background

57. 
    Provide a brief (two or three paragraphs max) overview and history of the manufacturer of the system being proposed.
    

58. 
    What is the manufacturer’s annual sales volume, net earnings, R&D spend, and market share (cite source) for the last year?
    

59. 
    Provide a copy of this year’s Gartner Magic Quadrant report (or similar) that shows the manufacturer’s position.
    

60. 
    Briefly summarize the history of the solution platform being quoted that has brought it to its current point of development. Summarize the future vision of the system.
    

Reference Accounts

61. 
    Provide contact information for two local private industry references and three California municipal references, using the same make and model equipment to the proposed solution. Ideally, these references should be from the same industry, be the same size, and be located within 100 miles from Coronado City Hall.
    

62. 
    In addition, provide at least one reference account that has experienced negative service issues. Please describe how your organization responded to the issue(s) and possibly improved internal processes.
    

63. 
    Critical Requirements
    

System Reliability

64. 
    No Single Point of Failure (99.999% availability) for core applications and PSTN/SIP connectivity – Any element in your design that would cause the failure of a significant portion of the system should be made redundant. If redundancy is not available for this element, then the element should be made highly available by adding hot swappable redundant power supplies, RAID hard drives, etc. In addition, software upgrades should be able to be loaded to the system while in operation, with no, or momentary, downtime to implement the software patch.
    

65. 
    Mirrored Redundancy for Call Processing – Hot standby failover to a synchronized secondary processor that has a synched database copy and awareness of all calls in progress. Active calls should not be dropped and phones should home to the 2nd processor immediately when idle without rebooting the phone. When the primary server is brought back into service, phones should not require a reboot to recover to the primary processor.
    

66. 
    For on-premises solutions, the City desires a geographic redundancy solution, where primary servers are located at the Police Services building and secondary servers at a Disaster Recovery (DR) location located at City Hall. Vendors proposing non-premises solutions (e.g. hosted or cloud/SaaS) are expected to have geographic redundancy as part of their base cost. For Vendors proposing on-premises solutions, in the case of failure at Main location, all VoIP call processing and registration, voice mail, AA, and mobility (extend and reach / simultaneous ring) functionality should re-home to live servers in the DR facility. All City DID numbers should automatically connect to this DR location and all City locations and remote softphone or mobility stations should automatically connect to this DR location if Main administration is no longer available. Failover/re-homing/re-registration time should be under two (2) minutes. Device licensing at the Disaster Recovery location should allow all users to connect to this location. Please describe below how this functionality would work, any WAN requirements or considerations, how the main and DR systems are kept synchronized, how long a failover would take, and how the system would recover to normal operation upon recovery of the primary location.
    

67. 
    In the event of a failure of the WAN, or the unavailability of the central phone system servers, each remote location marked as survivable on Schedule B must have the ability to continue to process internal calls as well as external calls over local PSTN trunks (e.g., 2-4 standard analog phone lines) to allow calling to 911.
    

Unified Messaging

68. 
    The City defines Unified Messaging as the following. Please confirm that a user on the system can attain all of the following features/functionality simultaneously, and briefly discuss how this functionality is provided.
    

Voicemail messages which appear in the user’s inbox have the actual voicemail attached as a .wav or mp3 file that can be played from the computer or SmartPhone;

Email inbox, SmartPhone inbox and voicemail mailbox remain in synch as messages are played and deleted; and vice versa;

Voicemail messages that are listened to from the computer or SmartPhone will turn off the Message Waiting Indicator on the phone system;

Messages that are deleted from the computer or SmartPhone are deleted from the voicemail store and moved to the deleted items folder;

Messages that are deleted through the telephone user interface of the voicemail are deleted from the email and SmartPhone inbox and moved to the deleted items folder.

Messages can be saved to personal folders, .pst files, or document management system by dragging and dropping from Outlook, OWA, or SmartPhones (does not require a user to “Save As” a message for retention).

Response: Comply, Included Partial Comply, Included Optional Cost, Not Included DO NOT Comply

69. 
    The City is interested in the possibility of using Microsoft Office 365 Exchange Unified Messaging as the voicemail for their new system. As previously noted, the City currently uses Exchange Online UM as their current voicemail. Please state below whether you are proposing to maintain connectivity to the existing Exchange 365 voicemail infrastructure why or why not.
    

Please compare and contrast the telephone system Manufacturer’s standard voicemail to the Exchange UM voicemail. What, if any, functionality is lost when using Exchange UM as the voicemail instead of the Manufacturer’s own Unified Messaging platform? Do you recommend installing Exchange UM – why/why not?

If you are not quoting Office 365 Exchange UM as your voicemail, but are capable of doing so, please show, in the optional section of Schedule A, the cost savings that would accrue from not having to purchase your voicemail, but adding in professional services to implement the telephony side of an integration to Exchange UM.

Please describe how your phone system would integrate with Exchange UM as the voicemail system, including type of integration and any additional hardware/software required. Please note if the Vendor is a Microsoft certified Exchange UM integrator and would like to be considered for the Exchange UM integration if The City decides to pursue that path. How many Exchange UM integrations has the vendor completed with the phone system quoted?

70. 
    Coronado UM users like the ability for Exchange UM to convert voicemails to emails through speech to text. This is a mandatory feature for any Exchange UM integration and a highly preferred functionality for all other voicemail/UM systems. Please describe how this functionality is provisioned in the solution that you are quoting, and include it in your base pricing. Vendors will not be disqualified if they cannot provide this functionality, but it is highly desired by all staff.
    

Office 365 Skype for Business (S4B) Integration - Mandatory

71. 
    The City is currently running Skype for Business within Office 365 for Instant Messaging and Presence. It is expected that this system will be used primarily for internal city use and any new VoIP system IM/P functionality would need integrate with S4B.
    

Does the system currently integrate with Microsoft Skype for Business Server (S4B) and Skype for Business client? If not currently available, what is the manufacturer’s long-term vision regarding these integrations?

72. 
    How does the system integrate with Microsoft S4B? Describe architecture, licensing and integration method.
    

73. 
    Will the phone system send status updates to S4B for presentation in the Skype for Business client? Will the phone system receive presence updates from S4B and show them on the phone or soft-phone client?
    

74. 
    The system must support integration and federation with S4B Online through Office 365.
    

75. 
    Will the system allow a user to start a call on the phone system and then add in Microsoft desktop videoconferencing, Instant Messaging, collaboration, desktop sharing, whiteboard, etc?
    

76. 
    Has the Vendor implemented S4B integration for another client? Please describe any best practices or constraints regarding this implementation. What unique abilities or integration points does the system provide with S4B?
    

Unified Communications (some Optional)

77. 
    The City would like to receive optional pricing for a 10 port audioconferencing bridge that would be integrated into the proposed system and displace its use of outside conferencing providers. Briefly describe the application below, what hardware and software are required to support the application, the pricing model, and the ability to expand the functionality in the future.
    

78. 
    Extend calls to cell phone (simultaneous ring): Provide pricing to allow the telephone system to automatically extend a phone call to a user’s desk phone and their cell phone simultaneously, in such a way that the call can be answered at either device. Describe whether the system automatically recognizes answering the call at the cell phone, or whether the user must dial a digit or code to receive the call; in either case, unanswered calls should go to the extension’s voice mailbox. Describe whether the system provides a user portal to allow user management of their alternate (cell phone) number. Provide optional pricing for 15 users on Schedule A.
    

79. 
    Coronado is interested in the ability to do SMS Texting from a city DID number from the proposed system. This functionality could be provided from the telephone or a UC client. Coronado desires a texting solution that integrates with the proposed system and becomes part of the quoted Unified Communications (UC) environment. Please provide a description of your ability to provide such integrated texting using hard phones, soft phones, integrated mobility phones, ACD agents, and email. Provide option pricing where indicated on Schedule A.
    

80. 
    Calls that go to voicemail should allow the caller to press 1 (or other button) to reach the called person on their cell phone, press 0 to reach the operator, or leave a message. If the call is not answered on the cell phone, the call should be pulled back and a message taken in the voicemail system at Head Office. When the call is extended to the cell phone, the caller ID of the original calling party should be passed to the display of the cell phone. Please describe how you will provide the functionality requested above and a screenshot of the user interface.
    

81. 
    Provide optional pricing on Schedule A for Find Me Follow Me functionality as described in Schedule C - Users have the ability to program the system with a set of rules by day of week, time of day or mode. System will attempt to locate them at different phone numbers and pull the call back to voicemail if unanswered.
    

82. 
    Describe any fax server functionality of your platform. Provide optional pricing for Fax Mail functionally for 20 named users or departments and 2 universal ports. Can fax be automatically directed by DNIS/DID to a user’s personal mailbox? Will the presented document be a tiff or .PDF (preferred) file? Can a user create and send a fax from their desktop using a custom cover page and a library of pre-existing documents? What format (word, .PDF, excel, etc.) can the pre-existing documents exist in?
    

Trunking to PSTN

83. 
    The City intends to install new SIP circuits for PSTN access at City Hall and Police Services buildings. On-premises vendors must include the installed cost of new session border controllers (SBC) at each site (made redundant as described above for no single point of failure), where indicated in Schedule A. Vendors proposing non-premises (hosted or cloud) can assume that the City will desire dedicated MPLS or Private Line connectivity to vendor’s site(s) to support Quality of Service (QoS). Please indicate your compliance with the Trunking to PSTN requirements above, and explain how the proposed solution provides the required PRI card(s).
    

UCD, Hunt Groups, or ACD

84. 
    The City has several departments and applications that would benefit from the ability to have calls delivered to multiple stations simultaneously or in a round-robin fashion. The desired functionality goes beyond what is traditionally available in a hunt group but does not rise to the level of a full Call Center with logged in agents. What functionality does the proposed solution provide for the following features? Please describe and include the professional services to deploy if the functionality is included in the base price, otherwise please provide optional pricing where indicated on Schedule A.
    

Basic reporting

Announcements and music on hold played to callers while waiting

Response: Comply, Included Partial Comply, Included Optional Cost, Not Included DO NOT Comply

Enhanced 911 (E911)

85. 
    The City requires the following functionality, generally referred to as E911 compliance, in addition to the 911 compatibility described in a later section. Please state your compliance, and briefly describe how your solution could meet the following requirements, as well as your overall E911 strategy and abilities.
    

Send calling station DID number or an alternate ELIN (Emergency Location Identification Number) to the Public-Safety Answering Point (PSAP) through the digital trunks (initially PRI and changing to SIP). The City anticipates providing its PSTN carrier a Public Safety Automatic Line Identification (PSALI) database with every DID/ELIN number and associated exact location for that station (i.e., street address / building / room number).

Provide an export from the telecommunications platform of the ALI database in a format (e.g. NENA) suitable for upload to the carrier, e.g., using West (Intrado)

Notify a designated internal extension at the City PD Dispatch Center (staffed 24/7) through on-display, email, text or other real-time means when a user dials 911, and what extension (with exact location information) has placed that call. This notification should be immediate as 911 is dialed and not delayed until after the 911 call is completed. This notification should have a distinctive audible and visual alarm.

Provide specific ELIN (matches to ALI) information to the PSAP to allow for correct identification of the caller’s general location (site and building) in the event a station is not in the ALI database provided to the carrier.

Automatically update the user’s location when they log in to a different phone with their same extension or move their phone to a different area of the building, or to a different office.

Provide the ability for the PSAP to dial back to the DID number of the station that made the 911 call, including the situation when more than one 911 call is placed in a short time period.

Assign an ELIN temporary DNIS number to any extension that does not have a DID number to allow the PSAP to call the station back in an emergency.

Possibly provide station-specific location information for mobile phones using WiFi wireless access points (WAP), through triangulation and/or signal strength methods.

Response: Comply, Included Partial Comply, Included Optional Cost, Not Included DO NOT Comply

Paging - Analog

86. 
    The City uses a Bogen paging amplifier with TAM-B interface modules to integrate to the overhead paging systems at the Police, Fire, and Library buildings, with one zone per location. The current paging system is connected to the NEC system through a loop start trunk circuit (FXO analog trunk). Include the cost to integrate the proposed system to the paging system in Schedule A or MRC Schedule A where shown.
    

Proof of Concept

87. 
    Implementation of the new system will follow the Proof of Concept (PoC) model for deployment. All required servers will be deployed within the City’s network, and PSTN access will be installed onto the system. The City will then fully deploy required functionality to a pilot group of users in each location. If it is discovered that the system is materially non-compliant with the requirements of this RFP, or the specified reliability and quality cannot be provided (and cannot be remediated by Vendor within a reasonable amount of time); the City will be allowed to cancel the contract for material breach of contract by the Vendor. Once the functionality desired in this RFP is proven through the PoC, installation will continue for the rest of the system. At that point, all remedies provided in this RFP and by rule of law will remain available to the City.
    

88. 
    The proposed solution must support Uniform Coordinated Dialing between disparate telephone systems where a user simply dials an extension number and the phone system inserts, deletes or modifies digits to place the call through dedicated connections to the existing Telecommunications Network. This is required to simplify integration to the old system during deployment and testing, and phased branch-by-branch rollout of the new system.
    

The T1 card used to integrate with the existing City voice network will only be required through the implementation period and will no longer be required once the final location is cutover. The City would be interested in any ability to rent or borrow the required T1 card so that unnecessary equipment is not purchased. Please explain below how the proposed solution provides the required T1 card for integration to the existing City voice network.

89. 
    PoC acceptance will be defined as follows. The City expects that they will move from Proof of Concept to full system implementation upon completion of a PoC Delivery and Acceptance agreement.
    

System is complete, reliable, and meeting manufacturer specifications.

All integrations and functionality specified in RFP and SoW perform to expectations.

System runs reliably with no outages or downtime for at least 2 weeks.

System successfully completes mutually agreed User Acceptance Testing, which will formalize testing of the functionality required in the RFP.

Features of the system are easy to use and logically deployed.

Call flows and functionality are demonstrated to meet design criteria.

System is able to generate reports and alerts to the specifications of the RFP.

Paging – VoIP

90. 
    The City also intends to use native paging in the proposed telecommunications platform to attached VoIP phones with speakerphones. Describe how paging works in your system and any limits in the total maximum number of stations, and the maximum number of stations, that can be simultaneously paged in the base system.
    

91. 
    The City is interested in the ability to page all VoIP stations at the same time and assuming the maximum stations in native paging would then be exceeded, please describe any optional package(s) that would provide this functionality and related capabilities. Provide optional pricing in Schedule A and MRC Schedule A where shown.
    

Call Detail Recording

92. 
    The City does not presently use a call detail recording (CDR) system, also known as station message detail recording (SMDR). However, City of Coronado is interested in CDR with the ability to record the call information (i.e., timestamp, called/calling extension, called/calling PSTN number, duration of call, trunk used) for all calls to/from the PSTN. There is no requirement or need to cost calls. City of Coronado wishes to easily search and report on individual extension calls (e.g. most recent extension dialing 911) as well as report on total call counts to an extension (e.g. number of outside calls to the emergency number in Operations) and reporting on trunk usage (e.g. traffic reports). Please briefly describe the CDR system that is part of the base system, whether it can perform the above functions, and whether it can be easily used by authorized City of Coronado IT staff.
    

Integration with Current Network infrastructure

93. 
    The City will be replacing its current network infrastructure prior to the implementation of the new voice system. Vendor is expected to work in concert with the City, outside Vendors and other specialists to deliver a LAN, WAN, and PSTN configuration that is 100% operational and suitable for the solution. Vendor will be responsible for providing consultation, best practice recommendations, sample configuration scripts and programming guides for the models and software revision levels that The City has deployed. Network consultation and engineering will include all existing LAN/WAN switches, routers, and firewalls. The City will provide a copy of the current configuration and Vendor will provide a change control document that will amend the current configuration to support the implementation. The City (or 3^rd party specialist) will then implement the changes that are designed and vetted between the City and Vendor into existing IS systems.
    

94. 
    The City would like to implement VLAN segmentation in conjunction with this project and will rely on the Vendor for recommendations for separating VoIP traffic from data traffic, as well as creating VLANs for other types of data devices, and configuring trunking on access layer ports. It is expected that the VLAN segmentation will be accomplished by simple static routes within each location on the Layer 3 core switch. Please comment on your solution’s ability to meet this requirement, your prior experience in deploying such a solution, and any caveats or concerns you might have in implementing a mixed IP addressing deployment of VoIP.
    

95. 
    An initial discussion (upon contract award) will be held between the Vendor and the City to review all IS infrastructure systems, including all hardware installed, software revisions, and programming. Upon completion of this initial discovery, Vendor will provide recommendations for upgrades and remediation.
    

96. 
    After the Vendor recommended upgrades and remediation have been implemented and tested, the Vendor and Manufacturer are expected to guarantee the installation. If the installation fails the requirements of the RFP:
    

The City will assist in problem identification/resolution under the direction of the Vendor,

Vendor will need to provide definitive proof that the problem exists in the City’s network or IT infrastructure if there is an assertion to that effect,

Vendor will have five additional days to correct the problem if it is in the hardware they have provided.

97. 
    If the Vendor cannot provide a solution that supports the requirements of this RFP (after the City’s implementation of any remediation or upgrades recommended by Vendor), and cannot rectify the problem per the section above, it will be considered a material breach of contract on the part of the Vendor. Vendor will allow the City to return the complete system for a full refund, and remove the system once an alternate solution has been put in place by the City.
    

98. 
    Phone System
    

99. 
    Architecture: the City prefers that all locations be part of a single telephone system with a single database image. Multiple systems with databases that are coordinated by a centralized system administration software that emulates single system functionality are not compliant with this definition. Please state whether your base pricing includes this architecture.
    

100. 
     Virtualization – the City prefers VMware v5.5 ESXi virtualized servers in order to minimize hardware requirements, leverage capital investments, and facilitate server/application replication and failover. Describe the parts of your equipment stack that will and will not support server virtualization. Virtualization is preferred in this RFP but Vendors that can support virtualization will be preferred if all other issues are equal.
     

101. 
     Music on Hold – the City desires music on hold (MoH) at all locations. Please describe if the system provides the ability to play standard .wav or .mp3 files as music on hold from a file saved on the gateway. Please describe if the system can provide multicast music on hold that would stream one audio connection to each location (not one audio connection for every call on hold). Please describe if the system can be configured to stream music on hold as G711 while the rest of the VoIP traffic between locations is G729. Please note if conference calls that are put on hold while adding parties are able to speak with each other and not hear music on hold. This application should be included in the base pricing.
     

102. 
     Telephone Specifications:
     

Phones that utilize paper designation strips for button labels will not be accepted.

Backup Receptionist or Departmental Answering Point telephone - The City requires a PC “Operator” position. This telephone will provide coverage to department operators and provide full operator functionality in cases of emergency, call coverage or when a PC console needs to be restarted. This should be a standard multi-line phone with attached Busy Lamp Field, or a hardware based (non-PC) attendant console.

Staff (Standard) telephone requirement is for a multiline set capable of supporting at least two extension appearances. The following features, accessible via fixed or soft feature keys, are required: internal and PSTN dial-tone, hold, transfer, message waiting indicator, ad-hoc five-party conference call, system speed dial access, personal speed dial access, and forward to voice mail. LCD display, two-way speakerphone and the ability to mute speakerphone, headset and handset calls independently are requirements for this set.

Executive telephone requirement is for a Full Duplex speakerphone capable of supporting Busy Lamp Field appearance for 1 other telephones, intercom to their assistant, and one touch speed dials for 3 numbers (minimum 6 button phone required). All other features of the Standard telephone shall be supported as well.

Telephones with minimum of six BLF requirement is for a telephone that meets all the specifications of a Standard Telephone but has enough buttons to provide six Busy Lamp Field appearances for other telephones.

Executive Assistant (Secretary) telephones shall include all features of the standard telephone, however be equipped with the ability to monitor at least three Executives. Secretary should be able to tell if an Executive is busy on any of their extension appearances. Call Coverage Keys should ring or delay ring along with the Executive’s telephone. Secretary phone should have 2-way intercom button to their executive. This phone should have four (4) message waiting lights (MWI), to provide a MWI for each executive (3) as well as for the department.

Empty Desk/Visitor Cube telephones should match the specification for Standard (Staff) phones and include a telephone license, but do not require a VM license.

Basic (or courtesy) telephone requirement is for a single or multi-line phone that would be placed in very low usage areas such as intern desks, waiting areas, warehouse, lunchroom, etc. The following features, accessible via fixed or soft feature keys, are required: internal and PSTN dial-tone, hold, transfer, system speed dial access, and park pickup.

Analog Stations - The proposed system must allow analog stations such as the retained Polycom conference phones to access substantially all of the features available to VoIP telephones through the use of feature access codes – especially conference and transfer.

103. 
     Telephone - Hard phones: Provide a brief description and picture for each telephone being proposed below. If you are quoting VoIP telephones, specify data speeds available/quoted (10/100/1000), optional snap-in interfaces available, and power requirements (or which PoE class) for each phone. Describe the phone’s “headset” function, ideally having a separate headset jack where the handset does not need to be removed from the cradle to answer calls. Please note if any of the phones require a wall mount kit and include pricing in the Schedule A. Please fill in the model number that you have quoted for each phone type onto the appropriate line of Schedule B.
     

104. 
     Telephone - Color Display: If a color display option is available (and not already included in your proposal) include the incremental cost to upgrade all telephones to color in the options section of Schedule A.
     

105. 
     Telephone – Soft phones: Provide a screenshot and brief description for the PC softphone highlighting its features and functionality. Describe whether a soft phone be able to ring simultaneously on an attached (USB) headset/handset as well as at the PC. Will computers that do not have multimedia speakers be able to ‘ring’?
     

106. 
     Telephone – Departmental “must answer” line is a line appearance and button that appears on a group of telephones to be answered by anybody in a department. Callers would access this line either by direct dial, operator transfer, or zero out of voicemail. It should have multiline attributes so multiple calls can be ringing into the group simultaneously. This button should include a Message Waiting Indicator for voicemails to this extension in addition to the user’s voicemail. Users should be able to answer the department line simply by picking up the handset or pressing a key to answer on speakerphone. Please describe how the department line is accomplished and any limitations.
     

107. 
     Telephone Functionality - The following features which should be supported in the quoted solution:
     

hunt groups,

simultaneous ring groups,

pick-up groups,

directed call pick-up,

directed hold pick-up,

directed call park (park+extension to park, unpark+extension to retrieve),

personal speed dial lists, and department speed dial lists

most recent received phone numbers,

most recent dialed phone numbers,

authorization codes to override toll restriction.

Please respond with your compliance to these features, any required work-arounds, and any limitations to the number of phones in a pickup group, ring group, or shared extension.

System Architecture

108. 
     Provide a brief description and discussion of the recommended system architecture. Describe connectivity and communication between its integral parts. Include a Visio or Bay Face diagram to illustrate the quoted architecture (not a generic drawing). Also, include a standard data rack elevation showing all Data Center equipment including servers, cabinets, switches and routers.
     

109. 
     The proposed system must be able to provide traffic reports and report historic trunk utilization by trunk group or for specific lines, in the base system being quoted. The system should provide a peak busy usage report that shows the maximum number of lines used during specified periods. Please include samples of these reports in the appendix and your softcopy.
     

110. 
     The proposed solution should be 911 compatible, which we define as:
     

Allow a 911 call to be made from any station, even if that station is restricted to extension dialing;

For stations that do not have local PSTN connections, calls over the WAN/VoIP infrastructure should correctly send a default location for that station to the PSAP that will differ from the rest of the stations that connect over those PSTN connections;

The operator or system administrator should be notified when a 911 call is made from the phone system.

111. 
     The City will provide any required battery back-up. List here any components of the proposed system that may require any non-standard plugs or voltage (DC, 220v, twist-lock), and the specification.
     

Software

112. 
     Describe the underlying operating system used for the applications that form the telecommunications platform (i.e. Windows Server, VXWorks, Linux, Unix, etc.). List the operating system for each server being proposed. The Vendor is responsible for providing the Operating System (OS) for all servers required.
     

113. 
     Please describe how the underlying OS has been “bolstered” to prevent exploitation of OS security flaws. Unneeded applications should be uninstalled, removed, or disabled from the OS. This is particularly relevant to Windows operating systems. List the Firewall ports that your application uses, keep opens, or listens to.
     

114. 
     The City prefers to implement a new software release after it has been generally available (G.A.) for at least 3 months. The software can then be considered stable and there should have been an x.1 type software release to resolve any software bugs. Please make note if you are recommending the installation of any software that does not meet this criteria, and your justification for doing so. When is the next release due?
     

115. 
     If your solution uses any commercially available software for the Operating System, database, connectors, API, or other, please explain how the software is patched when the manufacturer of that software issues bug and security patches (Microsoft, Linux and VMware as examples).  Will the City be able to install these patches as soon as they are released, or must they wait for the UC Manufacturer to validate and support the patch?  What SLA will the Manufacturer commit to validating and releasing compliance with “High Risk” security patches?
     

System Reliability

116. 
     If not already answered in previous sections, please describe which resiliency features have been included into the base price on this RFP response. Describe how the proposed system provides fault tolerance. Please describe any functionality that makes the system inherently fault tolerant.
     

117. 
     If a branch site loses connectivity to the central call processor and fails into local survivable mode, list the specific features that will be lost in local survivable mode.
     

118. 
     Voice over IP
     

119. 
     VoIP Quality and Performance Expectations: It is expected that a Voice over IP installation will be reliable and provide high quality voice. We define the following as our minimum acceptable performance for VoIP telephone systems:
     

• 
  Provide 99.99% uptime of all applications including after-hours maintenance;
  
• 
  Provide 99.999% uptime of call processing including after-hours maintenance;
  
• 
  For LAN calls using G711, telephones should deliver an average Mean Opinion Score (MOS) of 4.5 (better than toll quality), and minimum Mean Opinion Score of 4.0 (toll quality);
  
• 
  For WAN or G729 calls between locations, telephones should deliver an average Mean Opinion Score of 4.0 (toll quality), and minimum Mean Opinion Score of 3.5 or better (cell phone quality);
  
• 
  Telephone calls will be free of echo, choppiness, sound artifacts, poor sound quality, and dropped calls.
  

120. 
     An initial discussion (upon contract award) will be held between the Vendor and the City to review all applications and data flows on the LAN/WAN, including all hardware installed, software revisions, and routing/switching programming. Upon completion of this initial discovery, Vendor will provide recommendations for upgrades and remediation.
     

121. 
     Vendor will conduct a VoIP Readiness Assessment of the newly upgraded LAN. This assessment should be performed within two weeks of the installation of any new LAN equipment to support VoIP, and configuration of QoS on all links, so the City has sufficient time to address any shortcomings discovered by the assessment prior to full deployment.
     

122. 
     The Network Readiness Assessment Scope of Work will consist of the following:
     

Testing Server shall be positioned on the core network switch expected to support the voice communications call server, with testing end-points strategically positioned in the voice VLAN of each office;

VoIP Assessment should test mesh connectivity between all WAN segments and offices (not just remote to core);

An initial test should be performed where call traffic is gradually “throttled up” to the limit set in Call Admission Control to ensure that the QoS bandwidth allocations are sufficient to prevent discarded packets;

Once voice capacity is established, Vendor should generate data traffic, such that the uplink from an IDF to the MDF is saturated to near 100% utilization while generating test voice traffic, to ensure that QoS on the LAN is properly implemented to prioritize voice packets over data packets.
This test will be repeated one time for each different access layer switch type to ensure that implemented QoS methodology is working correctly;

In order to test end-to-end QoS, Vendor should generate data traffic, such that the uplink from the Core Router to the Provider Edge (PE) Device is saturated and the Edge router is forced to shape traffic and drop excess data packets in favor of higher QoS voice packets, before putting traffic into the WAN link. Voice traffic will be generated and measured during the saturation test and Vendor will provide a Mean Opinion Score (MOS) for the voice traffic under load;

In order to test QoS over the WAN, Vendor should generate data traffic from multiple remote locations, such that the uplink WAN link from the WAN provider to the PE WAN router and CPE Core Router is saturated and the WAN provider is forced to shape traffic and drop excess data packets in favor of higher QoS voice packets, before putting traffic into the WAN link. Voice traffic will be generated and measured during the saturation test and Vendor will provide a Mean Opinion Score (MOS) for the voice traffic under load;

For the saturation tests above, the Vendor will provide all testing methodology, hardware and software that will be used to generate sufficient traffic to flood the uplinks from the IDF to the Core in the LAN, and between locations on the WAN. These tests will need to be conducted after business hours so that they do not impact business processes;

A normal testing session will then be initiated between all end points using expected voice and data traffic and should last no less than 3 days;

Testing shall use the G711 codec using a 64kb packet size with a 20ms jitter buffer on the LAN. If your system recommends other “Best Practices” then test should match manufacturer recommendations;

Testing shall use the G729 codec using a 20ms sampling rate and 40ms jitter buffer on the WAN. If your system recommends other “Best Practices” then test should match manufacturer recommendations;

Test results should include: throughput (bandwidth), packet loss, packet delay (latency), jitter (variable latency), and the minimum and average Mean Opinion Scores that can be expected per LAN/WAN segment;

Vendor will then interpret, and summarize the findings and provide a verbal and written recommendation for any remediation;

If the initial test of the network fails, and remediation is required. Vendor will retest the network one time with the same process as above, after remediation is complete, and prior to bringing the new voice system into production.

This Network Readiness Assessment Scope of Work is our minimum acceptable SoW and may not be reduced or answered as non-compliant by the vendor. Nonresponsive or noncompliant responses may be eliminated from further consideration. Please note your compliance below and comment on any additional methodologies recommended.

Response: Comply, Included Partial Comply, Included Optional Cost, Not Included DO NOT Comply

123. 
     Please comment on the diagnostic tools you will use and the type of report that we would expect to see. Please include a sample VoIP Readiness report in the CD provided with this response (paper copy not required). It is expected that the awarded Vendor, or a sub-contractor that specializes in this type of analysis, will perform these tests.
     

124. 
     What tool will be used to generate the required data traffic load on the LAN and WAN, in order to flood the uplinks and WAN circuits? Please note that this traffic generator may need to generate 10G worth of data on uplinks from the IDF to the MDF and 1G at other points in the network.
     

125. 
     After the initial VoIP network readiness assessment, Vendor will be required to explain and price any additional remediation recommended in order to achieve the goals above. Once the City has implemented the remediation, and the network has been certified through a follow-up assessment, the Vendor and Manufacturer are expected to guarantee the installation (other than WAN carrier quality issues). If the installation fails the requirements (for example due to dropped calls, poor quality calls, static, echo) then:
     

The City (and/or WAN provider) will assist in problem identification/resolution under the direction of the Vendor,

Vendor will need to provide definitive proof that the problem exists in the underlying Cabling/LAN/WAN fabric if there is an assertion to that effect,

Vendor will have five additional days to correct the problem if it is in the hardware they have provided.

126. 
     If the Vendor cannot provide a voice solution that supports VoIP to the expectations in this RFP (after the City’s implementation of any LAN/WAN remediation or upgrades recommended by Vendor), and cannot rectify the problem per the section above, it will be considered a material breach of contract on the part of the Vendor. Vendor will allow the City of Coronado to return the complete system for a full refund, and remove the system once an alternate solution has been put in place by the City.
     

VoIP Specifications

127. 
     List the manufacturer’s recommended best practice for CODEC choice, sampling rate, packet size, jitter buffer, etc. List the bandwidth, including overhead and QoS, for each recommended CODEC require. List the applicable VoIP CODECs that are supported on the platform, i.e. G.711, G.729A, G.729B, G.722, H.323, SIP, etc.
     

128. 
     List the highest common denominator Codec across all applications being quoted. Will calls require transcoding between applications (voicemail, call recording, etc.)?
     

129. 
     List the CODECs that are supported natively by the telephones. Will telephones auto-negotiate CODEC over the LAN/WAN when connecting between offices without the need for an intermediary translation or transcoding? If not, how is transcoding provided?
     

130. 
     List the network parameters that are, or should be observed with the platform, i.e. 802.1p/q, Differential Services (DSCP), weighted fair queuing, Rapid Spanning Tree, VLAN pruning, device discovery, etc.
     

131. 
     Do the telephones natively tag packets with both QoS (Layer 3 – IP Header) and CoS (Layer 2 – Ethernet Header) bits? Do all telephony servers and services automatically tag packets with both QoS and CoS bits? Which Layer 3 DSCP or IP Precedence tags are recommended by the manufacturer for voice RTP traffic and VoIP call control traffic?
     

132. 
     Does the system support SIP trunks, SIP compliant gateways, or SIP telephones from other 3rd party manufacturers? Which manufacturers and telephone companies have been certified with the system? Describe any capabilities or limitations regarding the SIP implementation above or beyond the generic SIP feature set.
     

Encryption

133. 
     Do the telephones being quoted have the ability to encrypt the conversation between telephones, and between telephones and PSTN gateways? Will the system encrypt call setup control messages between locations and between the telephones and the Processor? Are you quoting any equipment that will not support encryption?
     

134. 
     Does the Vendor recommend implementing encryption as part of their proposed solution? Why, or why not? The cost of implementing encryption should be included in the base price quoted.
     

135. 
     What encryption techniques will be used? If the encryption method is certificate based, which server will mint certificates? How can certificates will need to be managed by City of Coronado IT staff? How will encryption integrate with City of Coronado network security devices such as Active Directory, 802.1x and Radius servers?
     

136. 
     How much latency is added to the call in encryption/decryption? Does encryption reduce the overall system capacity of the VoIP network? Does encryption restrict any system features or functionality (for example conference calls, ACD monitoring, call recording)?
     

137. 
     VOICE MAIL PLATFORM
     

138. 
     The City currently uses Office 365 Unified Messaging, many users like its voicemail translation capabilities. The City would consider a different unified messaging platform if there is limited loss of functionality. A seamless Office 365 Unified Messaging integration with the new communication system is preferred. Please describe your unified messaging solution features, and how your communication system would integrate with Office 365 Unified Messaging.
     

139. 
     It is imperative that any new voicemail platform be easy to use and require users to only press one (1) button for single digit prompting to access commonly used features. The voicemail platform should allow recording and saving of multiple greetings per user, and allow easy selection of which saved greeting to use. Please describe whether individual voice mail users can set the play order of saved messages (e.g. play newest saved messages first) and whether users can enable/disable the message envelope (date/time and caller ID) and set playing the envelope before or after the message. Please describe your solution, particularly listing the user button commands.
     

140. 
     The Vendor is required to set up two guest mailboxes on a demo system with integration to the PBX you are quoting so that we can test the user interface. Please provide a phone number and login information below. Please provide a copy of the voicemail quick reference guide on the following page and in the soft-copy of your proposal.
     

Voice Messaging System Description

141. 
     Describe your voice messaging product offering. Include a brief overview of the hardware, software, architecture, and components of the equipment proposed to meet RFP requirements.
     

142. 
     Does the manufacturer of the PBX also manufacture the voicemail solution? If not please provide information regarding the OEM company, their history, and relation with the PBX manufacturer.
     

143. 
     The Vendor is required to provide, install and maintain the computer platform, OS and software for the voicemail. Please provide the specifications of the platform you will be providing.
     

144. 
     List the operating system used by the voice mail system use. Vendor will be responsible for installing and maintaining the voicemail operating software – including security fixes and updates.
     

145. 
     What physical connection will be established from the voicemail to the phone system? If additional voice ports are required in the future, how is the hardware/software added? Explain how the system scales beyond the number of proposed ports.
     

146. 
     Are voice messages stored in an industry standard format? How many megabytes of disk space are required for each hour of voice storage?
     

147. 
     When a backup is performed what is backed up – programming, greetings, messages? Do back-ups happen automatically and can they be directed to NAS or SAN volumes/LUNs?
     

148. 
     What, if any, limits are there to greeting, message or announcement length? What will the voice mail do if an individual mailbox is full? What will the remote caller hear? How will the user be notified and what options will the user have?
     

Voice Mail Security and Administration

149. 
     Please describe the system administration interface for the voicemail. Can the voicemail be administered through the same interface as the phone system? Does it require separate sessions? Is system administration done through a standard web-enabled GUI? If so, which browsers does the administrative application support? If not, can the application be loaded on multiple PCs?
     

150. 
     Users should be required to enter a password to access their voice mailbox. What is the minimum and maximum password length? Can it be different for different classes of users? Will the voicemail system prevent the use of trivial passwords such as sequential digits, repeating digits, and re-use of the extension number?
     

151. 
     Does the system track failed password entries in a single session and disconnect the caller? Does the system track failed password entries across multiple sessions and automatically lock the mailbox? Does the system create a log and alarms (SNMP, email, pager) based on failed log-on attempts?
     

152. 
     Describe voicemail port, disk utilization and user status reports available. Include a sample of these reports in the appendix.
     

153. 
     Unified Communications
     

Unified Messaging

154. 
     Unless already provided elsewhere, please provide a general description of your Unified Messaging offering, including where its messages are queued and stored, physical and/or logical connectivity to the telephone system, logical connectivity to Office 365 UM, logical connectivity to the email client (Outlook), server and desktop requirements, and architecture.
     

155. 
     Does the system install an email client add-in to allow for message playback and management without having to open a 3rd party media player such as Windows Media Player? Does the user have the choice to play the message through their telephone, or through their PC speakers, while still controlling the call through their email client? Provide a screen shot of the software used to control Unified Messaging.
     

156. 
     Briefly describe any advanced capabilities for text to speech playback of emails over a telephone interface, speech to text, voice control and Calendar/Task integration. Describe what upgrades are required to add these advanced features to the system you are quoting.
     

Unified Communications and Collaboration

157. 
     Unless already provided in the Critical Considerations section or Schedule C, please describe any Unified Communications functionality available with the proposed solution. Please summarize the components and software required to add desktop Presence, Instant Messaging, Collaboration, desktop video, and buddy lists through the telephone system’s native application or your recommended alternate. Vendor should state what, if any, Unified Communications functionality is provided in the base platform specifically. If possible, provide budgetary numbers for the application on a per user basis.
     

158. 
     Collaboration - Describe whether the proposed system would allow for online collaboration, screen sharing, whiteboarding, presentations, etc. (similar to WebEx or LiveMeeting). Although this functionality is not required at present, provide general overview of how this functionality can be provided in the future.
     

159. 
     Conferencing - Some phone systems include a built in conference bridge at no additional cost. These conference bridges tend to leverage existing telephony infrastructure and provide a “meet me” number that can be provided to callers to automatically bridge calls into a conference call. Some Manufacturers allow the use of passcodes, scheduled and reserved meetings, and meeting invitations, while other Manufacturers simply add each incoming caller to the bridge without the requirement for a passcode. Please describe any functionality that the quoted system will provide for this type of Meet Me Conference Bridge.
     

160. 
     Speech Recognition - What abilities does the system have for speech-activated control of a user’s voice mailbox and Outlook calendars? Please describe your ability to provide this functionality, features provided, and optional pricing models.
     

Mobility Applications (Find Me/Follow Me)

161. 
     Extend calls to Cell Phone: If not already described in another section, describe here any functionality that the system has to ring a call to a person’s cell phone and desk phone simultaneously. Will the user see the inbound caller’s Caller ID or the PBX’s Caller ID on the display of their cell phone? Does the cell phone interface allow for pressing a digit to accept the call, or are there other means to detect that the cell phone has answered the call? If the call is answered on the cell phone, how do you get the call back to the desk phone? If the call is answered on the desk phone, how do you extend the call to the cell phone?
     

162. 
     Soft Phone Dialer: Describe any functionality that allows a user to place a call from a softphone application on their computer (Windows or Mac) but instead of using VoIP through the softphone, extend the call to the user over PSTN (home phone or cell phone) before making the call to the dialed party. Provide optional pricing where indicated on Schedule A.
     

163. 
     0 out from Voicemail - Calls that go to voicemail should allow the caller to press 1 (or other button) to reach the called person on their cell phone, press 0 to reach the operator, press another button to reach their personal assistant (which might vary by extension or class or service), or leave a message. If the call is not answered on the cell phone, the call should be pulled back and a message taken in the voicemail system at Head Office. When the call is extended to the cell phone, the caller ID of the original calling party should be passed to the display of the cell phone. Please describe how you will provide the functionality requested above and a screenshot of the user interface.
     

164. 
     Smart Phone Mobile Client: Describe your smart phone mobile client, the platforms you support (e.g. Android and IOS), and its capabilities. Will it automatically extend the audio for a call over WiFi while in the office, on Cellular 4G where available, and on Cellular voice minutes where data coverage is inadequate for high quality audio? Provide optional pricing where indicated on Schedule A.
     

165. 
     Describe and provide optional pricing for any other Mobility applications, or abilities that the system can provide in order for an employee to manage where the phone system can expect to find them. Provide optional pricing where indicated on Schedule A.
     

166. 
     System Administration RequirEments
     

167. 
     The City requires a system administration tool capable of supporting all offices within the enterprise from a single intuitive user interface. Ideally, this program will allow management of the phone system, voicemail, ACD, etc. from a single unified interface. Please describe all functions and applications the administration tools can support and include screenshots for each application.
     

168. 
     The system should maintain a change log of programming changes and which administrator made the change.
     

169. 
     Vendor should include tuition or course credits to a Manufacturer recommended and certified system administration training class for two (5) City of Coronado administrators. Please describe the course syllabus, where it is offered and duration of the course.
     

System Administration Questions

170. 
     Describe the database that contains user programming information for the phone system, voicemail, and other major system components.
     

171. 
     Generally describe how the programming database might be integrated with the City’s current Active Directory, Office 365, and HR databases.
     

172. 
     Does the system support synchronization to Active Directory? If a user is added or a name change made in Active Directory, will it download to the telephony systems? If a user change is made in the phone or voicemail system, will it upload to Active Directory? Does Active Directory synchronization happen automatically, or must it be manually run? After the telephony servers recognize an addition or change from Active Directory, what additional steps must an administrator take to complete the creation of a new user in the telephone and voicemail servers? If this functionality is not included in your base pricing, please provide optional pricing where noted on Schedule A or MRC Schedule A.
     

173. 
     How is security provided to prevent unauthorized access to the administration application? Can different administrators be given individualized permission levels? Can some administrative users be defined with “view-only” permissions?
     

System Monitoring and Diagnostics

174. 
     What diagnostic tools, logs and reports are available to aid in isolating faults? Are the system’s diagnostic tools SNMP compliant?
     

175. 
     Describe the system alarms and alarm notification available from each sub-system. Will the system call home to the maintenance company; call designated City phone numbers; send out pages to pagers; send emails, etc.?
     

176. 
     Does the proposed system have the ability to monitor VoIP Quality of Service? Does this application monitor for underlying network issues (latency, jitter, packet loss) with some kind of probe or error logs? Alternatively, does it monitor actual phone calls through data provided by the telephones? If data is provided by the telephones, can it be monitored in real-time, or are the statistics sent at the end of a call? Can this data be exposed in a simple network management protocol (SNMP) management information base (MIB) for easy access with traditional network management system applications? Please provide a brief description, with screen shot, and include a full brochure in the appendix.
     

Software Upgrades and Patching

177. 
     The manufacturer must provide software updates to address security flaws in the OS and applications at no additional cost (other than labor to implement) during the warranty and maintenance period.
     

178. 
     How does your company provide future software releases? Will the system need to reboot, or can these upgrades take place in an on-line environment? Briefly describe the process for installing a software update, and reverting to a previous software load if required. Specify for each major component proposed.
     

179. 
     Is it possible to perform a software upgrade on a standby/redundant processor and then force a failover to minimize down time during a software upgrade? Is this functionality included in the base price? Can the 2^nd processor stay on the old software level in case you need to revert to the previous software level? Is a similar process is used for software upgrades performed in the geographically redundant processor?
     

180. 
     For Hosted and SaaS solutions: Describe how the City will be informed of pending software upgrades and feature enhancements changes, and any ability to forgo or delay that update. Describe how the City will be advised of additional software updates/patches/upgrades that will be made to their production environment that could potentially be service impacting. List typical update windows for performing potentially service impacting changes.
     

181. 
     Implementation Requirements
     

The entire “Implementation Requirements” section reflects the requirements of the City. Vendors should ensure that their proposal would meet the required Scope of Work in this section.

Response: Comply, Included Partial Comply, Included Optional Cost, Not Included DO NOT Comply

Installation

Please indicate your intended compliance with each of the following once you are awarded the contract. The plans and charts do not need to be created at this time.

182. 
     Responsibility - The selected Vendor is solely responsible for the complete turnkey engineering of the new telecommunications system and all interconnecting facilities.
     
183. 
     Single Point of Contact – Successful Vendor will provide a single point of contact for all installation work. The Successful Vendor shall appoint a Project Manager for the duration of the project. The Project Manager will be subject to City approval.
     
184. 
     Database / Cut Sheets Work – Successful Vendor will be responsible to perform needs analysis, station reviews, application discovery, cut sheet database discovery, cut sheet completion, and original program initializations, with City of Coronado oversight.
     
185. 
     Telco Coordination – the City or Communication Strategies will coordinate the ordering of all local and long-distance communications facilities as deemed necessary.
     
186. 
     Installation - Vendor will be responsible for placement and installation of all servers, gateways, telephones, and all other supplied hardware.
     
187. 
     Interconnection - Vendor will be responsible for interconnection of all newly supplied equipment, including patch cords, patching, cross-connecting, plugging, Telco terminations, specialty wire harnesses, Amphenol tails, toning of analog cable, any required analog station patch panels or termination blocks, and any additional cables or wires required to connect the new telephone system to the City’s house cable.
     
188. 
     Software Version - Vendor will implement the most recent and stable version of all supplied software. If the manufacturer releases a software update to fix flaws, bugs, or security during the installation timeframe the Vendor will update City of Coronado’s system at the earliest reasonable opportunity during a scheduled maintenance window. This maintenance window will be scheduled after hours for service impacting upgrades to an operational and partially deployed system at no extra cost to the City.
     
189. 
     Project Plan - A master project schedule must be created, along with a work responsibility matrix, identifying the tasks the Vendor will perform and the tasks the City is expected to perform for a successful implementation of the new system.
     
190. 
     Vendors will provide a list of all space, power, and environmental requirements for the proposed system equipment.
     

Power – All power requirements, including any special conditioning or grounding requirements.

Heat – Vendor must provide heat dissipation for proposed switch room and the recommended safe temperature operating range for the proposed system.

Rack elevation - showing the number of U, and recommended stacking of the equipment that is being proposed at Head Office, and at each location.

191. 
     The City requires that security compliance protocols be followed at all times. This may require some or all of the following:
     

Examination and certification of installed systems, programs, applications and platforms in compliance with City standards;

Testing of critical components in a proof of concept or “sandbox” environment to ensure conformance with security protocols;

Individual background checks of employees working on solution installation.

Other factors deemed necessary by City executive management or council.

Response: Comply, Included Partial Comply, Included Optional Cost, Not Included DO NOT Comply

Training

192. 
     Requirements - The successful Vendor is required to include end-user training on City premises, with classes grouped by phone type or job classification.
     

Each user should have access to a live telephone instrument during training.

Classes should not exceed 60 minutes (45 minutes preferred)

All users will require training on the new telephone system and voicemail

Operators will require training on the new attendant console(s). Training should occur away from the reception area prior to cutover. On the morning of the 1st day of service, Vendor should provide personnel to assist the receptionist, as required, for a minimum of 2 hours.

Five (5) users will require complete system administration training on all new systems implemented. Knowledge transfer should occur during the full installation cycle. In addition, administrators should be provided a full orientation on the applications and tools they will need to use.

Two to three (2-3) weeks after the initial training, Vendor should conduct 2 sessions at Head Office for Power Users showing how to use all advanced functionality.

193. 
     Training Materials - Vendor will provide a training program and soft-copy training materials for designated City personnel who will train future employees. In addition, specify what computer based training materials are available and whether they are included in the base price.
     
194. 
     Quick Reference Guide - Vendor will prepare a 1-2 page handout that shows how to use the most commonly used features of the phone system and voicemail. Handout should also be delivered in soft copy (e.g. .DOCX or PDF) form without copyright restriction.
     
195. 
     Desk-side Training – Due to other commitments, it is often difficult to get Executives to attend training classes. For this reason, please add 1 full day, or 2 half days of trainer time starting the first day of service for walk-around and desk-side training at large locations, and 1 hour of desk-side training for small locations.
     

User Acceptance Testing

196. 
     Vendor, Communications Strategies and the City will create a User Acceptance Test (UAT) plan that confirms the operation and resilience of all applications to the requirements specified in the RFP.
     
197. 
     Prior to UAT testing – Vendor will complete Unit Testing of individual solution components, as well as System Integration Testing (SIT) between various parts of the Vendor provided solution and the City network infrastructure. SIT should (at least) mirror the UAT test plan to ensure that UAT testing will be successful. Vendor will test all installed equipment to manufacturer and vendor supplied test plans and correct all defects prior to UAT.
     
198. 
     Vendor shall have lead technician and adequate support staff onsite for UAT system testing at least two (2) weeks prior to going live with the telephony cutover.
     

Cutover Coverage

Cutover of the new system should not impact users during the City’s normal working hours, or disrupt usage of the current telephone platforms. Cutovers will therefore need to be completed after hours for service-impacting events.

199. 
     For each location cutover, it is expected that the lead engineer will physically attend onsite, and project manager will personally coordinate remediation onsite, until all reasonable punch-list items are resolved.
     
200. 
     For the cutover, Vendor shall provide at least one onsite Lead Engineer to provide programming and at least two onsite trained technicians to provide floating trouble resolution for two (2) 8-hour days beginning with the first day in service. After that, at least one trained technician shall continue to provide onsite trouble resolution until all reasonable punch-list items are resolved.
     
201. 
     Vendor shall provide at least one onsite Project Manager for each cutover for trouble ticket prioritization, desk-side training, and overall coordination for 1 x 8 hour day beginning with the first day in service.
     
202. 
     After reasonable punchlist items are resolved, additional issues will be moved to an exception list and will be tracked by Vendor with an action plan, responsible person, and deadline for completion. Vendor will provide daily updates on the remaining exception list items.
     
203. 
     State intended compliance with the requirements stated above.
     

System Acceptance

System acceptance will be defined as follows:

All equipment delivered and installed.

All training completed

All installation issues resolved to the City‘s satisfaction

All advanced features and software installed and tested, but not necessarily deployed

Documentation representing the system “As Builts” is delivered and reviewed with City of Coronado

The City may agree to system acceptance with an acceptable exception list
The City expects that they will move from installation support to warranty/maintenance support only upon execution of a Delivery and Acceptance agreement that records system acceptance. Please define if Vendor has a different requirement for the beginning of the warranty/maintenance period.

Response: Comply, Included Partial Comply, Included Optional Cost, Not Included DO NOT Comply

204. 
     Warranty, Maintenance and Support
     

205. 
     ALL hardware, software, and installation labor provided by the Vendor or Manufacturer should be covered by a 1-year parts and labor replacement warranty or first year maintenance plan, including onsite support if required.
     

206. 
     As most of the critical components of the system being quoted will be redundant and/or resilient, the City will only require 8x5xNBD support in order to minimize ongoing yearly expenses. This means that service and support will be provided at no additional cost during business hours Monday to Friday Pacific Standard Time, and that any replacement equipment will be delivered by the next business day. Maintenance/Warranty should be provided on all core Telephone System hardware and software and hosted services, including:
     

Voicemail/Auto Attendant servers and applications

Remote Site Survivable servers/gateways

Unified Communication Servers

e911 servers

Voice gateways which terminate PRIs or SIP trunks