Comprehensive RFP Template - VOIP Products and Services
This document is intended to be a forward-looking RFP/RFI (request for proposal/information) aid for large enterprises seeking to apply “future-proof” thinking to their next major communications system procurement.
ARCHITECTURE
Capacity
In 400 words or less, describe the capacity of your call controller, or controllers, in terms of handling from 500 to 5,000 IP endpoints. Be sure to indicate:
1. Platform: Processor(s), speed, operating system; do you sell this as software, or hardware/software (i.e., a pre-packaged appliance)?
2. Protocol: On what call-control protocol is this capacity based?
3. Are there different call controller models for handling 500 to 5,000 endpoints?
4. What is required to grow beyond 5,000 endpoints?
5. What is the capacity limit of the call controller to provide a single-system image across all locations and users?
6. What is the controller’s IP network interface (i.e., 10/100, gigabit)?
7. BHCA (busy hour call attempts); how was this tested and by whom?
8. If all available features are enabled for all endpoints, does this diminish the claimed BHCA capacity, or the number of concurrent endpoints supported?
Capacity—Enter response here:
Scalability
In 200 words or less, describe the scalability of your call control equipment, in terms of range of models, growth and expansion. Be sure to address:
1. The options available if adding branches, remote locations or endpoints to the existing, centrally controlled network, increasing total endpoints by 25%.
2. Whether call controllers can be added, aggregated, or “clustered” in an expandable, load-sharing manner.
3. The procedure, and extent of disruption and downtime, in upgrading call control hardware from one capacity level to the next, in both single-controller and hot-standby-controller environments.
Scalability—Enter response here:
Survivable central-site call control
In 200 words or less, describe the capability for making a centrally call-controlled network highly survivable. Be sure to address:
1. The options for hot-standby, redundant call-control. How far apart can such tightly coupled, redundant call controllers be?
2. The extent to which hardware redundancy (dual processors, redundant fans, NICs, etc.) enhance uptime. What MTBFs do you project?
3. Can an off-site, “stand-by” back-up call controller be set-up and configured to take over a large network automatically in the event of a central-site disaster?
4. Can two or more call controllers be locally aggregated or “clustered” to provide load-shared, fail-over call control?
Survivable central-site call control—Enter response here:
Distributed support—multiple systems (discrete call controllers)
In 200 words or less, describe the extent to which multiple “systems,” each with its own central call control, can be networked. Be sure to address:
1. The trunk mechanisms and protocols that are supported (T1/E1, PRI, Q.Sig, proprietary TDM-based, proprietary IP Trunk, SIP Trunk, other)
2. Feature transparency across such networked systems, over these different trunks, including abbreviated dialing and routing plans.
3. Up to how many total discrete systems, and up to how many total endpoints, can be networked via trunks, and what is the limiting factor?
4. What is your largest multi-system network now operating, in terms of number of interconnected systems, total endpoints, and types of trunks used?
Distributed support, multiple systems (call controllers)—Enter response here:
Distributed support—central call control, many branches
In 150 words or less, describe the extent to which your system, with centralized call control, can support multiple branches and offices. Be sure to address:
1. How many branches can practically be supported in an expanded system with central call control? What is the most branches or distributed locations you now support in a centrally controlled system?
2. How do you routinely distribute software updates (i.e., phone firmware versions) in a large distributed network?
3. What link requirements are needed to central call control, in terms of distance, bandwidth, QoS and latency, for a 5-endpoint, 50-endpoint and 500-endpoint branch?
Distributed support—central control, many branches—Enter response here:
Distributed/branch survivability
In 150 words or less, describe the mechanisms and options you offer for branch office survivability and IP-communications continuance, if connectivity with central-site call control is interrupted, intermittent or lost. Be sure to address:
1. Briefly list and compare branch-office options and their comparative costs for assuring branch office call continuity.
2. If call control reverts to a local controller, what features are lost? (Calls in progress? Last number redial? Abbreviated dialing? Conferencing? Directory access?)
3. What options are offered for “power-fail” connection, transfer? (Connectivity to PSTN, reversion to analog POTS if power fails)
Distributed/branch survivability—Enter response here:
Traffic control, bandwidth, CAC (Call Admission Control)
In 150 words or less, list and describe the mechanisms or protocols you support for bandwidth efficiency and traffic optimization. Be sure to address:
1. Can the system automatically determine and apply a low-bit-rate vocoder to all “remote” calls, while using a high-quality vocoder to ample-bandwidth “local” calls? If so, how does the user set-up and control this (by link, by IP subnet, by “region,” etc.)?
2. Is CAC supported? That is, can the user limit or otherwise control the max number of concurrent calls by remote link or between WAN-connected remote locations? Alternately, can the user allocate the maximum bandwidth for VoIP by link? If so, what protocol or control mechanism is used?
3. Is VAD (voice activity detection) or silence suppression supported? If so, on which codecs?
Traffic control, bandwidth, Call Admission Control—Enter response here:
QoS, VLANs
In 150 words or less, list and describe the mechanisms and options the system supports for prioritizing the transport of real-time IP communications. Be sure to address:
1. Which of these QoS options are supported: TOS, DiffServe, or any other transport-control protocol (such as RSVP, the resource reservation protocol)?
2. Are these QoS or access-control parameters or mechanisms settable on a per-phone basis, by region, on links between regions, or system-wide?
3. Can IP communications packets generated within this system be tagged for specific VLANs?
QoS, VLANs—Enter response here:
IM, video connection set-up
In 150 words or less, briefly describe how Instant Messaging and Videoconferencing connections are set-up within your system. Be sure to address:
1. What impact, if any, do high volumes of multimedia connections (such as IM and video) have on the capacity of call control for voice?
2. Can a user readily “escalate” from an IM session to a VoIP call? To launch a video connection from an established VoIP call (between appropriately equipped endpoints)? To concurrently maintain IM, video and VoIP connections with the same or different parties?
Multimedia connection control is also addressed in Item E1, “Multimedia Call Control.”
IM, video connection set-up—Enter response here:
Teleworker support
In 150 words or less, briefly describe any special hard or softphone options or connection arrangements your system supports for teleworkers. These might include:
1. Any special phone sets or telephony arrangement, supporting such features as automatic VoIP fail-over to POTS.
2. Capabilities for automatic VPN tunnel set-up or other secure access.
3. Ability to work via IP on a soft phone or other PC/laptop application, while using an “associated” IP or analog/POTS hard phone for audio.
Teleworker support—Enter response here:
Extensibility and application integration
In 150 words or less, briefly describe the system’s support for programmatic extensions to facilitate application integration or interoperability. Be sure to address:
1. API and SDK offerings.
2. Support for a Service Oriented Architecture (SOA).
Extensibility, customization—Enter response here:
ENDPOINTS
IP Hard phones
In the below table, list your IP hard phone models and provide these comparative data elements (add lines to the table for additional IP Hard phone models):
IP Hard phone model no.
Call-control protocol
No. buttons
No. line appearances
Display size, pixels, color
Soft-key support?
Includes speaker-phone
No., type network interface(s)
Headset options (Blue-Tooth?)
US list price ($)
MOBILITY
Dual-mode
In 200 words or less, list and briefly describe your system’s support for any “dual-mode” phones—handheld telephony endpoints that support both cellular and WiFi technologies. Be sure to address:
1. What phone technology (GSM, etc.), and what 802.11 modes (802.11a, b, g, n) are supported. What specific cellular/mobile services support this?
2. What capabilities, beyond basic voice telephony, the dual-mode phone adds.
3. How the dual-mode phone transitions from cellular-to-WiFi environments, and from WiFi-to-cellular environments. Is switch-over manual or automatic? Are connected calls retained in the transition? Without perceptible interruption?
Dual-mode—Enter response here:
Client applications for mobile, cell and feature phones
Item B4 in the previous “Endpoints” section asks about software client offerings for mobile platforms, including cellular feature phones.
Refer to the response in item below “Endpoints” section on “Mobile clients”.
Mobility feature package (fixed/mobile hand-off, bridging, transfer)
In 200 words or less, list and briefly describe any special applications, routing or feature packages offered with your system, whether integral or extra-priced, which tie (bridge) regular cell phones and/or analog phones (i.e., home phones) in with system (office, desktop) phones, providing connectivity and system access for mobile clients. Be sure to address:
1. The fixed/mobile hand-off process (i.e., single click)
2. Whether user’s voicemail support also transfers to the mobile phone.
3. Other transferred capabilities (i.e., hands-free dial-by-name, etc.)
Mobility feature package—Enter response here:
Free-desking, hoteling
In 200 words or less, briefly describe your system’s support for client moves within the same system, whether temporary or permanent. Be sure to indicate:
1. Whether a user can take his/her IP Hard phone to a different location (on the same call-control system), plug it into an available LAN port, and operate with all the same features and authorizations as in the previous location. Is system admin involved? What else does the user have to do (i.e., PIN log-in)?
2. Whether a user can go to any IP Hard phone on the system, log-in, and operate with all the same features and authorizations as on his/her own phone. What if the phone model is different? Is system admin involved?
3. After log-in, are user’s call logs available?
4. Do either of the above features, if supported, work transparently across distributed systems (discrete systems, each with its own call control, networked via trunks)?
Free-desking, hoteling—Enter response here:
STANDARDS AND OPENNESS
SIP, other call control
In 150 words or less, answer these questions about your system’s support for SIP and other call-control protocols.
1. Does your system support SIP as a call-control protocol?
2. Is SIP the “native” call-control protocol; that is, are all IP calls set-up and features invoked and delivered via SIP, “out of the box” and without any extra costs?
3. What additional call-control protocols are supported by the system, and to what extent? (i.e., MGCP for gateway control, proprietary H.323 can run in a dual-stack mode for backward compatibility, etc.)
SIP, other call control—Enter response here:
Support of third party phones and endpoints
In the below table, list and briefly detail all third-party phones and endpoints—including softphones, conference speakerphones, video phones, WiFi phones, etc.)—supported by your system.
Vendor and phone/ endpoint model(s)
Brief description (i.e., softphone, conference speakerphone, etc)
Call-control protocol
Approx no. telephony features
Resold by you?
Interop certified by you?
Microsoft interoperability
In 200 words or less, describe your system’s support of, and ability to interoperate with, current Microsoft servers and/or clients. Be sure to address:
1. Microsoft LCS and/or the newer OCS. Can your system receive VoIP calls from and/or place calls to, MS LCS or OCS-based systems? If so, is interoperability between systems SIP based on ECMA TR/87 ("SIP CTI,” as adopted by Microsoft)?
2. Do you offer any support for the MS Office Communicator client? If so, do you offer a software module that integrates with Office Communicator?
3. Please briefly describe any other Microsoft-specific integration or interoperability you support (i.e., integration of your voicemail with MS Exchange email store, for Unified Messaging, etc.)
Microsoft interoperability—Enter response here:
Interoperability with other third-party applications, servers
In 300 words or less, list and briefly describe any third-party applications packages and/or applications servers that interoperate with your system. Be sure to address:
1. Vendor and package name, brief description (i.e., Contact Center, Unified Messaging system, videoconferencing server, conferencing server, etc.)
2. Control protocol used between your system and theirs.
3. Does the package or server rely on your system for basic call control? For any other basic or advanced features?
4. What other “open” standards—including for example, XML and SOA—are inherent to your system, and facilitate third-party interoperability.
5. Was interoperability with your system the result of joint development with you, or was the package certified by you as interoperable?
Interop with other third-party applications, servers—Enter response here:
Gateways
In 200 words or less, list and briefly describe any gateways you offer for use with your system, including:
* VoIP-to-PSTN gateways,
* Protocol gateways (i.e., for support of H.323-based equipment, etc.).
Specify for each the control protocol used (i.e., SIP, MGCP), and whether you co-developed or certified interoperability of the gateway for use with your system.
Gateways—Enter response here:
SIP trunking
In 150 words or less, briefly describe your system’s support for SIP-based IP trunking by your system. Be sure to address:
1. Whether and to what extent SIP trunking is used internally, for interconnection of your various system components (i.e., call control to voicemail, call control to conferencing server).
2. List any carrier/service provider, and the service name (i.e., Verizon Business, AT&T FlexReach) with which your system interoperates via SIP trunk.
3. Whether the SIP trunking is based on the SIP Forum specs.
SIP trunking—Enter response here:
Certification program
In 200 words or less, briefly describe any formal program of interoperability testing you run or sponsor, so that third-party products can be certified for use with your system . Be sure to address:
1. Is this testing designed primarily for third-party SIP endpoints (including gateways)?
2. What results of this testing are published, in terms of test plan, features tested/validated, products and versions certified, and costs?
3. Is participation in this program open to any third-party, or do you need to approve applicants seeking interop testing via this program?
Certification program—Enter response here:
Proprietary vs Standard SIP Features
In 200 words or less, if your system supports SIP, briefly answer these questions regarding your system’s feature support via SIP:
1. Overall, in total, about how many total “telephony” and other features are supported in your system via SIP?
2. Roughly what percent of these do you estimate are directly based on published SIP-related RFCs?
3. Roughly what percent of these do you estimate are based on other published SIP-related specifications (from all sources: Internet Drafts, other drafts, and including SIP Forum, ECMA, etc.)?
4. Roughly what percent of these would you say are based on proprietary SIP headers, “feature codes” or other encapsulation in SIP-compliant message formats?
Proprietary vs Standard SIP Features—Enter response here:
Other standards support
In 150 words or less, list and briefly describe any other international or industry standards you support, or standards directions your company embraces or follows. Be sure to address:
1. Specific standards you support, beyond those already discussed, and how this benefits the customer.
2. Standard architectures you embrace—SOA, ITIL, etc.—and how this benefits the customer.
3. Your company’s active role(s) in relevant standards bodies.
Other standards support—Enter response here:
MULTIMEDIA AND PRESENCE SUPPORT
Multimedia call resources
In 250 words or less, briefly describe what call-control resources (i.e., SIP call controller, or other server(s)) within your system, and what protocols, are involved with:
1. Instant Messaging connections, if supported.
2. Videoconferencing connections, if supported
3. Web-based collaboration, if supported.
4. Collection, maintenance and distribution of presence status information, if supported.
Multimedia call resources—Enter response here:
Video, MCUs
In 150 words or less, briefly describe your system’s videoconferencing support, in regards to these questions:
1. Is multipoint videoconferencing supported? If so, is video-stream mixing done by an MCU or in (videoconferencing server) software?
2. What video MCUs do you offer or support (i.e., models, and vendor, if not you). How many “Hollywood Squares” streams can be mixed and displayed per videoconference? What (additional) client software is involved?
3. What protocol(s)—i.e., H.264—are supported as far video bandwidth (frames per second, etc.), and how are these settings changed.
Feel free to add screen shots and additional info in an appendix labeled “Video.”
Video, MCUs—Enter response here:
Instant Messaging (IM)
In 250 words or less, briefly describe your system’s support for Instant Messaging (IM). Be sure to address:
1. What is required for IM support (as far as client software, server, UC application suite, etc.)? Can your IP Hard phones partake in IM?
2. Does your IM environment interoperate with any of the following?
* AOL, MSN or any other “public” IM service?
* Lotus Sametime?
* Microsoft Office Communications Server?
* XMPP-based systems?
3. Is your IM environment secure via encryption?
4. Briefly describe IM message storage capabilities and features.
Instant Messaging (IM)—Enter response here:
Web conferencing, collaboration
In 250 words or less, briefly describe your system’s support for Web conferencing and collaboration. Be sure to address:
1. What is required for endpoints to participate in your Web-based conferencing and collaboration (client software, server and application suite, etc.)?
2. Does your package support desktop sharing? Distribution of Web-based presentations? Joint viewing, editing of Web-based materials?
3. How are Web-based collaboration sessions secured?
4. What other Web-based collaboration tools are supported (i.e., Whiteboard, polling, IM side-chats, etc.)?
Feel free to add screen shots and additional info in an appendix labeled “Web collaboration.”
Web conferencing, collaboration—Enter response here:
Presence
In 250 words or less, briefly describe your system’s support for presence, and be sure to address:
1. What is required in your system for the collection and distribution of presence status information?
2. What clients and endpoints can present the presence status of others?
3. Please list all the presence states your system supports and propagates.
4. Are individual and group presence capabilities supported?
5. Whether and which other applications can change one’s presence status?
Presence—Enter response here:
BASIC FEATURES AND SUBSYSTEMS
Basic dozen phone features
Are all of these “basic dozen” telephony features supported by all your IP endpoints?
* 3-party conferencing
* Call hold
* Last-number redial
* Caller ID
* Speed-dial
* Call park & retrieve
* Call forward/forward all
* Call transfer
* Missed-call/message indicator
* Mute
* Do not Disturb
* Multi-line appearances/group pickup
Please provide a complete list of your supported features in a “Features” appendix.
Basic dozen phone features—Enter response here:
Hunt groups, call routing
In 250 words or less, briefly describe your system’s call routing options, and whether the user can define hunt groups (associated phones for call coverage). Be sure to address:
1. Whether “least-cost” or user-prioritized routing (alternate route selection) is supported.
2. Whether the system can dynamically re-route calls based on:
* loss of IP connectivity on a particular route, and/or
* degraded QoS conditions, based on ongoing QoS monitoring.
3. Whether “personal call routing” or” find-me/follow-me,” is supported, allowing individual users to set and change their call-routing preferences.
Hunt groups, call routing—Enter response here:
Auto-attendant
In 150 words or less, briefly describe your system’s auto-attendant capabilities, including: voice-announcement capacity and capability; and scope of caller routing based on voice-prompt/DTMF-response.
Auto-attendant—Enter response here:
Voicemail
In 250 words or less, briefly describe your system’s voicemail subsystem(s). Be sure to address:
1. How the call-control system connects to the voicemail subsystem (i.e., SIP trunk, AMIS, other).
2. Voice capacity—user accounts and storage capacity.
3. Scalability of voice mail system for growth.
4. What mechanisms are available to make voicemail survivable or redundant; can multiple voicemail systems be synchronized or made hot-failover survivavble.
5. How voicemail is secured—storage, access and transport.
Voicemail—Enter response here:
Unified Messaging (UM)
In 250 words or less, briefly describe your system’s support for Unified Messaging—the integration of voicemail and email. Be sure to address:
1. With what specific email stores (email server repositories—i.e., Lotus Domino, MS Exchange) can your voicemail system integrate?
2. What vocoder is used by your UM? How large (Mbytes) is a one-minute message? And can this be adjusted?
3. Does your UM entail a “plug-in” (such as a “player” application and toolbar icon) on users’ desktop email interface (i.e., MS Outlook, Notes, etc.)?
4. Can the user set the conditions for deletion of voicemail (i.e., when UM voicemail is played and deleted).
Unified Messaging (UM)—Enter response here:
Management interface(s)
In 250 words or less, briefly describe your system’s user interface to:
1. The application(s) where users, voicemail accounts, endpoints and key assignment, are defined and changed.
2. Note whether management access can be partitioned to support a role-based .management structure, or multi-tenant environments.
3. For a large network (1,000+ stations), how many discrete management appli-cations are offered, integral and optional/extra-priced, each with its own user interface?
4. Are there any aspects of your system’s management that entail a command-line interface?
Feel free to append screen shots and additional details in a “Management” appendix.
Management Interface(s)—Enter response here:
Call quality, real-time monitoring, diagnostics & troubleshooting
In 250 words or less, briefly describe your system’s management capabilities, with regards to:
1. The ability to assess and see reports on VoIP call quality, on a per-call, per-user, per-link/route and/or per-region basis, showing MOS-type or R-factor results.
2. The ability to monitor, in real-time, the operational state of: an end-user’s phone and connectivity, trunk usage (IP or TDM), and the fail-over state of key, redundantly configured nodes (gateways, call controller, etc.).
3. The availability of any tools you offer to help the user investigate and resolve problems such as: long post-dial delays, poor voice quality, dropped calls.
Feel free to append screen shots and additional details in a “Management” appendix.
Call quality, monitoring, diagnostics & troubleshooting—Enter response here:
Moves, adds, changes
In 200 words or less, briefly describe your system’s management capabilities, with regards to entering/reconciling user moves, adds and changes. In particular note:
1. The number of steps—screens, clicks, data entry elements—required to add a new user to the system.
2. Whether set-up of a user’s phone is on the same screen, or within the same application, as set-up of that user’s voicemail.
3. How administration of softphones is different from IP hard phones.
4. What central-site admin is needed, if any, when a user gets promoted, moves to a different office, and gets a different IP Hard phone set model.
Feel free to append screen shots and additional details in a “Management” appendix.
Moves, adds, changes—Enter response here:
Reports
In 200 words or less, briefly summarize the scope and value of reports your management subsystem offers to an administrator. Note in particular:
1. The process for producing a call-detail summary report for calls in the last hour.
2. The ability of the administrator to devise his/her own recurring report, showing, say, call volume by time of day.
3. The availability of any reports, or inherent report-generation tools, that show voice quality (MOS) by user, by local vs remote calls, and by time of day.
Feel free to append screen shots and additional details in a “Management” appendix.
Reports—Enter response here:
Software and firmware upgrades
In 150 words or less, briefly describe the process involved with your system for an administrator to distribute a new firmware load to all IP hard phones. Note in particular:
1. Whether the current firmware load in all phones can be readily determined
2. Whether firmware upgrade can be launched for all phones at one time.
3. Whether upgrades can be performed when phones are not in use.
Software and firmware upgrades—Enter response here:
Multi-language support
In 150 words or less, summarize your system’s support for different languages, with regards to:
1. Languages available for words displayed on phones.
2. Languages supported in on-line documentation and in management interfaces.
3. Languages supported in voice-prompts in auto-attendant.
Multi-language support—Enter response here:
User set-up support, documentation
In 150 words or less, describe pre- and post-cutover user help methods, for facilitating installation and set-up. Be sure to include:
1. Soft-copy and hardcopy documentation.
2. On-line support menus, installation wizards.
User set-up support, documentation—Enter response here:
ADD-ON OPTIONS AND SUBSYSTEMS
Voice Recognition (ASR), Text-to-Speech (TTS)
In 200 words or less, summarize the options and subsystems you offer that employ advanced speech technologies, including:
1. Voice Recognition (ASR, or automatic speech recognition) subsystem to voice-enable (front-end) auto-attendant, directory, conference set-up, and so on.
2. Text-To-Speech (TTS), such as for voice read-out of email.
3. For ASR, what different languages are supported? And for TTS, what text languages can be auto-detected and then read-out?
Voice Recognition (ASR), Text-to-Speech (TTS)—Enter response here:
Contact Center(s)
In 400 words or less, summarize the Contact Center options and subsystems you offer. Be sure to address:
1. Different Call Center offerings and system capacities.
2. Multimedia support, groups- and skills-based routing.
3. Call-back and outbound ("dialer") support.
4. How Contact Center call processing is handled. Is it integrated with the Contact Center? How does it network with the system call control?.
5. Agent desktop capabilities, including integrated presence, collaboration.
6. Reporting capabilities; can reports be customized?
7. Admin/supervisor capabilities.
8. System extension, customization; is an SDK offered?
Contact Center(s)—Enter response here:
Third-party Programmatic Access, APIs, SDK
In 150 words or less, briefly describe your offerings to aid user and third-party programmatic access to your system for customization. Be sure to address:
1. The use of such open standards as XML/SOAP and SOA (service oriented architecture).
2. The system features and functions exposed via APIs and your SDK.
Third-party Programmatic Access, APIs, SDK—Enter response here:
911/E911 Subsystem
In 250 words or less, briefly describe the inherent and optional features in your system for tracking user calls to 911, and reporting those caller’s locations to the 911 PSAP. Be sure to address:
1. How location of caller is determined, maintained and reported.
2. Whether you offer any special add-on subsystem(s) for maintaining phone/caller location information, which can be applied to E911 reporting.
911/E911 Subsystem—Enter response here:
Unified Communications
In 300 words or less, briefly describe your support of “Unified Communications"—typically an application suite and server that provides desktop/laptop users with advanced and multimedia communications capabilities. Be sure to address:
1. Which of these capabilities are provided as part of this package?
* Softphone/soft client
* Audio conferencing
* Web collaboration
* Desktop sharing
* Scheduling
* Whiteboarding
* Instant Messaging
* Video conferencing
* Presence (group, individual)
* Call logs, click to call
* Buddy lists, contact lists, workgroups
* Personal routing (i.e., Find-Me/Follow-Me)
* Other “unified communications” features or capabilities (specify).
2. Client access—what clients are supported (Windows PCs, Macs, other), and is access via “thick” client (PC-resident software) or “thin” (Web-based)?
3. How “integrated” are these tools and capabilities? Which of these are accessed via a single user interface?
Unified Communications—Enter response here:
Other Add-On, Extra-Priced Options, Subsystems
In 150 words or less, list and briefly describe any other noteworthy optional or extra-priced add-ons or subsystems you offer, not already identified or discussed, including resold packages from third-parties, which you believe contribute to the value of your system.
Other Add-On, Extra-Priced Options, Subsystems—Enter response here:
SECURITY
Firewall, SBC offering(s)
In 150 words or less, list and briefly describe any special security products, appliances or packages you offer, re-sell or support for use with your system, which enhance security for VoIP connectivity to, and through, the Internet. Be sure to detail:
1. Firewall product or system you sell, endorse or support. If so, how much delay is added to VoIP packets (RTP) traversing the firewall.
2. Session border controller (SBC) system you sell, endorse or support, for VoIP interconnection and traversal with carriers/service providers, or other enterprises.
Firewall, SBC offering(s)—Enter response here:
Secure Teleworker / Road Warrior Access
In 150 words or less, list and briefly describe any special network access control (NAC) arrangement, products, appliances or packages you offer, designed to secure access to communications services by teleworkers and/or road warriors. Be sure to address:
1. What security mechanisms are applied or supported (i.e., VPNs, passwords, VoIP stream encryption, etc.), and traffic types supported (i.e., IM, VoIP, Video, etc.)
2. Capacity, in terms of number of concurrently connected teleworkers/road warriors supported).
Secure Teleworker / Road Warrior Access—Enter response here:
Call Controller Security
In 150 words or less, list and briefly describe measures implemented in your call-controller architecture to safeguard against malicious assault.
Call Controller Security—Enter response here:
Device/Endpoint Authentication
In 150 words or less, describe the mechanisms inherent in your system and architecture for precluding unauthorized—and possibly malicious—endpoint device connection to your system. Be sure to address: What security mechanisms (i.e., MD5 message authentication) prevent a malicious attacker from sniffing and then emulating a legitimate endpoint?
Device/Endpoint Authentication—Enter response here:
User/Caller Authentication
In 150 words or less, describe the mechanisms inherent in your system and architecture for assuring that users and in-house callers are legitimate and authorized. Be sure to address:
1. In a highly secure environment, can a caller’s PIN or password/log-in be required daily? Per call? What PIN or password length is required/supported?
2. How does user authentication vary in your system between: IP Hard phone users; softphone users; WiFi callers?
User/Caller Authentication—Enter response here:
Call control security
In 150 words or less, describe the mechanisms inherent in your system and architecture for assuring the integrity of call control information. Be sure to address:
1. If SIP is supported, whether TLS (transport layer security) encryption is supported for call-control security.
2. For other than SIP, describe how call-control information is safeguarded in your environment. Is call-control information encrypted?
Call control security—Enter response here:
Eavesdrop protection, Secure RTP
In 150 words or less, describe the mechanisms inherent in your system and architecture for assuring that VoIP content between callers is secure and not intercepted. Be sure to address:
1. Whether secure RTP (sRTP) is supported for calls to and from your IP endpoints. If so, is sRTP supported by your softphone, too? Is this encryption supported between endpoints and VoIP gateways?
2. For other than SIP, describe how call-control information is secured in your environment. Is call-control information encrypted?
Eavesdrop protection, Secure RTP—Enter response here:
Administrator, Management Access
In 150 words or less, describe the architecture of your main management application(s) with regards to protecting management data and assuring authorized-only access. Be sure to address:
1. Whether remote management sessions are secured (such as via ssh—secure shell—or SSL/secure HTTP encryption), and not via unsecured HTTP.
2. Whether administrator access is password protected. Do sessions automatically timeout due to inactivity? Are multiple levels of administrator access supported, allowing role-based access to only pre-specified areas of system management?
Administrator, Management Access—Enter response here:
PRODUCTIVITY ENHANCEMENT
Enhancements with Workgroup Conferencing
In 150 words or less, detail quantifiable examples of how you believe your workgroup conferencing features can yield legitimate productivity gains to participants, either workgroup members or chairpersons. Try to quantify gains in terms of time saved or other demonstrable or estimated improvements in efficiency or productivity. Be sure to address:
1. Productivity gains through your audio conferencing capabilities (i.e., drag-and-drop, ad-hoc conference set-up, ad hoc versus scheduled conferences, etc.).
2. Productivity gains through your Web-based and/or multimedia conferencing capabilities (i.e., real-time whiteboarding saves on fax and email turnaround; group editing of documents in real-time reduces individual turnarounds by two-thirds, etc.).
Enhancements with Workgroup Conferencing—Enter response here:
Enhancements with Telephony Operations
In 150 words or less, detail quantifiable examples of how you believe your system can yield legitimate productivity gains to end users in their normal telephony operations. Try to quantify gains in terms of time saved or other demonstrable or estimated improvements in efficiency or productivity. Be sure to address:
1. Special applications, such as “visual voicemail,” directory search, and innovative features including “presence.”
2. Additional aspects of your base telephony system, such as LDAP integration, simplified phone interface, etc.
Enhancements with Telephony Operations—Enter response here:
Enhancements via Desktop Applications, Integration
In 300 words or less, detail quantifiable examples of how you believe your advanced desktop application offerings, including Unified Communications system, can yield legitimate productivity gains to end users. Try to quantify gains in terms of time saved or other demonstrable or estimated improvements in efficiency or productivity.
Examples that you may want to quantify might include:
* Call logs
* Click-to-call
* Video
* Secure IM
* Directory search
* Contacts
* Web access to personal settings
* Find-Me/Follow-Me
* Tell me when (camp)
Enhancements via Desktop Applications, Integration—Enter response here:
Other Productivity Enhancement
In 150 words or less, detail any other quantifiable examples of how you believe your system can yield legitimate productivity gains to end users, beyond the areas already addressed. Try to quantify gains in terms of time saved or other demonstrable or estimated improvements in efficiency or productivity.
Other Productivity Enhancement—Enter response here:
COST MODEL
In this cost model, the user of this RFP/RFI template needs to detail their requirements in each of the following nine areas.
An enterprise might specify several different types of sites (regional sites, branch offices, etc.), each with different numbers and mixes of endpoints, call control and redundancy requirements. User and management applications also need to be specified, as these are often extra-priced, and increasingly expensive, options today. The user needs to be clear about the level of redundancy and failover required, on a site-by-site basis, since overall costs can dramatically increase in highly redundant environments.
The customer needs to decide whether call control will be centralized or distributed—most enterprises deploy centralized call control, but with failover capability. Specific requirements for local survivability (local call control at a small site or branch) need to be made clear. Voicemail needs to be similarly specified—centralized, distributed, redundant, locally survivable, etc.
The vendor should be asked to provide realistic “street prices,” with appropriate discounts applied, in their responses to this RFP/RFI. Below are the nine areas that the customer needs to delineate to the vendor, in order to solicit a reasonable price quote.
In addition to vendor responses to the following nine cost components, the user of this RFP/RFI may also invite the vendor to submit a “brief” narrative of the proposed solution, including a solution diagram.
Call capacity
We recommend you specify a BHCA based on every station placing or receiving a call once a minute (in other words, a BHCA of 60,000 would be specified for 1,000 endpoints). Note that this is a very high projection, perhaps double the worst-case call load that might actually occur.
Any redundancy considerations assume that the survivable unit can handle the full load of the failed unit.
Customer requirements:
The capacity requirements should indicate whether a centralized or distributed call design is planned. For sites requiring survivable call control (sizeable branches), indicate call capacity requirements for “locally” survivable call control.
Vendor’s response:
In your response to this cost model, include the capacity of call control specified above, including distributed “local control” back-up.
Number and type of endpoints
Customer requirements:
Indicate the counts of the various endpoints required for all sites in the enterprise design. The customer should consider expected growth over the next few years. Be sure to specify percent of total endpoints that will be softphones, including soft attendant consoles (generally 20 percent or less), and the number of endpoints that will be higher-end IP Hard phones (also generally 20 percent or less). The remainder will tend to be mid-range IP Hard phones.
Be sure to also specify 802.3af Power-over-Ethernet (PoE) equipment, if appropriate.
Vendor’s response:
Indicate the costs for the above specified endpoints, specifically addressing the counts for all the phones and various types specifies above (Hard phones, softphones, attendant consoles).
Number of call controllers and level of failover/survivability
Customer requirements:
The user (issuer of this RFP/RFI) needs to clearly specify the desired levels of redundancy and survivability for each site. Keep in mind the cost for survivable equipment can vary substantially depending on the level of “feature and operational transparency” at the headquarters and distributed sites—addressing the case where the IP-WAN connection to centralized call controller fails. Assuring full feature transparency (i.e., maintaining 5-digit enterprise dialing and all features) tends to be fairly expensive. Maintaining just a “basic” feature set in survivable mode tends to be much more affordable.
Vendor’s response:
Indicate the appropriate costs for your equipment and facilities (hardware and/or software) that will provide the customer’s specified level of redundancy and survivability for all sites. The vendor may wish to add information for more extensive feature sets in survivability mode, which allows the customer to choose the solution best suited for the enterprise environment.
If multiple survivability solutions can address the customer’s design requirements, the vendor should describe them and outline their comparative costs. A brief description of the pros and cons of the solutions should also be described.
Number and capacity of gateways
Customer requirements:
Detail your requirements for gateways at each site. Note that, as long as there is sufficient IP bandwidth to a central (or regional) site, gateways may not be needed at small offices and branches (all PSTN calls are routed back to the central (or regional) site’s gateways).
The customer should consider the number of trunk circuits (whether T1 PRI, or FXO), that will satisfy the requirements for each site. As a very general rule, one PSTN trunk circuit is provisioned per every four stations, but that may be very inadequate in some environments (such as call centrals and many financial services). In many cases gateways may also participate with local-site survivable call control if the connection to the centralized call controller fails. In some cases locally survivable call control is integrated into the gateway, but is still a separately priced option.
Vendor’s response:
Indicate the costs for the gateways specified. The gateway models and capacity you quote should be consistent with the customer’s design and above specification. (Please also indicate the overall station-to-trunk ratio you have specified.)
Indicate costs for any additional units, modules or electronics cards needed in smaller or distributed sites to provide the specified survivability capabilities. Note that some of these gateways may not be used for local PSTN access in normal operational mode.
Also, indicate costs for emergency or power outage transfer/relay equipment (modules, cards, etc.) that can connect a (usually analog) phone to a PSTN trunk circuit in the event the IP-telephony system at the site loses power.
Management wares
Basic configuration management software is likely to be provided at no extra cost with the IP communications system. But increasingly, additional useful management capabilities are provided by applications and packages that are extra-priced.
Customer requirements:
If management software to monitor the performance of VoIP call quality is needed, this should be indicated. The vendor may or may not offer equipment and software, or may quote a third-party package. Similarly, some “canned” management reports may be included with the system, but there is often an extra-priced package for expanded reporting.
Vendor’s response:
Specify the cost of any additional, extra-priced tools you offer for monitoring QoS and call quality, and for creating management reports.
Indicate costs for the management applications described in the above customer requirements. Indicate, too, what additional hardware may be required. The license quantities should be appropriate for the specified network size and topology.
Service and support, including implementation services
Customer requirements:
The customer should determine the desired level of service and support. This can add 12 to 15 percent, or more, per year, to the overall purchase price of the system.
Some customers will “outsource” their service and support (almost completely) while others expect to train and provide their own in-house technical support staff. Even so, software support and updates is still needed. Keep in mind, too, that many vendors offer “professional services” that can customize the IP communications system, such as by integrating desired third-party applications or special configurations.
Customers also need to specify the role they want and expect the vendor to assume in implementation and deployment. Such services can range from: pre-deployment network assessment (i.e., QoS verification), to complete deployment, configuration, even training.
Vendor’s response:
Quote a consistent, but realistic level of service and support that satisfied the above customer requirements, and which addresses: spare parts on-site inventory, major and minor software upgrades, and on-site response time (4 hours, next day, etc.).
Provide a modular quote on pre-deployment and implementation services, consistent with the customer’s stated expectations and requirements.
Indicate costs for different “levels” of support, and detail how these levels are differentiated. If professional services are required, indicate clearly whether these are performed by the vendor’s staff ,or by a VAR or distributor.
Voicemail accounts, voice conferencing capacity
Customer’s requirements:
Detail voicemail requirements in this section. These will include basic voicemail capabilities for virtually all users, but might also include customizable IVR (voice greeting) capabilities, and perhaps even full personal call routing, depending on the user’s presence status.
If UM (Unified Messaging)—integration of voicemail with your email—is required, this should also be described here. The desired UM integration level (which might include integration with Exchange email, and perhaps also fax) should be delineated.
Audio conferencing usually entails a separate server and software. Capacity—and cost—depends on how many concurrent conferences, and concurrent participants in each conference, you specify.
Vendor’s response:
Specify the costs for the voicemail accounts and voice conferencing capacity detailed above. Indicate voicemail license fees (whether per-seat, or per user/client).
Specify whether additional voice conferencing servers or other hardware are required, and indicate their costs. Indicate if conferencing facilities are priced “per port”.
Enhanced, advanced applications
Customer requirements:
Enhanced and advanced applications can vary substantially among the different vendors. The customer should carefully consider what applications are likely to contribute to user productivity, and where “real” cost savings can be realized.
Because there is substantial diversity among vendors, it may be advantageous to conduct some prototype testing of candidate applications and suites.
Video conferencing and other multimedia requirements should be well-described. An MCU may be required for multi-point video conferencing. More sophisticated Unified Communications, which may include many pieces and discrete components—Web conferencing, whiteboarding, etc.—needs to be fully detailed.
Vendor’s response:
Specify your UC suites, and individual productivity applications, videoconferencing, etc., including server hardware, extra cost for video cameras, MCUs, and all desktop/laptop client software.
Indicate if any UC applications are provided as “plug-ins” to third-party client applications. Also indicate minimal and incremental-user pricing.
All licenses and license fees
Customer requirements:
Be aware that vendors often have additional license and fee charges, many times involving client software or applications. The charges can be vary subtle and take a variety of forms—including “per seat” or “per port” costs. The customer should require that all these costs be outlined in the RFP/RFI response.
Vendor’s response:
Specify all additional licenses and fees, whether for users, by seats, per PC, right to use licenses, etc.
In 250 words or less, briefly summarize any unique or special features (not addressed above) you offer for your IP Hard phone models. Be sure to address:
1. Any special connectivity, attachment or peripheral options—such as Bluetooth, USB port, keyboard, etc.
2. Options for “Web browsing” via the phone-set display (and note whether a rendering/conversion gateway/server, such as Net6, is required).
3. What applications are currently available on the hard phone displays (i.e., voicemail player, emergency notices, directory, etc.)
4. Whether and how “presence” status is displayed on your IP Hard phones.
IP Hard phones—Enter response here:
Softphone(s)
In the below table, list your IP softphone offering(s) and provide the data requested:
Softphone model no. or name
Call-control protocol
Client platform (Windows XP, Mac OS, etc)
Vocoders
Any USB headset, handset?
Is softphone standalone, or part of a convergence or unified comms suite?
US list license price ($)
In 250 words or less, briefly summarize unique or special features or aspects of your softphone(s). Be sure to address:
1. Special features of a soft Attendant Console (if applicable).
2. Options for setting or changing the softphone to optimize voice quality, and/or bandwidth efficiency, including QoS, WiFi connectivity.
3. Whether videoconferencing is supported? As a built-in softphone capability?
4. If part of a broader UC (Unified Communications) or convergence package, the role of the softphone application in multimedia communications.
5. List other ancillary, value-added capabilities that are inherent in the softphone application, such as: call logs, click to dial; directory; etc. (addressed more in other sections)
Feel free to attach additional details, GUI screen shots in a “Softphone” appendix.
Softphone(s)—Enter response here:
WiFi endpoints
In 200 words or less, briefly list and describe the system’s support for 802.11-based endpoints and wireless LAN connectivity. Be sure to address:
1. WiFi phone models, whether made or resold by you, and supported third-party WiFi phone models.
2. Specific 802.11 radio modes supported (802.11a, b, g, n).
3. Related standards supported (i.e., 802.11e, 802.11i, etc.)
4. Whether 802.11 support is a component of a “dual-mode” offering (cell phone and WiFi). This is addressed more in the Mobility Section.
WiFi endpoints—Enter response here:
Mobile clients
In 150 words or less, list and briefly describe any software or firmware clients you offer that load and run on smartphones, PDAs and/or other “mobile” platforms (such as Windows Mobile release(s)). Be sure to address, for each:
1. What phone technology is supported (GSM, WiFi, etc.).
2. What capabilities, beyond basic cell telephony, the client software adds (such as: places cell calls back through the system, enables access to directory and click-to-dial, supports mobility roaming and call transfer, etc.).
3. Whether the client software provides interface commonality with your desktop phones.
Mobile Clients are also referenced in the Mobility section.
Mobile clients—Enter response here:
Video endpoint support
In 150 words or less, briefly describe the system’s support for video conferencing. Be sure to address:
1. Do (any of) your IP Hard phone models inherently support video, or the attachment of video cameras (i.e., via USB port)? What additional hardware required?
2. What video/camera equipment, add-ons, and/or video endpoints are supported or offered, and do you make or resell this gear?
3. What video-supporting desktop/laptop software is used for video support on soft endpoints? What platform(s) is/are supported? Is this software offered by you (i.e., your softphone application), or is it from a third party?
Additional questions on video support are posed in the Multimedia and Presence Support section.
Video endpoint support—Enter response here:
Other endpoints (special teleworker, conference room speakerphones, etc.)
In 150 words or less, briefly describe any other IP endpoints you offer or support, beyond those already discussed: Be sure to include: IP speakerphone models, special teleworker phone models and any other endpoints. Please also note IP call-control protocol support.
Other endpoints—Enter response here:
RFP EVALUATION
This RFP contains some 70 specific criteria, which vendors would need to individually address in their responses. These are organized under these 10 top-level category headings:
1. Architecture
2. Endpoints
3. Mobility
4. Standards and Openness
5. Multimedia and Presence Support
6. Basic Features and Subsystems
7. Add-on Options and Subsystems
8. Security
9. Productivity Enhancement
10. Cost Model
Except for the Cost Model section, the bulk of this RFP/RFI’s criteria have been intentionally kept generic—asking vendors about their support for specific features and capabilities. In the Cost Model category, the RFP/RFI issuer does need to provide details on the system’s requirements, by quantifying the nine cost components previously discussed.
To keep vendor responses concise and to the point, and to minimize excess marketing verbiage, we advocate limiting the maximum size of the vendor response to any particular item. Allowing 50 words for the each question or discussion point raised, this imposes a limit of 150 to 350 words for each criteria item. Individual responses that far exceed the limit should be abridged in a consistent manner. Vendors may still attach relevant supporting documentation, like screen shots or pictures of IP phone models, in separate appendices.
We propose a fairly simple mechanism for reviewing vendor responses. It is a technique long used by consultants to prioritize competitive alternatives in a complex analysis. For each criteria, all members of the review team make specific “pro” and/or “con” notes about that vendor’s response. Then, either individually or collectively, one of five summary grades is applied to that vendor for that criteria:
++ = This criteria represents a strong competitive advantage for this vendor.
+ = The vendor’s handling of this criteria is competitively positive.
0 = The vendor’s handling of this criteria is competitively neutral.
– = The vendor’s handling of this criteria is competitively negative.
–— = This criteria represents a significant shortcoming for this vendor.
A weighting coefficient can be applied to each criteria, depending on its perceived relative significance (say, 1 to 3; 3 being most significant). Then, calculating the total pluses and minuses is fairly straightforward.
For the latest version of this template, visit Voicecon Wiki