voicecon request for proposal for an ip telephony system€¦ · voicecon request for proposal for...

©2005 TEQConsult Group 1

VoiceCon Request for Proposal for an IP Telephony System

Prepared by Allan Sulkin

President, TEQConsult Group teqconsult.com

VoiceCon Spring 2007

IPTS RFP Workshop March 5, 2007


Preface

The following RFP document was exclusively designed and developed by TEQConsult for the VoiceCon® Spring 2007 Conference. The RFP is intended to solicit product information and pricing data about IP Telephony systems during the Fall 2006 time period. The RFP was written for a large multi-facility enterprise configuration with IP voice terminals as the primary station user interface to the system. TEQConsult Group recognizes that every business and institution has unique communications needs and resources, but the much of the material included herein can be used by VoiceCon workshop attendees regardless of their unique system size and application requirements. VoiceCon workshop attendees may use this RFP as a template for customizing their own RFP with the proviso that proper accreditation to TEQConsult Group will be included in the document. TEQConsult Group would like to thank Fred Knight, VoiceCon GM and the publisher of Business Communications Review, for his review and editing of this document, and to Unimax Systems Corporation for its contributions to the systems management section of the RFP.


VoiceCon IP Telephony System Request For Proposal General Guidelines for Proposals 1. Please read though the entire RFP before beginning to work on your

response. 2. Configure and price your system design to satisfy all stated RFP

requirements, including any and all system hardware and software elements necessary to satisfy a requirement. Vendors that under configure their system design to reduce its price proposal will be penalized.

3. All products and solutions proposed for this RFP must be formally announced at time of VoiceCon Spring 2007.

4. Do NOT provide material or information unrelated or not relevant to a specific RFP clause requirement.

5. Be brief, but complete, in your responses. 6. Provide succinct, clear, and unambiguous responses; do not obfuscate

your responses with unnecessary wordage. 7. Make sure to review and edit your proposal before submission. 8. All proposals are due December 1, 2006. Late submissions and/or

revisions to submitted proposals may not be accepted. Deadline extensions may be granted under acceptable circumstances, only.

Proposal Evaluation The proposals to the RFP will be judged on the following factors:

1. Satisfaction of system performance requirements 2. Price of the proposed solution 3. Adherence to each of the above general proposal guidelines

Important submission requirements:

• Submit Part 1 System Performance Requirements responses in MS Office WORD file format, excluding responses to RFP Clauses specifying PowerPoint format, e.g., Clause 1.0.1. When PowerPoint format is requested do not copy/paste PDF format graphics or images.

• Submit Part 2 System Pricing responses in MS EXCEL file format


PART 1: System Performance Requirements Submit Part 1 responses in MS Office WORD file format except when otherwise noted. 1.0.0 System Overview The VoiceCon Company plans to install a new IP Telephony System (IPTS) network to support its newly constructed Headquarters (HQ) facility, a Regional Office (RO), and three Satellite Branches (SBs) with Survivable Remote Gateway (SRG) capabilities. Dedicated local IPTS call telephony servers must be installed at the HQ and RO facilities. All proposed call telephony servers must independently support all generic software features for the proposed IPTS model(s) as required in Section 5 of this RFP. The three SBs will be configured as survivable remotes behind the HQ IPTS call server with local trunk circuit services (Note: Survivability requirements for the SB facilities are identified later in this section). The proposed IPTS network solution may include a single fully distributed IPTS or no more than two IPTSs (each housed at HQ and RO facilities). If a single IPTS is proposed the distributed call servers must function and operate independently of each other, and support all generic software features as required in Section 5 of this RFP. The HQ IPTS call server will initially support 1,360 station users at the HQ and three SB facilities. The RO IPTS call server will initially support 250 station users. See Figure 1 for an overview of the VoiceCon IPTS network. See Figures 2 – 6 for port capacity requirements at each of the five VoiceCon facilities. VoiceCon anticipates 50% station user growth at the HQ and RO facilities, only, and the proposed IPTS network solution must accommodate this growth without replacement of any installed hardware/software. There is no anticipated growth at the SB facilities. A centralized messaging system will be housed at the HQ facility and must be capable of supporting station users located at all VoiceCon facilities (HQ, RO, and SBs).


HQ IPTS1200 stations

RO IPTS250 Stations

SB1 SRG100 Stations

SB3 SRG10 stations

SB2 SRG50 Stations

WAN

Figure 1

Voicecon IPTS Network

HQ: HeadquartersRO: Regional OfficeSB: Satellite BranchIPTS: IP Telephony SystemSRG: Survivable Remote Gateway


HQ IPTS1200 stations

6 Local T1 circuits7 Long Distance T1 circuits

5 PFTS circuits25 Emergency Analog GS/LS Circuits

Figure 2

HQ Port Requirements

RO IPTS250 stations

2 Local T1 circuits2 Long Distance T1 circuits

2 PFTS circuits10 Emergency Analog GS/LS Circuits

Figure 3

RO Port Requirements


SB1 SRG100 stations

1 Local T1 circuit2 PFTS circuits

5 Emergency Analog Circuits

Figure 4

SB1 Port Requirements

SB2 SRG50 stations

10 Analog LS/GS circuits2 PFTS circuits

Figure 5SB2 Port Requirements


SB3 SRG10 stations

5 Analog LS/GS circuits1 PFTS circuit

Figure 6SB2 Port Requirements

VoiceCon has plans to install at all of facilities LAN/WAN cabling and a transport infrastructure that will fully satisfy the stringent requirements of IP Telephony communications for all intra-premises and inter-premises call control and voice communications transmissions. Each location will be equipped, at minimum, with a 1-Gbps Ethernet backbone. The local wiring closets will house 10/100/1000 Mbps Ethernet switches equipped with Power over Ethernet (PoE). Multi-service routers will be installed at all locations to support a MPLS WAN installation. All Ethernet switches and IP WAN routers will be equipped and programmed to satisfy QoS and security standards necessary to support voice communications acceptable to VoiceCon. Pertinent bandwidth, latency, packet loss, and echo issues will be addressed in the design and implementation. Each station user’s work area will be supported by four (4) four-pair, Category 5E cable wiring with one (1) RJ-11 wall connector and three (3) RJ-45 wall connectors to the local wiring closet. The RJ-11 and RJ-45 connectors will be either wall mounted or mounted in the modular furniture throughout the office environment. VoiceCon plans to run its IP Telephony system over this cable infrastructure. NOTE: The proposed IP Telephony system must be able to support a limited number of non-IP stations, e.g., analog telephones, requiring a RJ-11 connector. The proposed system can use either circuit switched port carriers or media gateways to support analog communications terminal equipment.


Vendor Response Requirement Based on the RFP requirements in this document prepare a simple network diagram that illustrates the proposed IPTS network design. Include in the diagram the brand name/model of the IPTSs, all circuit switched port carrier/media gateway equipment, the brand/name of the HQ-located systems management and messaging system. The diagram must be prepared and submitted in a separate file using MS PowerPoint format (identify the file as part of your electronic proposal submission). In addition copy/paste diagram in the submitted MS WORD file proposal here.

Proposed IPTS Network Diagram Here

VoiceCon HQ

Regional Office RO

Small Branch SB1 Small Branch SB2

Small Branch SB3

MX-ONE Media Gateway Classic LIM




3-MX-ONE Media Gateway LIMsMX-ONE Media Gateway Classic LIM

N+1 Server

N+1 Server N+1 Server

N+1 ServerWAN

Ericsson MX-ONE™VoiceCon MX-ONE Network

Messaging 4.1

CommOrg

Manager Availability

VoiceCon HQ

Regional Office RO

Small Branch SB1 Small Branch SB2

Small Branch SB3

MX-ONE Media Gateway Classic LIMMX-ONE Media Gateway Classic LIM




3-MX-ONE Media Gateway LIMsMX-ONE Media Gateway Classic LIM

N+1 ServerN+1 Server

N+1 ServerN+1 Server N+1 ServerN+1 Server

N+1 ServerN+1 ServerWAN WAN

Ericsson MX-ONE™VoiceCon MX-ONE Network

Messaging 4.1Messaging 4.1

CommOrgCommOrg

Manager AvailabilityManager Availability

Ericsson Response: Additional system designs are included in attachement “02_Ericsson Diagrams VoiceCon 2007.ppt”. 1.0.1 LAN/WAN Requirements VoiceCon has not yet decided on the make/manufacturer of its new LAN/WAN communications equipment.


Vendor Response Requirement Indicate if the proposed IPTS solution for the HQ and the remote facilities requires manufacturer-specific LAN/WAN communications equipment to support any or all of the following voice communications operations or functions: call processing, switching, routing, PoE, media gateway, QoS and security. If responding in the affirmative, only, identify the make and model of the necessary switch/router equipment and the reason for its requirement. Ericsson Response: The MX-ONE Telephony System does not require manufacturer-specific LAN/WAN communications equipment to support any or all of the following voice communications operations or functions: call processing, switching, routing, PoE, media gateway, QoS and security. 1.1.0 Basic IPTS Requirements The proposed IPTS equipment should be in current production and operating as part of a commercial system for at least five (5) customers in the USA. Vendor Response Requirement State if the proposed IPTS equipment satisfies this commercial availability requirement. If the IPTS model has not yet been shipped and installed in a commercial installation, state expected availability date. Also provide an estimate of the number of IPTS solutions (same model as proposed) currently installed and operating in the USA. NOTE: All proposed system hardware and software must be formally announced as of VoiceCon Spring 2007 to be accepted by VoiceCon in response to this RFP. This is a mandatory requirement to submit a RFP response.


Ericsson Response: The MX-ONE™ Telephony System Version 2 was Launched in the US market during the VoiceCon 2005 Fall event. MX-ONE™ Telephony System Version 3 is being released December 15, 2006. MX-ONE™ V.3 builds on V.2, and provides additional features and functions. MX-ONE™ V.3 Highlights:

• 50,000 Users • SIP support (extension & trunk) • Redundancy

o Network redundancy o Support for N+1

• Encryption + Antivirus Policy • Integrated DECT • Parallel Ringing • Support for Voice over WLAN (SIP) • Corporate Telephony (Integration with Microsoft LCS)

Also, MX-ONE™ V.3 provides additional hardware options. Information is provided in 1.3.0 System Design Platform. 1.1.1 Single System Image The proposed IPTS network should provide a Single System Image across VoiceCon HQ, RO and SB facilities. The Single System Image should include, but not be limited to, the following: 1) 5-digit dialing between all station users; 2) High degree of transparent operation across all VoiceCon facilities for station, attendant, and system features (see RFP Section 5: Call Processing Features); 3) HQ-located centralized systems management solution using a single unified database for all station user profiles, equipped system design, and system-level operations; 4) Network-wide attendant operator services across all VoiceCon facilities, including the ability to support a centrally located attendant pool; 5) Shared messaging system resources; 6) Automatic alternative routing across the network for all voice calls (station-to-station and PSTN trunk connections). Vendor Response Requirement: Provide specific answers to each of the following questions: 1. Is the proposed IPTS network solution a single system solution or multiple systems intelligently networked? 2. Does the proposed IPTS network solution fully satisfy all six (6) of the


stated Single System Image requirements? If not, explain which of the requirements are not satisfied? Ericsson Response: The proposed MX-ONE is a single system solution. The proposed MX-ONE fully satisfies all six of the stated Single System Image requirements. 1.1.2 Enhanced 911 (E911) Services Support It is mandatory that the proposed and installed communications system support E911 services provided by a public safety answering point (PSAP) as defined by FCC regulations. All VoiceCon IPTS network locations addressed by this RFP are served by the same PSAP. All VoiceCon IPTS station user E911 calls must be directed to their local PSAP for call handling and response regardless of location, i.e., facilities remote from the primary call telephony server. If more than one E911 solution is available for the proposed IPTS network configuration clearly specify the solution that is included in the price proposal. Vendor Response Requirement: Confirm that the proposed communications system solution supports E911 service for all user stations (IP and analog) at each of the VoiceCon facilities. In the response briefly explain how E911 service requirements are supported, specifically addressing each of the following questions:

1) A description of any optional hardware/software equipment included in the pricing proposal, and if a peripheral server is required who is responsible for its purchase?

2) How are station user moves/adds/changes reported to the E911 provider?

3) What degree of specificity station user location is identified to the E911 PSAP? Desktop work area, local switch room, work floor, other?

Ericsson Response: The focus for the Ericsson MX-ONE™ Telephony System has been to provide the same level of telephony functionality for IP telephones as has been offered for digital telephones and to provide a solution to one of the greatest challenges for IP telephony. This challenge is the lack of geographical knowledge, i.e. the fact that a user can register, make and receive calls anywhere on the corporate intranet. This user positioning is vital, not only for emergency (E-911) calls but also when the available bandwidth to small offices is limited and


for the dialing of public numbers when this intranet is spread over several NPAs (areas with different area codes) and the same dialed local number actually represents different public listed directory numbers. The Ericsson MX-ONE™ Telephony System solution to this problem is its concept of Telephony Domains. Within a system, a domain can be specified for offices in different cities, in different buildings within a metropolitan area or even parts of one building (e.g. entrance or floor level). The telephony domain information is received from the corporate DHCP server (if configured) when a telephone is connected to the network.

• Geographical positioning of users calling Emergency numbers e.g. E-911.

• Area code per domain, allowing users registered in a remote location to use the normal, local PSTN number plan.

The emergency feature is available in the basic system without extra H/W or S/W. 1.1.2.1 E911 and Station Moves It is required that station user moves behind the proposed IPTS solution be tracked dynamically in real time for E911 services support. Vendor Response Requirement: Indicate if the proposed E911 solution satisfies this desirable capability and indicate how often the database updated. If an alternative E911 solution is available that satisfies this capability, but is not included as part of the overall IPTS solution and pricing proposal, briefly describe this option and the incremental costs to purchase and install beyond the proposed solution. Ericsson Response: Since we are using a configured number for each domain, the fact that a user is moving around into different domains doesn´t have any impact on our positioning feature. Whichever user that is logged on to a telephone does not impact the delivered number. 1.2.0 Proposed Communications System Design The proposed communications system may only be based on either of the two following architecture technology designs:

• Single system design based on true peer-to-peer distributed call


processing topology, i.e., identical or similar call telephony servers located at all VoiceCon facilities (HQ, RO, SBs)

• Intelligently networked multiple system design based on identical or similar call telephony servers located at VoiceCon HQ and RO facilities, and survivable remote gateways at VoiceCon SB facilities configurable behind the HQ call telephony server.

Only a supplier’s most current generation hardware/software solution will be acceptable. No refurbished equipment is acceptable. NOTE: There is no preference for either the single or multiple system design if all 1.1.1 Single System Image requirements are satisfied. Vendor Response Requirement: Briefly describe your proposed solution, referring to the diagram from RFP Clause 1.0.0 when applicable. Limit your response in this section to the following high level information as details are requested in following sections:

1. Product and model name(s) for the IPTS(s) and messaging system. 2. Identify proposed solution as a single system or multiple system design. 3. For each network location specify the product/model used to support station/trunk call processing and switching operations under normal operating conditions. 4. Identity the software release for each product/model proposed 5. Provide the product/model introduction dates.


Ericsson Response: Product name(s) and model name(s) Ericsson MX-ONE™ Version 3 IP communications platform

MX-ONE™ Telephony System Version 3 MX-ONE™ Telephony Server 3.0 MX-ONE™ Media Gateway 3.0 MX-ONE™ Media Gateway Classic

MX-ONE™ Communication Organizer 3.0 MX-ONE™ Manager 3.0 MX-ONE™ Messaging 4.1

The MX-ONE Telephony System is a single system employing a distributed call processing topology. Each location will have one or more MX-ONE™ Telephony Server/Media Gateway combinations depending upon the requirements. The Telephony Server/Media Gateway combination is referred to as a LIM. Ericsson MX-ONE™ is Version 3 of the software platform. The Ericsson MX-ONE™ Version 3 is orderable as of December 15th, 2006. 1.3.0 System Design Platform The proposed system solution may be based on either of the following two architecture system design:

• Converged TDM/IP: call telephony server supporting LAN/WAN distributed circuit switched port interface cabinets with equipped media gateway interfaces for IP port connectivity

• Client/server: call telephony server supporting media gateway equipment (server-embedded, standalone, switch/router-equipped or desktop) for non-IP port connectivity

Vendor Response Requirement: Briefly and clearly describe the architecture and design elements of the proposed IPTS solution. Include in your basic system description information about the following common equipment hardware elements:

1. Type of architecture design (converged or client/server) 2. Call telephony server and associated common control equipment 3. If applicable, circuit switched port interface equipment housing TDM

port interface circuit cards and media gateway boards.


4. If applicable, LAN-connected media gateways (server-embedded, standalone, switch/router-equipped, desktop

Ericsson Response: MX-ONE is a communication solution for enterprises. The MX-ONE integrates voice and data, fixed and mobile communication, as well as public and private services. It is designed to fit into the existing infrastructure of an enterprise Local Area Network (LAN), thereby saving the cost of operating an additional network for voice. MX-ONE comes with large networking capabilities and an Operation and Maintenance (O&M) functionality that complies with IS/IT common practices. The distributed architecture of MX-ONE makes it a flexible solution, able to scale from 100 to 50,000 users. Releases planned for later in 2007 will scale to over 100,000 users. For the user, the MX-ONE solution offers the same user experience as the classic circuit-switched Private Branch Exchange (PBX). Number dialing and terminal interaction is the same with the same array of services and functionality and most well-known features and services are available for the user through wired IP phones and mobile phones. The MX-ONE solution provides features for the users' daily communication, including user management of activities and profile settings, as well as features for voice mail and fax mail. The MX-ONE solution provides the enterprise with a stepwise migration from a circuit-switched PBX into a converged voice and data network. The MX-ONE Telephony System provides business class telephony features. It performs call control, call-signaling, and media transcoding and conversion functions. MX-ONE Telephony System can, in various configurations, support IP and mobile extensions, analog and digital extensions. The MX-ONE Telephony System

• provides traditional PBX functionality • is an H.323 Gatekeeper and Media Gateway • is a gateway towards private and public telephony networks,

both fixed (PSTN) and mobile (PLMN) • offers a wide range of telephony features


The major element to form the IP-based voice functionality in the MX-ONE solution is the MX-ONE Telephony System. It comprises the following functions:

• Call signaling • Call control • Media transcoding and conversion

The MX-ONE Telephony System consists of hardware modules called LIMs. Different types of LIMs are available in the MX-ONE Telephony System:

• Media Gateway LIM • MX-ONE Compact-SM • Media Gateway Classic LIM

Up to 64 LIMs can form an MX-ONE Telephony System. The Media Gateway LIM consists of the Telephony Server, a standard 19-inch server, and the Media Gateway, an Ericsson-developed hardware with a 19-inch 1U form factor. The following functions are offered by the Media Gateway LIM:

• Digital trunks (ISDN E1/T1) • Mobile extensions • IP extensions • Four analog extensions • IP networking with other PBXes • Operator Assistant

The Telephony Server and the Media Gateway are to be treated as system components inseparable from each other. The Telephony Server is based on open standard hardware and runs on the LINUX® operating system. Hardware options available for a Media Gateway LIM: 1) Rack mounted 19” Server, (HP, IBM, DELL, etc.) with Media Gateway

Proposed Solution

2) Ericsson MX-ONE Server ESU in single 1U, 19” Unit 25W with Media Gateway


3) MX-ONETM Compact-SM ESU and Media Gateway in asingle 2U unit, 45W and duplicated power.

The Media Gateway Classic LIM consists of the Ericsson Server Unit (ESU) and the Media Gateway Classic. The ESU is hosted by the Media Gateway Classic. The Media Gateway Classic is provided as one or two 7U 19-inch subracks with a number of boards for the different functions and interfaces.

Supported functions and interfaces are:

• Digital trunks (ISDN over E1/T1) • Digital extensions • Analog extensions • Analog Trunks • DECT Base Station interfaces


The Telephony Server is a standard Linux-based server that runs the Ericsson telephony call control software. The following applications run on the Telephony Server:

• Telephony System Application • File System for Media Gateway • Manager Telephony System (only on LIM number one)

The ESU is a standard PC embedded on a single board hosted by the Media Gateway Classic. The ESU runs the same version of the Linux operating system as the Telephony Server. The following application runs on the ESU:

• Telephony System Application The Media Gateway is constituted by a proprietary hardware developed by Ericsson. It is a 19-inch rack-mounted 1U unit. The operating system is Linux, installed on the Telephony Server file system and remotely mounted by the Media Gateway. The Media Gateway supports:

• Up to 700 extensions • Eight E1/T1 ports • Four analog ports for fax machines and courtesy phones

The Media Gateway Classic is provided as one or two 7U subracks adapted to the 19-inch building practice that allows mounting in a standard 19-inch rack. A number of boards provide the necessary functions and interfaces. Some of the boards are necessary for core functionality, while others are optional, depending on the necessary interfaces, number of telephones, and traffic requirements. The Media Gateway Classic supports up to 480 analog and/or digital extensions. The following boards are included:

• ESU - the Ericsson Server Unit with the same software as the Telephony Server

• LSU-E - LIM Switch Unit Ethernet - a common interface between the Telephony Server and the other boards

• DSU - Distributed Switch Unit- - providing distributed switching functions. Two boards per subrack.


A variable number of the following boards are included depending on traffic needs, number of extensions and number of trunks:

• IPLU - IP Line Unit - used as a packet to TDM Gateway. • TMU - Tone and Multiparty Unit - providing Dual Tone Multi

Frequency (DTMF) Sender/Receiver capabilities • ELU34 - Extension Line Unit - which provides 32 lines for

analog phones • ELU33 which provides 32 lines for digital phones • TLU76 - Trunk Line Unit - which provides a single E1 - PRI

(30B+D) interface • TLU77 which provides a single T1 - PRI (23B+D) interface • TLU82 which provides 8 Analog Trunk ports (GS/LS)

1.3.1 Common Control The primary common control complex of the proposed IPTS should be based on a standalone call telephony server or a call processor blade that is embedded in common equipment that functions as a call telephony server. The physical equipment may either be a fully bundled proprietary hardware/software offering that is factory configured or third party equipment provided by VoiceCon that is capable of running proposed proprietary call processing software without any service degradation. Any and all of the proposed primary common control call processor elements used to provide call processing functions must be proposed in a redundant duplicated design with seamless switchover operation between active and standby control elements, i.e., all active call connections must remain up during switchover in case of failure or major alarm states and new calls set-up without delay. The secondary standby control element must be local to the primary, i.e., physically located at the same VoiceCon facility. The secondary standby cannot be located at a remote VoiceCon facility. This takes into consideration the possibility of simultaneous primary control and LAN/WAN link failure that affects telecommunications services to station subscribers. This redundancy requirement does not apply to local survivable processors at SB facilities where primary control is located at the HQ facility. Solutions based on fully dispersed call processing system designs, i.e., primary control elements at HQ, RO, and SB facilities, however, must conform to the local redundancy requirement wherever a primary control element is installed. The overall common control design may be based on a load sharing design in which any call telephony server/processor blade may be programmed to function in primary and secondary backup modes. All primary common control elements must be capable of supporting required equipped and wired capacities at time of installation.


The call processing rating for the proposed primary and secondary IPTS call server(s) or equivalent(s) must minimally support the following call processing ratings at each of the following VoiceCon facilities: HQ: 35,000 Busy Hour Call Completions (BHCCs) RO: 10,000 BHCCs SB1: 5,000 BHCCs SB2: 2,500 BHCCs SB3: 1,000 BHCCs Vendor Response Requirement: Provide a brief description of the common control design you are proposing in terms of design platform: call telephony server, call processor blade (including necessary housing), third party server. Confirm that the duplicated common control requirement is fully satisfied by the proposed solution, and identify any feature/function that is not available if a standby (back-up) call processing element must be activated in case of a primary element failure. Ericsson Response: The common control of the MX-ONE Telephony System is built on an open architecture using standard components, Linux OS, and Ericsson’s Telephony software. The proposed MX-ONE Telephony Server is a HP DL360 server with an Intel Xeon 3.4GHz CPUs and 1GB memory. This server is one element of a MX-ONE LIM, described in 1.3.0 System Design Platform. The MX-ONE utilizes a distributed architecture. This design, when applied to IP terminals, provides a “load” sharing solution. IP terminals can register to any MX-ONE LIM. The actual load sharing is controlled by the IP terminals access point to the system. This access point can be either "any" MX-ONE LIM in the multi cast registration case, or one of two pre-configured MX-ONE LIMs in the terminal device. IP to IP calls are not terminated in the case of a server failure and new calls can be established once the IP terminal re-registers to another MX-ONE LIM. A back-up LIM server can also be installed (N+1) at any of the hardware locations for support of that location’s LIMs, including the failed server’s Media Gateway. All features are available when operating on the back-up LIM server. The switchover is automatic. During the switchover the affect Media Gateway will not be available. In addition, MX-ONE V.3 provides network redundancy for intra-LIM signaling.


1.3.2 CPU Make/Model Vendor Response Requirement: Identify the make/model of all proposed common control CPU(s) and associated BHCC rating for the configured system. Ericsson Response: Each MX-ONE Telephony Server 3.0 is a HP Proliant DL360 server and proposed with an Intel Xeon 3.4GHz CPU. The proposed MX-ONE Telephony System will provide at least 18,000 BHCC per LIM. This means ONE 64 LIM MX-ONE Telephony System will provide at a minium 1.1M BHCC. 1.3.3 Call Processing O/S Vendor Response Requirement: Identify the primary operating system of the common control call processor. A version of Linux is preferred, but not mandatory. Ericsson Response: The MX-ONE V.3 uses SUSE® Linux Enterprise Server (SLES) version 10 as its primary operating system. 1.3.4 Memory Vendor Response Requirement: Briefly describe the main memory design and storage elements and capacity for both the generic software and customer database as proposed. Ericsson Response: Each MX-ONE Telephony Server 3.0 (HP Proliant DL 360) is equipped with 1GB memory. This memory is used for all software and databases running on the each MX-ONE Telephony Server LIMs. 1.3.4.1 Database Integrity Vendor Response Requirement: How does the proposed IPTS solution maintain the integrity of the customer database between back-ups?


Ericsson Response: All database changes are real time and a data-backup should be performed after changes are made. The “data_backup” command will copy all data to the backup device (disk drive). The MX-ONE will verify the command structure and issue warning messages for system effect affect commands. 1.3.4.2 Database Information Loss Vendor Response Requirement: Identify under what circumstances can customer database information (configuration, messages, logs, etc.) be lost during back-ups Ericsson Response: Database changes are inhibited during backups. The proposed solution includes RAID1 disk for the Media Gateway LIMs. A hardware failure, power loss, or other system affect event during the backup could cause a loss of database information for that backup. The backup of the exchange is stored on each LIM and should be done on a daily basis. At a data backup, the exchange data for program units is stored in the file system. When a program unit is reloaded, exchange data for all program units is restored to prevent exchange data inconsistency. As part of certain error recovery routines, the exchange data will be restored from the backup in order to revert the system to the last known state with data consistency. Exchange data includes:

• System configuration data • Application data (for example, extensions and trunks). The

application data are altered either by command (for example, adding extensions) or by extension procedure (for example, call diversion)

Exchange data should be saved to backup regularly. The data should also be stored after:

• Loading the system initially • Changing hardware configuration • Upgrading a program unit • Altering application data by command (for example, adding

extensions)


1.3.4.3 Database Backup Scheduling Vendor Response Requirement: How often should the customer database be backed up? Specify if it is a full or incremental backup and the time the process takes. Ericsson Response: The backup of the exchange is stored on each LIM and should be done on a daily basis. This is a full backup. A backup will take approximately 10 minutes for a 32 LIM system. By using crontab (LINUX), it is possible to create automatic data backups, configuration mirrors, and safety backups. 1.3.4.4 Data Purging/Archiving Vendor Response Requirement: Describe the mechanism for data purging and archival, including storage and retrieval of archived data. Ericsson Response: The MX-ONE automatically stores the five latest backup directories. If more backups are made, the oldest backup directory is deleted. The data_backup command is used to create the backup and the data_restore command is used to restore a backup. A safety backup of the entire exchange can be performed and then copied to any mounted storage device, (network drive, DVD/CD RW, tape, etc.), that is supported by LINUX. These backups can be used to restore a failed LIM or the entire system. 1.3.5 Power Supply Vendor Response Requirement: Briefly describe common control power requirements and the integrated power distribution design. Indicate if the power supply is dependent on either an AC or DC current source.


Ericsson Response: Each MX-ONE Telephony Server is proposed with redundant power supplies. These power supplies are 120VAC. The Media Gateway is 120VAC powered. The Media Gateway Classic is –48VDC powered. The Media Gateway Classic is –48VDC powered and the proposed solution includes an AC/DC power unit, (APC Magnum VS 50). This unit converts the power input from the AC power supply network to DC output for the DC/DC converters in the Media Gateway Classic. This solution includes N+1 rectifiers. 1.3.5.1 Power Safeguards Vendor Response Requirement: Describe any power failure safeguards that are included in the IPTS design. Briefly describe what happens to system operation during a power failure Ericsson Response: Each proposed Telephony Server (HP DL360) is equipped with duplicated power supplies. Each Media Gateway Classic LIM will have N+1 rectifiers. The MX-ONE is based on distributed processing. A power failure at any one LIM will only affect the devices attached to that LIM. A site power failure, without UPS, will affect all LIMs at that site, but the other sites will continue operation. The local IP end-points can re-register if necessary to any available LIM. During a site power failure, the power fail transfer unit will connect external analog trunks to analog telephones. See 3.5.5 Power Failure Transfer Station (PFTS). 1.3.5.2 Power Backup Vendor Response Requirement: Is the proposed IPTS solution equipped with standard UPS hardware, and if so how long can the system run on it? If not, what UPS requirements are recommended?


Ericsson Response: Ericsson is not proposing UPS systems. It is assumed the system will be located in a data center which typically would have these systems. The following is the typical power load for the proposed equipment. HP Servers approximately 150-300 W Media Gateway approximately 22 W Media Gateway Classic approximately 250-350 W 1.3.6 Ethernet Call Control Signaling Links Vendor Response Requirement: Identify for each active and standby call telephony server the number of available and configured RJ-45 Ethernet LAN uplink interfaces for call control signaling to LAN-connected cabinets/carriers and/or standalone ports. Include a brief description of how the physical Ethernet connection is provided: dedicated circuit board; daughterboard; fully integrated RJ-45 connector, et al. Ericsson Response: Each MX-ONE LIM has two Ethernet LAN interfaces toward the corporate infrastucture. These interfaces are RJ-45 connector, and are integrated in the MX-ONETM Server and Media Gateway. 1.3.7 System Clocks Vendor Response Requirement: Identify the number and type of internal system clocks that are available and configured. Ericsson Response: The MX-ONETM utilizes NTP as a clock source for each LIM server. 1.3.8 Redundant system design elements It is desirable to have a highly redundant system design, especially as it relates to common control elements necessary for call processing, maintenance, and administration operations. Vendor Response Requirement: Specify the level or degree of redundancy included in your proposal for each of the following listed common control elements. For example, full duplicated


back-up, standby load sharing, seamless switchover, cold standby, et al.

• Primary call processor • Main system memory • Customer database memory • RJ-45 Ethernet uplinks to network • Power supply • Tone generators • Call classifiers • Registers • DTMF receivers • I/O interfaces

Ericsson Response: The proposed MX-ONETM design has the following levels of redundancy: MX-ONETM LIMs

MX-ONETM Telephony Servers (call processing/memory) Each with redundant disk drives (RAID1), redundant power supplies, 2 CPUs, and additional 1 Gb Memory.

MX-ONETM Media Gateways

DTMF Receivers for TDM Devices Tone Generators for TDM Devices

The Media Gateways are common resources in the distributed architecture of the MX-ONE. Any Media Gateway can service any IP terminal in the system. 1.4 Local Survivability It is important to VoiceCon that station users at all network locations have access to telephony services at all times. This includes 100% of generic software features and trunk circuit access to a local exchange carrier. For this reason it is highly desirable that station users at VoiceCon’s SB facilities have access to telephony services in case of HQ-SB WAN link failure due to switch, router, or private network transmission service issues, or HQ common control failure for any reason. It is preferable that standby telephony services be provided by an on-site call processing option. A less desirable, but acceptable, emergency option is an alternative PSTN-based call control signaling link, but only if an on-site call processing option is not available as part of the system solution. It is also highly desirable that the standby call processing option provide stations users with the same level of telephony services, i.e., station,


attendant, and system features, supported by the HQ IPTS at the medium (50 stations) and large (100 stations) SB facilities. For the small (10 stations) SB facility it is acceptable that POTS-like survivability (dial tone, PSTN trunk access, intercom calls, basic features such as Hold and Transfer) is supported. Please note that Power Failure Transfer Station (PFTS) is not acceptable as the local survivability option at the small SB facility. SB facility local survivability for any disruption due to any circumstance (common control failure and/or LAN/WAN incidents) of HQ-based IPTS call control signaling is a mandatory requirement for proposal submission. Vendor Response Requirement: Describe the proposed local survivability solution that satisfies the stated requirements. Include a description of all proposed and priced local survivability options (including any and all required hardware, software, and PSTN transmission services necessary to implement the option) for each of the three SB facilities: 10 stations, 50 stations, 100 stations. Ericsson Response: MX-ONE is built up based on a modular concept inherited from MD110. Each module can operate independently on its own or in combination with other modules, work as one large communications system. The modules are called LIMs and each LIM is implemented on its own server and is therefore fully self-supportive. A large system consisting of several LIMs can be implemented on a number of physical servers. These servers can be centralized at one location or decentralized over a geographically widespread area. From the users’ point of view and from configuration point of view it will act as one system. Configuration is done from one and the same place. The distributed architecture means small failure units. An extremely high degree of availability is achieved. The risk of catastrophic failure is practically eliminated. The proposed solution incooperates a MX-ONE LIM at each remote site. This LIM will provide local gateway and gatekeeper support in the event the site is isolated. Full telephony features will be available during any isolation. In addition, the proposed solution includes a backup LIM server at all sites, except SB3. See 1.3.1 Common Control.


1.4.1 Survivable IPTS Features/Services Vendor Response Requirements: Identify any required generic software feature (See Section 5.0 Call Processing Features) not available or operational when the local survivability solution is activated at VoiceCon’s 50 station and 100 station SB facilities. Also identify any type of station user equipment (instruments, consoles, softphones, wireless communications devices, et al) not supported in standby survivability mode at these two facilities. Ericsson Response: The proposed solution is a distributed processing architecture. Each location, including the 50 and 100 station SBs will have one or more MX-ONE LIMs. With this architecture ALL features and station types are supported should the location be isolated. 1.4.2 Local Survivability Failover and Switchback Vendor Response Requirements: For each of the SB facilities is failover to the local survivable call processing option seamless, i.e. no interruption of in-process telephony services, for any or all stations users if WAN connectivity is disrupted to the HQ IPTS? Indicate in answer if there is delay for implementing new calls immediately after the WAN disruption. Also describe the switchback process when HQ facility IPTS call control is again available via the WAN, specifying if the process is automatic or manual and how long the process takes to implement. Are connected calls and voice operations at the remote facility affected in any way by the switchback process and how soon can new calls be implemented? Ericsson Response: The proposed solution is a distributed processing architecture. Each location, including the 50 and 100 station SBs will have one or more MX-ONE LIMs. With this architecture ALL features and station types are supported should the location be isolated, and there is no need for any switchover/switchback. 1.4.3 Survivable Messaging Services It is desirable that remote station users at the RO and SB facilities have access to messaging services if there is a WAN link disruption to the HQ messaging system.


Vendor Response Requirements Does the proposed IPTS network and messaging solution satisfy this requirement if WAN connectivity between HQ and any of the other facilities (RO, SBs) is not available? Briefly describe how messaging services would be implemented and accessed by remote station users in emergency situations. The minimum messaging services function in survivable mode should include voice mailbox access by station users. Ericsson Response: Yes, voice mailbox access by station users is provided via dialing out local PSTN trunks through the HQ PSTN trunks. The procedure would operated in the same manner as a user would perform using remote access to voice mail from an off-system location, i.e., home, hotel, etc.. Message Waiting indication via display/light is not provided. 1.4.4 Network Failover Resiliency In the unlikely event the redundant common control complex (primary active and secondary backup) at either HQ or RO facilities become nonfunctional due to extreme system failure or catastrophic circumstances, e.g., fire, VoiceCon requires implementation of a resilient network failover process. This process requires that all local station users and media gateway equipment configured behind the nonworking common control complex automatically re-register to designated emergency call telephony server(s) at either the local or remote facility for continuity of telephony services. For this reason it is necessary that the designated emergency call telephony server(s) located at the HQ/ RO facility be capable of supporting sufficient port capacity requirements in the event of a failover. Vendor Response Requirements Does the proposed IPTS solution support network failover resiliency in case of a catastrophic common control failure at either the HQ or RO facilities? If affirmative, describe the failover process, optional hardware/software and/or WAN transmission requirements to implement, and the time required for the network failover to be implemented before telephony services are available. Indicate if the proposed IPTS solution can support more than one network failover design.


Ericsson Response: It would appear that the type of failure described would eliminate access (WAN/Router) to the any backup site for the IP end points. To implement this type of resiliency would require duplication of “paths” from the surving end-point to another complete “network” center. The MX-ONE is a single system and the IP telephones can register to any available LIM, whether local or remote, provided there is access. For the proposed design, the HQ site will support “all” IP end-points. Should the LIM at RO be disabled, the IP telephones would be supported by HQ automatically. Should the MX-ONE LIMs at HQ be totally disabled, then the RO site would need to have enough LIMs to support the services provided by the LIMs at HQ. In this case, RO would be equipped with four (4) additional LIMs. It should be noted that if PSTN access will be required, then this circuits would need to be available. The MX-ONE also supports network redundancy. To achieve network redundancy, a redundant network infrastructure must be available.Telephony Servers can be connected to two LANs. If one of the LANs fail, the other one will continue to serve the operations and the Telephony Servers will be available on the functioning LAN. If Media Gateways are evenly distributed over the two LANs, approximately half of them will still function. During the network downtime, the overall capacity of media processing will be reduced.

Telephony Server 3.0

LAN 2

LAN 1

Media Gateway

LIM 1

= Media= Signaling


Media Gateway

LIM 2Telephony Server 3.0

LAN 2

LAN 1

Media Gateway

LIM 1

= Media= Signaling


Media Gateway

LIM 2


1.5 Session Initiated Protocol (SIP) VoiceCon requires that the proposed IPTS support SIP-compatible stations and trunk networking as specified in the most current IETF Work Group RFC document. It is also required that the IPTS solution be capable of supporting the IETF-sponsored signaling protocols used for Internet conferencing, telephony services and features, presence, events notification and instant messaging. 1.5.1 SIP Stations Vendor Response Requirements Indicate if the IPTS solution as proposed can currently support SIP-compatible desktop telephone instruments (self and/or third party) and PC client softphones assuming 20% of individual system end user stations are IP-based. Specify if SIP call control is embedded in the IPTS common control design or optional hardware/software elements are required. Also identify up to three (3) third party SIP telephones you have successfully tested for operation behind your proposed IPTS solution. Ericsson Response: The MX-ONE supports SIP end-points. SIP is included in the MX-ONE software. No optional hardware/software elements are required. Ericsson’s Dialog 44XX IP Telephones support either H.323 or SIP. The MX-ONE will suport third party SIP telephones that support SIP-INFO. Currently the Grandstream BudgeTone 100, Grandstream GXP-2000 Enterprise IP Telephone, Hitachi Wireless IP 3000, Hitachi Wireless IP 5000, and Ascom i75 SIP phones have been tested. Additional terminals are planned for testing. 1.5.1.1 SIP Clients Vendor Response Requirements Do the IP desktop telephone instruments and PC client softphones included as part of this proposal in response to RFP Section 5: Voice Terminals currently conform to IETF SIP standards? If not, are they upgradeable to support SIP standards and specifications via a firmware download if required in the future? If a firmware download is required is there an associated cost or fee to VoiceCon?


Ericsson Response: Ericsson’s Dialog 44XX IP Telephones support SIP. The softphone (Personal Assistant PC) is not SIP based. 1.5.2 SIP Trunk Networking Vendor Response Requirements Indicate if the IPTS network solution as proposed can support SIP-based trunk networking. Specify if SIP media proxies are required to support this requirement. Identify up to three (3) major Service Providers (SPs) and three (3) other IPTS suppliers you have conducted IP trunk networking compatibility tests with for the proposed IPTS. Ericsson Response: The MX-ONE V.3 supports SIP Trunk Networking. SIP Trunk Networking for the MX-ONE V.3 can be used with or without proxy service. SIP Trunk Networking for the MX-ONE V.3 is a new offering and at this time the following compatiblity tests have been performed. 1) Asterix (freeware softswitch PBX) 2) Ericsson IMS platform (IMT) 3) Telenor (Alcatel softswitch) 1.5.2.1 SIP Applications Vendor Response Requirements: Indicate if the IPTS network solution as proposed can support SIP-enabled applications, such as Internet conferencing, telephony services and features, presence, events notification and instant messaging. Ericsson Response: MX-ONE V.3 supports some SIP-enabled applications like ViPr (videoceonferencing solution), Solidus eCare 5.0 (Contact Center solution, version 5.1 can connect directly to SIP network or SIP complient PBX), NOW (Attendant Console) supports viewing of Presence from Microsoft LCS. More applications are part of our roadmap and will be included in future releases.


1.6 Security VoiceCon requires a secure IPTS network solution to optimize system performance and reduce the probability of toll fraud and illegal system access. 1.6.1 Authentication Vendor Response Requirements Briefly describe authentication processes embedded in the proposed IPTS solution to prevent: unauthorized access to common control elements, data resources; and abuse of telephony services, e.g., toll fraud. Ericsson Response: Administrative logon access to the MX-ONETM Telephony System is based on Linux’s login services. A local connection to the Telephony System (the Telephony Server within any LIM) is achieved via monitor and keyboard connected to, Telephony Server. Using a local connection, users can login to any shell with the appropriate password (root, bash or mdsh). The security measures available for the MX-ONE system are mainly based on the following open standard technologies:

• SSL (or TLS) Provides secure access to web services. Web clients are authenticated with username and password while servers (web servers) have to authenticate themselves using a valid digital certificate

• SSH Provides secure console-based access to the MX-ONE Telephony server

• IKE/IPSec Can protect the communication between the system servers. Authentication is based on pre-shared keys.

Voice over IP Traffic The H.323 RAS signaling is protected by the means of a password-based mechanism: each time an IP extension registers itself at the MX-ONE Telephony Server, he/she has to provide a valid password in order to guarantee the success of the registration process and to avoid toll fraud.


1.6.2 Disruption of Services Vendor Response Requirements Briefly describe any embedded features/functions in the proposed IPTS that will reduce probability of telephony services disruption due to Denial-of-Service (DoS) attacks. Ericsson Response: The MX-ONE and the VoIP terminals are end-points on the IP Network and do not provide any features/functions regarding Denial-of-Service (DoS) attacks. The use of VLAN, for example, makes the telephony communication occurring over the LAN more resilient to Denial of Service (DoS) attacks. Most of these attacks originate from PCs in the LAN. Therefore PCs should be located in a different VLAN than the VoIP terminals. Then only the VLAN where the DoS attack originated will be affected. The separation of different types of traffic improves the security of the network as it limits the spread of an attack and facilitates diagnostic actions. The use of firewalls and Intrusion Detection Systems (IDS) provides an additional degree of security to the network. However, it is necessary to use devices that are aware of the application layer protocol exchanges, as H.323 and RTP for example use dynamically-allocated ports that are negotiated during the set-up of the VoIP connections. It is highly recommended to use VPN when having a VoIP network composed of physically separated subnets and public networks are being traversed. 1.6.3 Confidentiality and Privacy (Packet Sniffing) Vendor Response Requirements Briefly described any embedded features/functions in the proposed IPTS that will preserve communications confidentiality and privacy. Indicate if control signaling and/or bearer communications signaling is encrypted at the call control, voice client, and media gateway elements to counter packet sniffing attempts.


Ericsson Response: Ericsson is continuously working to improve security in MX-ONE. Enhancements in MXONE V.3 include:

• Inter-LIM signalling protected with IPSec and pre-shared keys. • Media encryption with SRTP for telephones and IPLU • Signalling protected with TLS.

In an MX-ONE with Media Gateway, security is provided for calls between IP phones. In a mixed scenario with both Media Gateway and traditional media gateways based on Media Gateway Classic, security is provided for calls between IP phones and outgoing calls are routed via the Media Gateway Classic IPLU. 1.6.4 Physical Interfaces Vendor Response Requirements Are there separate physical network interfaces to IPTS administration, control, and voice transmission signaling functions? Ericsson Response: No. 1.6.5 Root Access Vendor Response Requirements Is there direct Root access to the IPTS common control? Ericsson Response: Yes when using locally connected monitor/keyboard. No for remote connections. Root login in a remote communication session (using TELNET or SSH) is disabled.


2.0 IPTS Network Port Capacity Requirements The proposed IPTS must be capable of supporting port capacity requirements for the HQ facility and remote branches. It must also be capable of supporting future VoiceCon growth requirements at HQ and RO facilities. 2.1.0 Port Capacity Requirements The equipped port capacity of the proposed VoiceCon HQ IP Telephony System at time of installation and cutover must support of a mix of IP telephones, analog telephones, facsimile terminals, modems, local central office trunk circuits (analog and digital, long distance trunk circuits [digital, only], and private network trunk circuits [IP]). In support of general communications requirements, VoiceCon facilities will have a sufficient number of wiring closets distributed throughout each facility to satisfy ANSI/EAI/TIA 569 structured cabling specifications for voice and data communications. Wiring closets will be interconnected based on requirements of the selected system. The entrance facility (trunk connect panel), main telecom equipment room, and Main Distribution Frame (MDF) for each facility are located off the entrance lobby. It will be the responsibility of the contractor to provide all cross connects between labeled 110 terminal blocks in each wiring closet and the demarc or "smart jack" and their equipment. The following sections describe the port capacity requirements for each of the VoiceCon network locations. Satisfying these stated port capacity requirements is a MANDATORY requirement 2.1.1 HQ Facility The HQ location is a four-floor facility that will support at time of system installation and cutover the following station equipment: * 1040 desktop IP station instruments; * 100 PC client softphones (including three attendant operator positions); * 10 IP audio conferencing units; * 26 analog telephones including 5 used for Power Failure Transfer Station operation; * 12 facsimile terminals; * 12 data modems. Station equipment is uniformly distributed within and across the four floors of the building. There are ten (10) wiring closets per floor, and one (1) main equipment room on the first floor. See Table 1 for station summary. 2.1.2 RO Facility The RO facility will be a two floor facility that will support: * 205 desktop IP station instruments; * 21 PC client softphones (including two (2) attendant operator positions);


* 4 IP audio conferencing units; *10 analog telephones including 2 used for Power Failure Transfer Station operation; * 5 facsimile terminals; * 5 data modems. Station equipment is uniformly distributed within and across the two floors of the building. There are ten (10) wiring closets per floor, and one (1) main equipment room on the first floor. See Table 1 for station summary. 2.1.3 SB1 (Large) The SB1 facility will be a single floor facility that will support: * 75 desktop IP station instruments * 10 PC client softphones * 4 audioconferencing units; * 5 analog telephones including 2 Power Failure Transfer Stations; * 2 facsimile terminals; * 4 modems. All line station equipment will be equally distributed across the single floor of the building. There will be two (2) wiring closets, and one (1) main equipment room. See Table 1 for station summary. 2.1.4 SB2 (Medium) The SB1 facility will be a single floor facility that will support: * 37 desktop IP station instruments; * 5 PC client softphones * 2 IP audioconferencing units; * 2 Analog station used as Power Failure Transfer Stations; * 2 facsimile terminals; * 2 modems. All line station equipment will be equally distributed across the single floor of the building. There will be two (2) wiring closets, and one (1) main equipment room. See Table 1 for station summary. 2.1.5 SB3 (Small) The SB3 facility will be a single floor facility that will support: * 8 Deskop IP station instruments; * 1 Analog station used as a Power Failure Transfer Station; * 1 facsimile terminal. All station equipment will be equally distributed across a single room on the main floor of the building. There will be one (1) wiring closet/equipment room. See Table 1 for station summary.


Table 1: VoiceCon Equipped Station Requirements IP Station IP Station IP Att. IP Analog Analog Fax Modem

Instrument Softphone SoftconsoleAudio-Conf. Standard PFTS Terminal Device

HQ 1040 97 3 10 21 5 12 12 RO 205 19 2 4 8 2 5 5 SB1 75 9 1 4 3 2 2 4

SB2 37 5 0 2 0 2 2 2 SB3 8 0 0 0 0 1 1 0

2.2 Equipped Voice Terminal Requirements VoiceCon requires the following mix of wired and installed desktop IP telephone instruments (Table 4). Note: Descriptions of Desktop IP individual voice terminal types can be found in RFP Section 4

Table 4: VoiceCon Desktop IP Telephone Instruments Requirements

Facility Economy Administrative Professional Executive HQ 50 140 800 50 RO 15 30 150 10 SB1 8 10 55 2 SB1 3 8 25 1 SB3 0 1 7 0

2.3 Trunk Circuit Requirements The VoiceCon HQ and RO facilities will each have a combination of local, long distance, and private network trunk circuits. The SB facilities will each have a limited number of analog trunk circuits, but all long distance calls will be routed through the HQ facility. All facilities will also have PFTS circuits. All local digital trunks must be able to support a combination of inbound DID


service and two-way CO trunk services. All long distance calls placed from a SB facility will be routed via the LAN/WAN through the HQ facility for PSTN trunk access. The following table summarizes HQ facility trunk circuit requirements for each of the four VoiceCon design configurations. Table 5: VoiceCon IPTS Network Equipped Trunk Port Requirements

VoiceCon will engineer its WAN trunk circuits to support compressed voice traffic (G.729A algorithm voice codecs) among all IPTS network facilities inter-facility voice traffic. Any additional PSTN trunk circuits required to support local survivability requirements must be identified. Necessary common equipment must be included in the system configuration and pricing proposals and identified as such. Vendor Response Requirements Confirm that the proposed IPTS network solution satisfies the stated trunk circuit requirements; support of centralized long distance trunk resources at the VoiceCon HQ facility for the SB facilities; and automatic alternate routing of calls among all VoiceCon facilities across the WAN and PSTN. Ericsson Response: The MX-ONE V.3 complies. 2.3.1 ISDN PRI Services All installed VoiceCon T-1 trunk circuits must support ISDN PRI features and functions for both local and long distance exchange carrier transmission services.

Per Incremental Location

T-1 Digital Local Inbound/Outbound

T-1 Digital Long

Distance Analog (PFTS) 2-way GS/LS

HQ 6 7 5 25

RO 2 2 2 10

SB1 1 0 2 5

SB2 0 0 2 10

SB3 0 0 1 5


Vendor Response Requirements Confirm that the proposed T-1 trunk circuit interfaces support ISDN PRI capabilities. Ericsson Response: The MX-ONE V.3 complies. 2.4 IPTS Network Growth Requirements VoiceCon anticipates that station capacity requirements at the HQ and RO facilities will increase approximately 50% for the expected installed life of the proposed IPTS network solution. Port capacity growth requirements at the SB1 and SB2 faciilties are anticipated to increase by about 20%; no growth is anticipated at the SB3 facility. Vendor Response Requirement: Confirm that the proposed IPTS solution can satisfy VoiceCon station port growth requirements and associated trunk growth requirements at its HQ, RO, SB1 and SB2 facilities without replacing any hardware equipment at time of initial system installation and cutover. Hardware additions are permissible to support incremental port interface requirements. Ericsson Response: The MX-ONE V.3 complies.


3.0 Port Interface and Traffic Handling Requirements The proposed IPTS network solution must be able to support a mix of TDM/PCM and IP ports. For traffic design engineering calculations assume the following traffic requirements:

1. The average busy hour traffic for IP desktop station users will be rated at 10 CCS @ P.01. Assume a traffic mix pattern of 30% intra-network calls, 15% outgoing local trunk calls, 25% outgoing long distance trunk calls, and 30% incoming DID trunk calls.

2. Analog telephone station busy hour traffic will be rated at 3 CCS @ P.01. Assume a traffic mix pattern of 70% inter-network calls and 30% outgoing local trunk calls. All analog telephone station calls will be subject to toll restrictions.

3. Assume that busy hour traffic is rated at 36 CCS @P.01 for each of the following port types: all PSTN and WAN trunk circuits; attendant consoles; modems; audioconferencing units; facsimile terminals; voice mail ports.

Vendor Response Requirement: The proposed system must design and engineer their system to support the above traffic assumptions. Confirm you have satisfied this requirement. Ericsson Response: The proposed MX-ONE V.3 configuration is designed to provide the traffic capacity as requested. 3.1 Circuit Switched Network Design The proposed IPTS solution must support a variety of peripheral ports and switched connections. Although it is not required to support traditional digital voice terminal equipment, the IPTS must support analog communications devices. Switched connections involving non-IP ports may be handled using a circuit switched network, media gateways/Ethernet switches, or a combination of both methods. Vendor Response Requirement: If the proposed IPTS network solution includes integrated circuit-switched hardware equipment, then briefly describe the characteristics of the offering. Include, at minimum, the following information: hardware cabinet description; CCS @P.01 rating; center stage switch and local TDM bus time slot/talk slot capacities; interswitch link capacities; all redundant design elements and level of redundancy.


Ericsson Response: Ericsson is proposing its MX-ONE Media Gateway Classic LIM to provide the required analog TDM interfaces. The MX-ONE Media Gateway Classic enables support for legacy terminals (analog and digital). The Media Gateway Classic is provided as one or two 7U subracks adapted to the 19-inch building practice that allows mounting in a standard 19-inch rack. A number of boards provide the necessary functions and interfaces. Some of the boards are necessary for core functionality while others are optional, depending on necessary interfaces, number of telephones, and traffic requirements. The following boards are included:

• ESU - Embedded Server Unit with the same software as the Telephony Server

• LSU-E - LIM Switch Unit - Ethernet • DSU - Distribution Switch Unit

A variable number of the following boards may be included depending on traffic needs, number of extensions and number of trunks:

• IPLU - IP Line Unit • TMU - Tone and Multi-party Unit • ELU34 - Extension Line Unit for analog extensions • ELU33 - Extension Line Unit for digital extensions • TLU76 - Trunk Line Unit for ISDN/QSIG • TLU77 - Trunk Line Unit for ISDN

3.2 Peer-to-Peer Communications for IP Station to IP Station Calls All two-party voice calls between IP desktop stations located at VoiceCon facilities must be handled exclusively over the LAN/WAN infrastructure without any circuit switched connections. This is a Mandatory requirement. Vendor Response Requirement: Confirm that your proposed system satisfies this Mandatory requirement. Ericsson Response: The MX-ONE V.3 complies. 3.2.1 IP Station Discovery How do IP communications devices learn about their voice VLAN, including IP


addresses, default gateways, call controller, TFTP server, QoS settings, VLANs, and other parameters. Does the proposed system solution employ proprietary protocols for IP communications devices to learn their voice VLAN or is an industry standard, such as Dynamic Host Control Protocol (DHCP) used? Ericsson Response: A Dynamic Host Configuration Protocol (DHCP) server is/can be used to provide the terminals with the following:

• IP address for the IP telephone • Subnet mask for the IP telephone • IP address for the default gateway (router) • IP address of the HTTP server (optional) • IP address and port number for the WWW proxy server

(optional) • Telephony Domain Name (optional) • VLAN identities (optional)

The phone terminals uses a Dynamic Host Configuration Protocol (DHCP) server to find the HTTP server that holds the configuration data and boot image files used in the terminals. (Client Side). The IP telephones use a configuration file to initiate parameters in the telephone. Examples of parameters that are possible to set in the configuration file are:

• which system the IP telephone shall register towards • the version of the software to be used • priority of the codecs • assignment of function keys

The file shall be stored on a software server (web server) and the IP telephone uses the http protocol to read the file. The other software files to be loaded into the IP telephone shall also be stored on the same software server. The IP address to the software server can either be distributed to the IP telephones from the DHCP server, from DNS SRV resource records or entered manually into the IP telephone. 3.2.2 IP Station Power over Ethernet (PoE) VoiceCon requires that the power option to support IP telephones conform to IEEE 802.3af Power over Ethernet (PoE) standards.


Vendor Response Requirement: Confirm that the proposed IPTS solution supports the IEEE 802.3af specification for in-line of IP telephone equipment. Describe current, future and retrospective compatibility of all proposed equipment. If 802.3af is not supported, identify the PoE implementation being proposed. Ericsson Response: The Dialog 44XX IP Telephones support PoE power class 1 (Power over Ethernet IEEE 802.3af). The telephones will automatically identify for less than 4W. 3.2.3 IP Station QoS Vendor Response Requirement: Describe the proposed IPTS solution’s capabilities to provide Layer 2 and Layer 3 QoS to IP stations to ensuring end-to-end quality of service. Include in the response what industry standards are deployed. Ericsson Response: The proposed IP Telephones supports the follow capabilities:

• QoS packet prioritization/tagging ToS/Diffserv, IEEE802.1p • VLAN support IEEE 802.1p&q

3.3 Multi-Party Conference Calls The proposed system must be able to support six party add-on conference calls among IPTS stations and off-network stations. The system must also support a minimum of three (3) off-network stations per multi-party conference call when required. The HQ IPTS must support a minimum of 20 simultaneous multi-party add-on conference calls (up to six parties per conference) and the RO IPTS a minimum of 10 simultaneous multi-party add-on conference calls (up to six parties per conference) Vendor Response Requirement: Briefly explain how multi-party add-on conference calls are handled if: 1) All parties are on-network IP stations; 2) There is a mix of on-network IP and off-network stations. The explanation should identify any and all hardware and software requirements necessary to support multi-party add-on conference call requirements. Specify if peripheral hardware equipment, e.g., conference bridge servers, is required.


Ericsson Response: The MX-ONE provides multi-party conferencing. Up to 8 end-points may be included in one conference call. End-points may include any combination of extension types (IP, Analog, Digital, Mobile Extension, Operator) and/or up to 8 trunks (IP and/or TDM). The proposed configuration is designed to provide the required capacity of 20 and 10 simultaneous 6 party conference calls. Conference calls are handle via “Virtual” Multi-Party Boards (MPU) of the MX-ONE Media Gateway. Each Media Gateway can have up to 4 “Virtual” Multi-Party Boards (MPU). Each MPU provides 24 positions for conference end-points. One position is allocated to each end-point of the conference call. For the proposed design 120 (20 X 6) positions are required or 5 “Virtual” Multi-Party Boards (MPU). 3.4 VoIP Overflow Traffic If available WAN circuits connecting the HQ, RO and all SB facilities are busy, call admission control levels are reached, or QoS levels are not satisfied on-network voice traffic must be able to automatically overflow to PSTN trunk circuits. Vendor Response Requirement: Confirm that your proposed communications system supports overflow of voice traffic across VoiceCon locations if WAN links are not available or conditions are not acceptable. Also indicate if overflow traffic can revert back to the WAN if conditions permit. Ericsson Response: The proposed MX-ONE solution is a single fully transparent system that supports all locations as if they were co-located. In the event there is a WAN disturbance between locations, inter-location traffic can be handled by dialing the full 10-digit number rather than the 4 or 5 digit extension number. Routing is then automatically done by the MX-ONE. When there is a WAN failure the MX-ONE will convert the number and use the PSTN to set up the connection. If the WAN comes back in operation the next call will use the WAN again. The MX-ONE would support the requested overflow between different MX-ONE systems via its Least Cost Routing and Private Networking facilities.


3.5.0 Port Interface Circuit Cards For each of the following port types, provide a brief description of the proposed port interface circuit card(s) and/or media gateway equipment included with the proposed IPTS to support analog, digital, and IP ports. Include in the descriptions below the number of port interface terminations for each port circuit card, and the number of available gateway channels for each media gateway unit. 3.5.1 IP Telephones (desktop instrument and PC client softphones, including Attendant Console Position) & IP Audioconferencing Units Vendor Response Requirement: Provide a brief description how all IP telephone types are logically and physically supported by the common control call telephony server. If direct call control signaling via the Ethernet LAN/WAN is not supported identify all intermediary carrier, signaling interface and/or media gateway equipment that is required. Ericsson Response: IP terminals are logically support by the MX-ONE. The MX-ONE Telephony Server provides the gatekeeper function, and the MX-ONE Media Gateway provides the gateway functions. The MX-ONE provides the call control and telephony features toward the IP terminals. IP terminals are physically supported via an Ethernet Switch using standard CAT5 cabling. 3.5.2 Analog telephones Vendor Response Requirement: Provide a brief description how analog telephones are logically and physically supported by the common control call telephony server, identifying all intermediary hardware elements necessary for control signaling transmission. Specify the number of circuit terminations per circuit board/module/media gateway.


Ericsson Response: Analog telephones interfaces can be provided by the Media Gateway, Media Gateway Classic. Each Media Gateway provides 4 analog TDM interfaces. Each Media Gateway Classic can be configured for up to 480 analog TDM interfaces. Per 32 analog extensions one ELU 34 board is placed in the Media Gateway Classic. The analog interfaces are physically connected by one twisted pair cable. The DRG22i provides analog extension (SIP) integration over IP. DRG22i can be registered directly towards the MX-ONE™ Telephony System gatekeeper. 3.5.3 Facsimile terminal Vendor Response Requirement: Provide a brief description how facsimile terminals are logically and physically supported by the common control call telephony server, identifying all intermediary hardware elements necessary for control signaling transmission. Specify the number of circuit terminations per circuit board/module/media gateway. Ericsson Response: Facsimile terminals can be connect to the analog telephones interfaces as indicated in 3.5.2. Analog telephones. In this case, Facsimile terminals are physically connected by one twisted pair cable. Facsimile terminals may also be used with the Ericsson Digital Residential Gateway (DRG22i). The DRG22i provides analog extension integration over IP. DRG22i can be registered directly towards the MX-ONE™ Telephony System gatekeeper. When connected to MX-ONE™, extensions on the DRG22i will be supported G3 fax (based on G.711) usage. 3.5.4. Modem Vendor Response Requirement: Provide a brief description how modem terminals are logically and physically supported by the common control call telephony server, identifying all


intermediary hardware elements necessary for control signaling transmission. Specify the number of circuit terminations per circuit board/module/media gateway. Ericsson Response: Modems can be connected to the analog telephone interfaces as indicated in 3.5.2. Analog telephones In this case, Modems are physically connected by one twisted pair cable. 3.5.5 Power Failure Transfer Station (PFTS) Vendor Response Requirement: Provide a brief description how analog telephone instrument Power Failure Transfer Stations (PFTSs) are logically and physically supported by the common control call telephony server, identifying all intermediary hardware elements necessary for control signaling transmission. Specify the number of circuit terminations per circuit board/module/media gateway. Ericsson Response: Power Failure Transfer Station are supported by a 578 Porta Systems Linebacker™Power Fail Transfer Unit. The 578 Porta Systems Linebacker™ Power Fail Transfer Unit automatically activates the instant of a power outage or system alarm. Dial tone is maintained to eight pre-designated lines and calls in progress remain uninterrupted—even after service is restored and the circuits are returned to PBX control - a feature not always available in other such units. 3.5.6 GS/LS CO Trunk Vendor Response Requirement: Provide a brief description how GS/LS CO trunk circuits are logically and physically supported by the common control call telephony server, identifying all intermediary hardware elements necessary for control signaling transmission. Specify the number of circuit terminations per circuit board/module/media gateway. Ericsson Response: GS/LS CO Trunks are supported by the Media Gateway Classic LIM. Each trunk card supports 8 ports. Either GS or LS can be used.


3.2.7 DS1/T-1 Carrier Interface Trunk Vendor Response Requirement: Provide brief description how DS1-based T-1 carrier trunk circuits are logically and physically supported by the common control call telephony server, identifying all intermediary hardware elements necessary for control signaling transmission. Specify the number of circuit terminations per circuit board/module/media gateway. Ericsson Response: Each MX-ONE Media Gateway provides 8 ISDN TDM interfaces. Each MX-ONE Media Gateway Classic can be configured for up to 8 ISDN TDM interfaces. 3.2.8 Other Trunk Interfaces VoiceCon may need at some future time additional analog trunk interfaces, specifically Auxiliary, FX, and E&M Tie Line. Vendor Response Requirement: Provide a brief description of how additional analog trunk interface requirements can be logically and physically supported by the common control call telephony server, identifying all intermediary hardware elements necessary for control signaling transmission. Specify the number of circuit terminations per circuit board/module/media gateway. Ericsson Response: The Media Gateway Classic LIM would provide the support for additional analog trunk interfaces.


4.0.0. Voice Terminal Instruments The proposed communications system must be able to support a mix of analog and IP communications devices. VoiceCon will provide its own analog telephone instruments, fax terminals, and modems. 4.1 Regulation Requirements All single- and multi-line IP phones will be manufactured in accordance with Federal Communication Commission hearing aid compatibility technical standards contained in Section 68.316. and the Telecommunication Act of 1996. Vendor Response Requirement: Confirm the proposed telephone equipment satisfies these requirements Ericsson Response: The Ericsson IP Telephones comply with the follow:

• Regulatory compliance - FFC part 15 and 68 • Hearing aid support according to ITU-T P.370 (8/96) and FCC

Part 68, subpart D American. • Acoustic shock protection ETS 300 245-2.

4.2 Desktop IP Telephone Instruments VoiceCon has a requirement for several types of desktop IP telephone instruments:

• Economy • Administrative • Professional • Executive

4.2.1 Economy Desktop IP Telephone Instrument The Entry model will be used in common areas. It should have, at minimum, the following design attributes and features/functions:

• 12 key dial pad • Single line appearance • Hold button • G.711/G.729 voice codecs • Auto Self Discovery/DHCP • Echo Canceller


• IEEE 802.af POE support Vendor Response Requirement: Confirm that your proposed Economy model satisfies all of the stated requirements and provide a brief product description that includes an illustration/ photograph (PPT format, only) of the instrument. Indicate in your response any and all requirements not satisfied. Ericsson Response: The proposed model is the Dialog 4420 IP Basic.

12 key dial pad Included Single line appearance Included Hold button Included G.711/G.729 voice codecs Included Auto Self Discovery/DHCP Included Echo Canceller NA – monitor

speaker IEEE 802.af POE support Included

Dialog 4420 IP Basic is positioned as the entry-level IP telephone primarily intended for use in non communications-intensive areas like office receptions, general meeting/service areas, manufacturing and retail floors. The Dialog 4420 IP Basic bears all the standard features and functions to meet the voice communications needs of business users. It comes with an embedded switch that allows a single LAN connection to be shared with the desktop computer. Keys

6 programmable keys 12 function keys with LED

Features Telephone

Emergency call support Fixed number assignment Ethernet switch (2 ports) 10/100 Mbits/s (autosense) Monitor speaker Mute function Volume control Programmable ring tones Speed dialing Phone management via web interface Remote firmware upgrade Hearing aid support

VoIP


DHCP RTCP, IETF RCF 3550 QoS packet prio/tagging IEEE 802.1p VLAN support IEEE 802.1p&q Codecs: G.711, G.729a, G.729ab, G.723.1 H.323 V4 Branch office survivability support SIP support

Miscellaneous Color: Light grey or dark grey Dimensions (HxWxL) : 102x240x234 mm Tone: 10 ringer tones (max. volume >72dBA) Hearing Aid Compatibility: ITU-T P.370 (8/96) and FCC; Part 68, subpart D American Acoustic shock protection: ETS 300 245-2 EU RoHS directive 2002/95/EC compliant

4.2.2 Administrative Desktop IP Telephone Instrument The Administrative model will be used by station users who have executive management group call answering and coverage responsibilities. It should have, at minimum the following design attributes and features/functions:

• 12 key dial pad • Sixteen (16) programmable line/feature keys with soft label/status

indicators • G711, G729 and wideband, e.g., G.722, voice codecs • Auto Self Discovery/DHCP • Echo Canceller • QoS Support (802.1p/Q, DiffServ) • Hold key • Last Number Redial key • Release key • Message Waiting/Call Ringing indicator(s) • Full Duplex Speakerphone • Speaker/Mute key • Volume Control keys/slide • High resolution, backlit, monochrome grayscale pixel-based, graphical

display screen with four (4) associated context sensitive soft feature labels (key, cursor, or navigator control)

• LDAP access • Stored Call Data (Last 10 numbers dialed/Last 10 incoming call

numbers) • Integrated Ethernet switch and two (2) RJ-45 connector interface ports

for 10/100 Mbps connectivity • Headset interface • IEEE 802.af POE support


The Administrative model must also be capable of supporting optional add-on key modules if an additional 12 programmable line/feature keys with soft label/indicator status is required at some future time. Vendor Response Requirement: Confirm that your proposed Administrative model satisfies all of the stated requirements. Provide a brief product description that includes an illustration/photograph (PPT format, only) of the instrument. Indicate in your response any and all requirements not satisfied. State which required feature-specific keys are not available, but softkey feature access can be used as an alternative. Ericsson Response: The proposed model is the Dialog 4425 IP Vision V2.

12 key dial pad Included Sixteen (16) programmable line/feature keys with soft label/status indicators

No soft label

G711, G729 and wideband, e.g., G.722, voice codecs

No G.722

Auto Self Discovery/DHCP Included Echo Canceller Hands-free speaking

with full duplex and Acoustic Echo Cancellation (AEC)

QoS Support (802.1p/Q, DiffServ) Included Hold key Included Last Number Redial key Included Release key Included Message Waiting/Call Ringing indicator(s) Included Full Duplex Speakerphone Included Speaker/Mute key Included Volume Control keys/slide Included High resolution, backlit, monochrome grayscale pixel-based, graphical display screen with four (4) associated context sensitive soft feature labels (key, cursor, or navigator control)

Included

LDAP access ComOrg Corporate Directory

Stored Call Data (Last 10 numbers dialed/Last 10 incoming call numbers)

Included

Integrated Ethernet switch and two (2) RJ-45 connector interface ports for 10/100 Mbps connectivity

Included


Headset interface Included IEEE 802.af POE support Included

The Dialog 4425 IP Vision is a multi-featured IP phone supporting advanced system functions. It is ideal for demanding and executive office usage. The adjustable contrast and viewing angle of the six-row back-lit graphical display, allow users to adjust the phone for all types of environment and lighting conditions. Telephone features and system functions are easily accessible using an intuitive display menu and soft-keys. The menu gives access to a phonebook, enabling dial-by-name. The call list accessed via the menu includes logged call information for all incoming and outgoing calls and offers a user-friendly scroll-and-dial function. When absent from the office, users can set up diversion options and messages. Intranet/Internet access to WAP-based content is provided using the phone display. From the phone menu, users can access WAP content with relevant company information, e.g. time tables, etc.. WAP functionality also enables dialing from the central phone directory. The high-quality, hands-free speaking feature makes the Dialog 4425 ideal for telephone meetings and conference calls in small meeting rooms. An integrated headset port allows a headset to be plugged directly into the phone, with toggling between the headset and handset controlled by a dedicated key. A connection for an external bell or busy signal is available with the Option Unit. The Dialog 4425 features 20 function keys. In addition, up to four extra key panels with 17 function keys each can be connected to the phone. All programmable function keys have associated LEDs and can be labeled by users. Keys

Programmable keys Function keys with LED 4 additional Key Panels (17 keys)

Option Unit Power

Power over Ethernet (PoE), IEEE 802.3af power class 1 48 V DC Average consumption using PoE 2 W

Power adapter (optional) input: 100-230 V, Output:24 V AC Average consumption using power adapter 3 W

Graphical display Backlit Adjustable contrast Internet browser


Central corporate phone book Time and date Adjustable viewing angle

Telephone, features Emergency call support Fixed number assignment 2 port Ethernet switch, 10/100 BaseT/TX (autosense) Monitor speaker Hands free with full duplex and Acoustic Echo Cancellation (AEC) Mute function Volume control Programmable ring tones (max. volume >72dBA) - 10 Speed dialing Integrated web server for maintenance Firmware download from a web server Support for AC/AC external power supply Increased hearing level for users with impaired hearing Contacts (personal phonebook) 1000

VoIP, features DHCP RTCP, IETF RCF 3550 Quality of Service IEEE 802.1p&q and Diffserv VLAN support IEEE 802.1p&q Support for codecs: G.711, G.729a, G.729ab, G.723.1 H.323 V4 Branch office survivability support Security authentication (IEEE 802.1x) DNS SRV resource record support

Regulatory compliance Acoustic chock protection: ETS 300 245-2 Hearing Aid Compatibility: ITU-T P.370 (8/96) and FCC; Part 68, subpart D American. EU RoHS directive 2002/95/EC

4.2.3 Professional Desktop IP Telephone Instrument The Professional model will be used by VoiceCon managers. It should have, at minimum the following design attributes and features/functions:

• 12 key dial pad • Six (6) programmable line/feature keys with soft label/status

indicators • G711, G729 and wideband voice codecs • Auto Self Discovery/DHCP • Echo Canceller • QoS Support (802.1p/Q, DiffServ)


• Hold key • Last Number Redial key • Release key • Message Waiting/Call Ringing indicator(s) • Full Duplex Speakerphone • Speaker/Mute key • Volume Control keys/slide • High resolution, backlit, monochrome grayscale pixel-based, graphical

display screen with four (4) associated context sensitive soft feature labels ((key, cursor, or navigator control)


numbers) • Integrated Ethernet switch and two (2) RJ-45 connector interface ports

for 10/100 Mbps connectivity • Bluetooth interface for wireless headset • USB interface • IEEE 802.af POE support

The Professional model must also be capable of supporting the following integrated feature/functions if required at some future time:

• Gigabit (10/100/1000 Mbps) Ethernet connectivity • Embedded Web-browser applications

Vendor Response Requirement: Confirm that your proposed Professional model satisfies the stated requirements and provide a brief product description that includes an illustration or photograph (PPT format, only) of the instrument. Indicate in your response any and all requirements not satisfied. State which required feature-specific keys are not available, but softkey feature access can be used as an alternative. Ericsson Response: The proposed model is the Dialog 4425 IP Vision V2. Please refer to 4.2.2 - Administrative Desktop IP Telephone Instrument.

12 key dial pad Included Six (6) programmable line/feature keys with soft label/status indicators

No soft label

G711, G729 and wideband voice codecs No G.722 Auto Self Discovery/DHCP Included Echo Canceller Hands-free speaking



QoS Support (802.1p/Q, DiffServ) Included Hold key Included Last Number Redial key Included Release key Included Message Waiting/Call Ringing indicator(s) Included Full Duplex Speakerphone Included Speaker/Mute key Included Volume Control keys/slide Included High resolution, backlit, monochrome grayscale pixel-based, graphical display screen with four (4) associated context sensitive soft feature labels ((key, cursor, or navigator control)

Included



Included

Integrated Ethernet switch and two (2) RJ-45 connector interface ports for 10/100 Mbps connectivity

Included

Bluetooth interface for wireless headset Not Included USB interface Not Included IEEE 802.af POE support Included Gigabit (10/100/1000 Mbps) Ethernet connectivity

Integrated Ethernet switch - 10/100 Mbps connectivity

Embedded Web-browser applications Included - WAP 4.2.4 Executive Desktop IP Telephone Instrument The Professional model will be used by VoiceCon’s executive management team. It should have, at minimum the following design attributes and features/functions:

• 12 key dial pad • Twelve (12) programmable line/feature keys with soft label/ status

indicators • G711, G729 and wideband voice codecs • Auto Self Discovery/DHCP • Echo Canceller • QoS Support (802.1p/Q, DiffServ) • Hold key • Last Number Redial key • Release key • Message Waiting/Call Ringing indicator(s) • Full Duplex Speakerphone


• Speaker/Mute key • Volume Control keys/slide • High resolution, backlit, color pixel-based, graphical display screen

with four (4) associated context sensitive soft feature lablels (key, cursor, or navigator control)


numbers) • Integrated Ethernet switch and two (2) RJ-45 connector interface

ports; 10/100 Mbps connectivity • Headset interface (Bluetooth is also acceptable) • IEEE 802.af POE support

The Professional model must also be capable of supporting the following integrated feature/functions if required at some future time:

• Gigabit (10/100/1000 Mbps) Ethernet connectivity • Embedded Web-browser applications

Vendor Response Requirement: Confirm that your proposed Executive model satisfies the stated requirements and provide a brief product description that includes an illustration or photograph (PPT format, only) of the instrument. Indicate in your response any and all requirements not satisfied. State which required feature-specific keys are not available, but softkey feature access can be used as an alternative. Ericsson Response: The proposed model is the Dialog 4425 IP Vision V2. Please refer to 4.2.2 - Administrative Desktop IP Telephone Instrument. 12 key dial pad Included Twelve (12) programmable line/feature keys with soft label/ status indicators

No soft label

G711, G729 and wideband voice codecs No G.722 Auto Self Discovery/DHCP Included Echo Canceller Hands-free speaking


QoS Support (802.1p/Q, DiffServ) Included Hold key Included Last Number Redial key Included Release key Included Message Waiting/Call Ringing indicator(s) Included


Full Duplex Speakerphone Included Speaker/Mute key Included Volume Control keys/slide Included High resolution, backlit, color pixel-based, graphical display screen with four (4) associated context sensitive soft feature lablels (key, cursor, or navigator control)

No Color



Included

Integrated Ethernet switch and two (2) RJ-45 connector interface ports; 10/100 Mbps connectivity

Included

Headset interface (Bluetooth is also acceptable)

Included

IEEE 802.af POE support Included Gigabit (10/100/1000 Mbps) Ethernet connectivity

Integrated Ethernet switch - 10/100 Mbps connectivity

Embedded Web-browser applications Included - WAP 4.2.5 Desktop IP Telephone Instrument Web-browser Functionality Vendor Response Requirement: Provide a brief description of embedded Web-browser functionality for the proposed Professional and Executive IP desktop telephone instrument models. Include the following information in your response: browser protocol (HTML, XML, WAP, Java, LDAP, Stimulus, other); station user interaction (touchscreen and/or keypad control cursor control; ability to place calls during active screen applications; screen saver option; standard and optional applications (visual mailbox; personal directory and calendar; web page access and display; visual alerts; audio alerts; et al). Ericsson Response: Intranet/Internet access to WAP-based content is provided using the phone display. From the phone menu, users can access WAP content with relevant company information, e.g. time tables, etc.. WAP browser with easy access to WAP portals, enabling fast access to WML based Internet/intranet pages or tables


4.2.5 Desktop Instrument Options and Add-on Modules Vendor Response Requirement: Provide a brief description of all hardware/software options and/or add-on modules currently available with the proposed Economy, Administrative, Professional, and Executive models. Options/modules should include key modules, display modules, BlueTooth interface, USB interface, Gigabit Ethernet connectors, et al. necessary to satisfy the above telephone model requirements. Indicate the specific models that support the individual option/module. Ericsson Response: The following modules are supported by the proposed Dialog 4425 IP Vision V2, and the optional Dialog 4422 IP Office V2 telephones. Option Unit The Option Unit is designed to enhance the Dialog 4000 series telephones and enables connection of a busy signal and external Bell. Extra key panel with 17 keys 4.2.6 SIP Compatibility It is desirable, but not required, that the proposed desktop IP telephone instruments conform to current SIP standards and specifications at time of installation and system cutover. If any or all the proposed instrument models do not support natively embedded SIP capabilities as proposed, then it is acceptable that a firmware download upgrade be available when requested. Vendor Response Requirement Indicate which of the proposed telephone models are native SIP or can be reprogrammed via a SIP firmware download when requested by VoiceCon. Identify which proposed models cannot currently be reprogrammed for SIP support at this time. Ericsson Response: The proposed Dialog 4425 IP Vision V2 and Dialog 4420 IP Basic telephones can support either H.323 or SIP depending up on the setting in the “configuration file”. 4.3 PC Client Softphone A PC client softphone will be used by station users and attendant operators as their primary desktop voice terminal. It is desirable, but not mandatory,


that the PC client softphone application conform to SIP standards and specifications. Vendor Response Requirement Indicate if the proposed softphone solution satisfies the stated SIP requirement. If the proposed softphone solution does not support SIP, does your product portfolio currently include a PC client softphone solution that does? Ericsson Response: Ericsson is proposing its Communication Organizer Personal Assistant-PC (PA-PC) softphone. PA-PC is a H.323 end-point. At this time a SIP softphone is not available. 4.3.1 Desktop Station User Application The proposed PC client softphone solution must be able to support a minimum of six programmable line appearances, integrated system and personal directories with search/dial-by-name capabilities, and functions comparable to the proposed Professional model. The softphone solution must also be able to support a peripheral headset. Vendor Response Requirement Confirm that the proposed softphone solution satisfies the stated requirements and provide a brief product description that includes a illustration/photograph (PPT format, only) that depicts the look and feel of an active call screen display. Ericsson Response: Ericsson is proposing its Communication Organizer Personal Assistant-PC (PA-PC) softphone.


Communication Organizer Personal Assistant-PC offers many benefits that directly address the business needs of today’s enterprises:

• Enables a mobile workforce by allowing employees to work effectively in the office, at remote locations or from home using the same extension and business class telephony features

• Lets employees manage their means of communication based on specified activities, and choice of format and device for communications

• Improves productivity by providing single-source access to telephony, directories and messaging features

• Click-to-dial calls—just click the name of the person to be called.

• Single-number access enhances communications between employees and customers regardless of location

• Hotkey dialing from other applications • Instant messages to any other Communication Organizer user • Mobile phone control via Bluetooth™ interface

Communication Organizer Personal Assistant-PC, a Microsoft Windows-based client application, provides the following functionality:

• VoIP • Activity management • Monitor feature (Administrative Assistant) • Business Class telephony • Support of an array of directories to search and dial • Instant messaging • Intelligent routing of calls

o Presence, location, calendar, activity driven o Based on preferred communication type: Voice, IM, or e-

mail • Contact list management • Server-based calendar integration with • Exchange/Outlook and Domino/Lotus Notes integration Add-

ins for access to PA-PC features directly from Outlook and Notes

• Call log • Up to six simultaneous calls are supported

Peripheral headsets are supported. Pictures are included in file “03_03_Ericsson Phone Pictures - VoiceCon 2007.ppt”


4.3.1.1 Teleworker Station User Application The proposed PC client softphone solution may also be used by some station users as a teleworker voice terminal outside the VoiceCon facility environment. Vendor Response Requirement Confirm that the proposed customer premises softphone solution can be used as am off-premises teleworker voice terminal option . Indicate in your response if any optional hardware and/or software requirements are required to support teleworker mode operations for deployment in a home, hotel, or office environment. Ericsson Response: Ericsson is proposing its Communication Organizer Personal Assistant-PC (PA-PC) softphone. Communication Organizer Personal Assistant-PC offers many benefits that directly address the business needs of today’s enterprises:

• Enables a mobile workforce by allowing employees to work effectively in the office, at remote locations or from home using the same extension and business class telephony features





• Hotkey dialing from other applications • Instant messages to any other Communication Organizer user • Mobile phone control via Bluetooth™ interface


Communication Organizer Personal Assistant-PC, a Microsoft Windows-based client application, provides the following functionality:

• VoIP • Activity management • Monitor feature (Administrative Assistant) • Business Class telephony • Support of an array of directories to search and dial • Instant messaging • Intelligent routing of calls

o Presence, location, calendar, activity driven o Based on preferred communication type: Voice, IM, or e-

mail • Contact list management • Server-based calendar integration with • Exchange/Outlook and Domino/Lotus Notes integration

Add-ins for access to PA-PC features directly from Outlook and Notes

• Call log • Up to six simultaneous calls are supported

Pictures are included in file “03_Ericsson Phone Pictures - VoiceCon 2007.ppt” 4.3.2 Soft Attendant Console Attendant operator console requirements are to be satisfied using a PC client softphone application. The attendant console application should include several distinct display fields, such as: incoming call queue and active caller information; release loop keys; feature/function keys; direct station selection (contact directory)/ busy lamp field; trunk groups; minor/major alarms; and messaging. GUI capabilities must support drag & click operations. At minimum the following information and data must be available in the softphone screen display: # Calls in queue; Call appearance status; Calling/called party number/name; Trunk ID; COS/COR; # Calls waiting; call coverage status; time/date, call duration; text messages; alarm notification Vendor Response Requirement Confirm the proposed softphone solution satisfies the stated requirements, and provide a brief description of the proposed softphone solution when programmed for attendant console operation. Include in the response a representative illustration or photograph (PPT format, only) that conveys the look and feel of an active call console display screen.


Ericsson Response: Ericsson is proposing the MX-ONE™ Communication Organizer Operator Assistant. Communication Organizer Operator Assistant provides the ultimate in fast, flexible and powerful call handling. Ericsson MX-ONE™ Communication Organizer Operator Assistant offers many benefits that directly address the business needs of today’s enterprises:

• Prompt location of people for quick processing of calls • IP-based for flexible configurations and reduced hardware

costs • Activity management handling • Instant message capability for communication with other

Communication Organizer users • Rapid learning curve; new operators learn this application

faster than traditional consoles • Fast, efficient call handling allows callers to reach the right

person the first time • Improved caller service for increased customer satisfaction • Access to all directory information • Progressive searches for all directory search fields • User-customizable workspace • External directory read access using LDAP V3

4.4 IP Audio Conferencing Unit VoiceCon requires a limited number of desktop audio conferencing units with multidirectional, full duplex speakerphone operation. The unit must be native IP. Vendor Response Requirement Provide a brief description of the proposed IP audio conferencing unit and include in the response an illustration or photograph (PPT format, only) of the unit. Ericsson Response: Ericsson is proposing the Polycom SoundStation IP 4000 SIP VOIP Conference Phone. Designed for offices or small to medium sized conference rooms, the SoundStation IP 4000 SIP provides remarkable room coverage. You can speak naturally from up to 10-feet away from a microphone and


still be heard clearly on the far end of the call. Optional extension microphones offer an increased pickup for larger rooms. Plus, with gated microphone technology, echo and background noise is almost entirely eliminated. Product Features:

• Allows simultaneous natural conversation – the industry’s best full duplex

• Speak up to 10-feet from a microphone and be heard clearly on the far end of the call

• Optional extended microphones expand coverage to 20 x 30 feet for larger conference rooms

• Gated microphones nearly eliminate distracting echo and room noise

• Downloadable upgrades as standards develop and protocols evolve

• 360-degree room coverage using a powerful, digitally-tuned custom speaker and three sensitive microphones for uniform coverage of a small to medium-sized conference room or office

• 248 X 68 pixel resolution LCD makes menu navigation easy Pictures are included in file “03_Ericsson Phone Pictures - VoiceCon 2007.ppt” 4.8 Other IP Telephone Instruments Please provide a brief description of additional IP desktop telephone instrument models included in your portfolio other than the models used to satisfy the Economy, Administrative, Professional, and Executive requirements. Information should include, at minimum, fixed feature/function, number of programmable line/feature keys, display description (if applicable), type of speakerphone (if appplicable), and any other information you deem vital. Include an illustration/photograph (PPT format, only) for each of these additional models. Ericsson Response: Dialog 4422 IP Office highlight summary:

• 2-port Ethernet switch (for sharing a LAN cable/port with a computer)

• User mobility (log-on and call) • Registration with a default number function (the phone cannot

be logged off) • Monitoring functionality support • Emergency calls with location information • Hands-free speaking feature with full duplex and Acoustic Echo

Cancellation (AEC)


• Monitor speaker • Headset port (with dedicated headset switching key) • Power over LAN support (IEEE 802.3af compliant) • User settings via web browser • Hearing-impaired support • Acoustic shock protection • Flexible function keys • Central storage of user settings for function keys • Call list (local) • Multi-codec support (G.711, G729a, G.729ab, G723.1) • Multi-language support • QoS support - (includes QoS statistics available via web

browser) • DHCP • RTCP - IETF RFC 3550 • QoS packet prioritization/tagging - ToS/Diffserv, IEEE802.1p • VLAN support IEEE802.1p&q • Ethernet switch 10/100 Mbit/s (autosense) • H.323 V4 • Branch office survivability support with the Enterprise Branch

Gateway (EBG) • Option Unit support (for connection of external bell and/or

busy signal) • Six-row graphical display with adjustable contrast • Up to 10 programmable function keys • Support for 1 key panel with 17 additional function keys

Pictures are included in file “03_Ericsson Phone Pictures - VoiceCon 2007.ppt” In addition to the current Dialog 44xx models, Ericsson will be releasing the new Dialog 5000 IP Premium series IP terminals. The first model is expected to be released in early Q2, 2007. The Dialog 5000 IP Premium is a full-feature enterprise-class telephone that provides a large backlit graphics color display with 8 programmable self –labeling keys, six intuitive call state sensitive soft keys, superior sound quality, and XML browser. The Dialog 5000 IP Premium is ideal for any enterprise executives and managers.


5.0 Call Processing Features The proposed communications system should have a robust list of call processing features supporting station user, attendant, and system operations. 5.1 Station User Features It is required that the proposed communications system support the following list of station user features. Definitions for most listed features may be found in PBX Systems for IP Telephony (2002), written by Allan Sulkin and published by McGraw-Hill Professional. Table 9 Station User Features

STATION USER FEATURES ADD-ON CONFERENCE (6 party or more) Included

AUTOMATIC CALLBACK Included

AUTOMATIC INTERCOM Included

BRIDGED CALL APPEARANCE Included

CALLBACK LAST INTERNAL CALLER Included

CALL COVERAGE (PROGRAMMED) Included

INTERNAL & EXTERNAL CALL PROGRAMMING Included

TIME OF DAY/DAY OF WEEK CALL PROGRAMMING Optional

ANI/DNIS/CLID CALL PROGRAMMING

INTERNAL CALLER ID PROGRAMMING

CALL FORWARDING - ALL CALLS Included

CALL FORWARDING - BUSY/DON'T ANSWER Included

CALL FORWARDING - FOLLOW-ME Included

CALL FORWARDING - OFF-PREMISES Included

CALL FORWARDING: RINGING Included

CALL HOLD Included

CALL PARK Included

CALL PICKUP - INDIVIDUAL Included

CALL PICKUP - GROUP Included

CALL TRANSFER Included

CALL WAITING Included

CONSECUTIVE SPEED DIALING Included

CONSULTATION HOLD Included

CUSTOMER STATION REARRANGEMENT Included

DIAL BY NAME Included

DISCRETE CALL OBSERVING Included

DISTINCTIVE RINGING Included

DO NOT DISTURB Included

ELAPSED CALL TIMER Included

EMERGENCY ACCESS TO ATTENDANT Included

EXECUTIVE ACCESS OVERRIDE Included


STATION USER FEATURES EXECUTIVE BUSY OVERRIDE Included

FACILITY BUSY INDICATION Included

GROUP LISTENING Included

HANDS-FREE DIALING Included

HANDS-FREE ANSWER INTERCOM Included

HELP INFORMATION ACCESS

HOT LINE Included

INCOMING CALL DISPLAY Included

INDIVIDUAL ATTENDANT ACCESS Included

INTERCOM DIAL Included

LAST NUMBER REDIALED Included

LINE LOCKOUT Included

LOUDSPEAKER PAGING ACCESS Optional

MALICIOUS CALL TRACE Included

MANUAL INTERCOM

MANUAL ORIGINATING LINE SERVICE Included

MEET ME CONFERENCING (6-Party or more) Optional

MESSAGE WAITING ACTIVATION Included

MULTI-PARTY ASSISTED CONFERENCE w/SELECTIVE CALL DROP Optional

MUSIC ON HOLD Included

OFF-HOOK ALARM Included

PADLOCK Included

PAGING/CODE CALL ACCESS Included

PERSONAL CO LINE (PRIVATE LINE) Included

PERSONAL SPEED DIALING Included

PERSONALIZED RINGING Included

PRIORITY CALLING

PRIVACY - ATTENDANT LOCKOUT

PRIVACY - MANUAL EXCLUSION Included

RECALL SIGNALING Included

RINGER CUT-OFF Included

RINGING TONE CONTROL Included

SAVE AND REDIAL Included

SECONDARY EXTENSION FEATURE ACTIVATION Included

SEND ALL CALLS Included

SILENT MONITORING Included

STEP CALL

STORE/REDIAL Included

SUPERVISOR/ASSISTANT CALLING Included

SUPERVISOR/ASSISTANT SPEED DIAL Included

TEXT MESSAGES Included

TIMED QUEUE

TRUNK FLASH Included

TRUNK-TO-TRUNK CONNECTIONS Included

WHISPER PAGE


Vendor Response Requirement Confirm that the proposed communications system supports each of the above listed station user features. Identify any and all features that are not included as part of the standard call processing software generic package. Identify any and all of the listed features that require additional hardware and/or software, e.g., CTI application server, because they are not included as part of the standard generic software package. Ericsson Response: Ericsson has inserted a column in the table and indicated whether the feature is included/available, or if the feature is optional/available. Optional features will require additonal hardware. A blank indicates the feature is not available. The following features are not available. Call Coverage (Programmed) Ani/Dnis/Clid Call Programming Internal Caller Id Programming Help Information Access Manual Intercom Priority Calling Privacy - Attendant Lockout Step Call Timed Queue Whisper Page Please note that individual feature usage will depend upon the client device. 5.1.1 Additional Station User Features Vendor Response Requirement Provide a listing of proposed standard generic software station user features that are not included in Table 9 that VoiceCon may find of use and benefit.


Ericsson Response: Some additional noteworthy features are provided below.

• Repeated Individual Deflection • Personal Number • Boss-Secretary • Call List (Call log) • Delayed Hot Line • Triple Access Line • Parallel Ringing • Single Number Indication (SNI)

5.2 Attendant Operator Features It is required that the proposed communications system support the following list of attendant operator features. Definitions for most listed features may be found in PBX Systems for IP Telephony (2002), written by Allan Sulkin and published by McGraw-Hill Professional. Table 10 Attendant Operator Features

ATTENDANT OPERATOR FEATURES AUTO-MANUAL SPLITTING Included

AUTO-START/DON'T SPLIT Included

BACK-UP ALERTING Included

BUSY VERIFICATION OF TERMINALS/TRUNKS Included

CALL WAITING Included

CAMP-ON Included

CONFERENCE Included

CONTROL OF TRUNK GROUP ACCESS

DELAY ANNOUNCEMENT Included

DIRECT STATION SELECTION w/BLF

DIRECT TRUNK GROUP SELECTION Included

DISPLAY Included

INTERCEPT TREATMENT Included

INTERPOSITION CALL & TRANSFER Included

INTRUSION (BARGE-IN) Included

OVERFLOW Included

OVERRIDE OF DIVERSION FEATURES Included

PAGING/CODE CALL ACCESS Included

PRIORITY QUEUE Included

RECALL Included

RELEASE LOOP OPERATION Included

SERIAL OPERATION Included

STRAIGHT FORWARD OUTWARD COMPLETION Included


ATTENDANT OPERATOR FEATURES THROUGH DIALING Included

TRUNK-TO-TRUNK TRANSFER Included

TRUNK GROUP BUSY/WARNING INDICATOR

TRUNK ID Included

Vendor Response Requirement Confirm that the proposed communications system supports each of the above listed attendant operator features. Identify any and all features that are not included as part of the proposed standard generic software feature package. Identify any and all features that require additional hardware and/or software, e.g., CTI application server, not standard with the proposed system model(s). Ericsson Response: Ericsson has inserted a column in the table and indicated whether the feature is included/available, or if the feature is optional/available. A blank indicates the feature is not available. 5.2.1 Additional Attendant Operator Features Vendor Response Requirement Provide a listing of proposed standard generic software attendant operator features that are not included in Table 10 that VoiceCon may find of use and benefit. Ericsson Response: Ericsson MX-ONE™ Communication Organizer Operator Assistant provides the ultimate in fast, flexible and powerful call handling.


Ericsson MX-ONE™ Communication Organizer Operator Assistant offers many benefits that directly address the business needs of today’s enterprises:

• Prompt location of people for quick processing of calls • IP-based for flexible configurations and reduced hardware

costs • Activity management handling

Through the CalMgr interface, the Operator Assistant Workstation creates, modifies, and deletes activity entries for any user, or all users belonging to the same department and/or sub-departments of a given user.

• Instant message capability for communication with other Communication Organizer users

• Rapid learning curve; new operators learn this application faster than traditional consoles

• Fast, efficient call handling allows callers to reach the right person the first time

• Improved caller service for increased customer satisfaction • Access to all directory information • Progressive searches for all directory search fields • User-customizable workspace • External directory read access using LDAP V3 • Notepad for message taking during calls

5.3 System Features It is required that the proposed communications system support the following list of system features. Definitions for most listed features may be found in PBX Systems for IP Telephony (2002), written by Allan Sulkin and published by McGraw-Hill Professional. Table 11 System Features SYSTEM FEATURES ACCOUNT CODES Included

ADMINISTERED CONNECTIONS Included

ANSWER DETECTION Included

AUTHORIZATION CODES Included

AUTOMATED ATTTENDANT Optional

AUTOMATIC CALL DISTRIBUTION Optional

AUTOMATIC ALTERNATE ROUTING Included

AUTOMATIC CAMP-ON Included

AUTOMATIC CIRCUIT ASSURANCE Included

AUTOMATIC NUMBER ID Included

AUTOMATIC RECALL Included

AUTOMATIC ROUTE SELECTION - BASIC Included


AUTOMATIC TRANSMISSION MEASUREMENT SYSTEM

CALL-BY-CALL SERVICE SELECTION Included

CALL DETAIL RECORDING Included

CALL LOG Included

CENTRALIZED ATTENDANT SERVICE Included

CLASSES OF RESTRICTION (SPECIFY #) Included

CLASSES OF SERVICE (SPECIFY #) Included

CODE CALLING ACCESS Included

CONTROLLED PRIVATE CALLS

DELAYED RINGING Included

DIAL PLAN Included

DIALED NUMBER ID SERVICE Included

DIRECT DEPARTMENT CALLING Included

DIRECT INWARD DIALING Included

DID CALL WAITING Included

DIRECT INWARD SYSTEM ACCESS Included

DIRECT INWARD TERMINATION Included

DIRECT OUTWARD DIALING Included

E-911 SERVICE SUPPORT Included

EXTENDED TRUNK ACCESS Included

FACILITY RESTRICTION LEVELS Included

FACILITY TEST CALLS Included

FIND ME- FOLLOW ME

FORCED ENTRY ACCOUNT CODES Included

HOTELING (/PERSONAL ROAMING) Included

HOUSE PHONE Included

HUNTING Included

INTEGRATED SYSTEM DIRECTORY Included

LEAST COST ROUTING (Tariff-based, TOD/DOW) Included

MULTIPLE LISTED DIRECTORY NUMBERS Included

MUSIC ON HOLD Included

NIGHT SERVICE –FIXED Included

NIGHT SERVICE - PROGRAMMABLE Included

OFF-HOOK ALARM Included

OFF-PREMISES STATION (OPX) Included

OPEN SYSTEM SPEED DIAL Included

PASSWORD AGING

POWER FAILURE TRANSFER STATION Optional

RECENT CHANGE HISTORY Included

RESTRICTION FEATURES Included

CONTROLLED Included

FULLY RESTRICTED Included

INWARD/OUTWARD Included

MISCELLANEOUS TERMINAL Included

MISCELLANEOUS TRUNK Included

TOLL/CODE Included

TRUNK Included

VOICE TERMINAL (IN/OUT) Included

ROUTE ADVANCE Included

SECURITY VIOLATION NOTIFICATION Included


SHARED TENANT SERVICE Included

SNMP SUPPORT Included

SYSTEM SPEED DIAL Included

SYSTEM STATUS REPORT Included

TIME OF DAY ROUTING Included

TIMED REMINDER

TRUNK ANSWER ANY STATION Included

TRUNK CALLBACK QUEUING Included

UNIFORM CALL DISTRIBUTION Included

UNIFORM DIAL PLAN Included

VIRTUAL EXTENSION Included

VOICE MESSAGE SYSTEM INTERFACE Included

Ericsson Response: Ericsson has inserted a column in the table and indicated whether the feature is included/available, or if the feature is optional/available. A blank indicates the feature is not available. Class of Service (CoS) 64 or Common Service Profile (CSP) 256 5.3.1 Additional System Features Vendor Response Requirement Provide a listing of proposed standard generic software system features that are not included in Table 11 that VoiceCon may find of use and benefit. Ericsson Response: Some additional noteworthy features are provided below.

• Advice of Charge • Choice of Language • Generic Extension • Original A-number

5.4 Mobility Features VoiceCon requires that the proposed IPTS support a variety of features and applications to support its mobile workforce. 5.4.1 Fixed Teleworking VoiceCon requires that its employees be able to use a PC client softphone outside the office environment using Internet or VPN access.


Vendor Response Requirement Verify that a VoiceCon employee can use a PC client softphone to access the full set of HQ IPTS features and functions from a remote location using Internet or VPN access. Specify if there are known NAT or firewall transversal issues with this application. Ericsson Response: The Ericsson MX-ONE™ Communication Organizer Personal Assistant-PC (PA-PC) allows a user to make and receive calls directly from their PC just as easily as from your office phone. MX-ONE™ Communication Organizer Personal Assistant-PC (PA-PC) offers many benefits that directly address the business needs of today’s enterprises:

• Enables a mobile workforce by allowing employees to work effectively in the office, at remote locations or from home using the same extension and businessclass telephony features





• Hotkey dialing from other applications • Instant messages to any other Communication Organizer user • Reduces costs by centralizing administration, reducing the

number of desktop phones and reducing internal traffic to operators, thus greatly improving the level of service offered to customers and external callers

• Phone control via Bluetooth™ interface. Make, answer and hang up calls via Bluetooth Mobile phone type headset.


Communication Organizer Personal Assistant-PC is a software-based IP phone. In addition to VoIP, it provides easy access to a wide range of the Ericsson MX-ONE Telephony Server features. Employees can stay connected whether working in the main office, at a branch site or at remote locations, or even from home via a VPN connection. Using IP telephony over a corporate LAN/WAN allows employees to access the same features as if they were in the office, while reducing telephone charges. Personal Assistant PC is a Windows-based Softphone application that also includes IP telephony functionality based on H.323, which could be used as a stand-alone application or as an integrated part of Outlook and Notes clients. In addition to the above features, Personal Assistant supports:

• Backup Gatekeeper if primary Gatekeeper fails • Codec; G.729a, G.729ab, G.723.1, G.711 • Mute Microphone and Speaker • Configurable ring tones • Making, answering and hanging up calls on a mobile phone via

Bluetooth™.


5.4.2 Cellular Extensions VoiceCon requires that its employees be able to utilize their cellular handsets to answer and place calls that are routed through the HQ IPTS. Vendor Response Requirement Verify that the proposed IPTS solution can support cellular handsets as system extensions, and briefly describe the IPTS option. Off-premises call forwarding of calls directed to an IPTS extension is not satisfactory for this requirement. Specifically address the following: 5.4.2.1 Shared directory number with IP desktop telephone instrument or

PC client softphone for inbound and outbound calls 5.4.2.2 Access to IPTS call answering and calling features (identify specific

features available to cellular handset user) 5.4.2.3 Shared voice mailbox for desktop stations and cellular extensions 5.4.2.4 If available provide a picture or photograph in PowerPoint format

of an optional graphical user interface screenshot for use with a cellular handset

5.4.2.5 Indicate if the cellular extension feature is proprietary to a specific cellular carrier operator service

5.4.2.6 Identify any optional hardware/software required to support the cellular extension feature if not a proposed IPTS generic software feature

Ericsson Response: Ericsson's Mobile Extension is a complete integration of mobile phones into a customer’s corporate communications. Mobile Extension enables the customer to control these calls in a similar way to control any other corporate extension. Another advantage is that any mobile phone can be used as an internal extension of the MX-ONE™ IP-PBX. Although the Communication Organizer Personal Assistant plug-in application offers an easy to use interface for Sony Ericsson P9XX series smartphones, the mobile extension feature of the MX-ONE™ will work seamlessly with most mobile phones available on the market today. (Any public subscription supporting touch-tone signaling, PSTN analog, ISDN, GSM, CDMA, WCDMA etc.) If the MX-ONE™ Mobile Extension is complemented with a Mobile Extension VPN/IN service offered by an operator, the solution can be enhanced even further. The solution grants that all calls to and from the Mobile Extension user are routed through the MX-ONE™, with no special actions needed from the users. By adding other product families, such as Ericsson’s MX-ONE™ Messaging with its text-to-speech engine for access to their


corporate inbox and Ericsson Mobile Organizer, mobile users have all the tools they need to be effective on the road. It's like having an "office in your pocket". The obvious advantages here are in the fixed/mobile convergence, which gives mobile corporate users access to the same applications and services in and out of the office on one device. Another benefit is that customers gain control of their mobile costs enabling them to reduce their overall public telephone charges and get a quick return on investment (ROI). The Mobile Extension features start with:

• Abbreviated Dialing • Account Code • End-to-end DTMF • Authorization Code • Call-back • Call Diversion • Call Offer • Call Pick-up • Operator/attendant svs – Extending – Camp on Busy – Monitoring – Recall – Serial Call – Call Splitting – Intrusion – Forced Release • Call Waiting • Class of Service • Common Bell Group • Conference • CSTA Monitoring • Customer Identity Storage (CID) • Data Privacy • Do Not Disturb • Emergency Category • External Number Redial • Faultman’s Ring Back • Follow-me • Three Party Services – Hold – Inquiry – Refer Back – Transfer – Conference


• Internal Group Hunting • Intrusion • Message Diversion • Hot-line • Paging • Parking • Personal Number • Secretarial Monitoring • Repeated Individual Diversion (RID) • Simplified Interception

The MX-ONE Personal Number (PN) is an extension directory number with a terminal of any type assigned, which has the Repeated Deflection service available. The aim of Personal Number is to provide system users (voice extensions) with different possible answering positions for the incoming calls. The MX-ONE Personal Number (PN) service is designed to provide the user with up to five profiles, each one containing up to 10 possible answering positions. The MX-ONE Personal Number (PN) service has the following characteristics:

• Every Personal Number can have up to 5 different lists available, but only one of them can be active.

• Each list can be set up with up to 10 different answering positions that are selected depending on the user location (e.g. at the office, at home).

• The user can activate and deactivate the service or change the active list via a procedure.

• When the Personal Number service is activated, incoming calls to the Personal Number are deflected to the positions in the active list, until the call is answered or is stopped for any reason. Typically the last position in a Profile is the Voice Messaging system.

• When the Personal Number service is not activated, all incoming calls to the Personal Number are distributed to the assigned terminal as in a normal call.

Any extension type can utilize the Personal Number service, regardless of the type of telephone assigned: Generic: Remote Mobile or fixed extension IP extension Virtual generic extension Traditional: Analog extension (only Primary extension) The answering positions to be included in the profiles can be:

• Analog extensions (Primary and Secondary extension)


• Remote extensions (mobile or fix) • IP extensions • A destination in the private network • A destination in the public network • An internal group hunting group • Individual PABX operators or PABX operator group • A voice mail system • Virtual generic extensions

If a personal number with the PN service active is defined as answering position, the Personal number service is not executed to the answering position, even if it is activated. An order of priority is defined to select the proper service when several services are activated for a personal number. Basically, the order of priority in which services (if they are activated) are executed is as follows:

• Individual Do Not Disturb • Message Diversion/External Follow me/Direct

Diversion/Follow me • Group Do not Disturb • Personal number service/Boss-secretary service • Diversion on Busy/ Diversion on No Reply •

MX-ONE Parallel Ringing service is an alternative to Personal Number. MX-ONE Parallel Ringing service provides the user with simultaneous ring signal on up to three pre-defined answering positions for an incoming call to the user. When the user answers the call, the call is directed to the extension where it has been answered. However, the extensions might not ring at the same time depending on their type. For example, non-generic extension will ring before a generic extension due to the delay in call set up. Parallel Ringing service has the following characteristics:

• The extensions to ring simultaneously are grouped as a parallel ringing list. A parallel ringing list consists of one main extension and up to two secondary extensions.

• Call to a parallel ringing list is made through the main extension number.

• Parallel Ringing service is not executed for a direct call to secondary extension of a parallel ringing list.

• It is not possible to define an extension in more than one parallel ringing list.

• If any of the extensions in the parallel ringing list is busy, the incoming call to that parallel list is reported as busy.


• Whenever there is a call to the parallel ringing list, it is possible to transfer call to secondary extension but not onto main extension.

Pictures in PowerPoint format for Personal Assistant-Web and Personal Assistant Smartphone are provided in file “03_Ericsson Phone Pictures - VoiceCon 2007.ppt”. The combination of MX-ONE Mobile Extension and MX-ONE Personal Number can provide an organization with the Ericsson One Phone Solution. Ericsson One Phone solution stands for:

• One phone • One subscription • One number • One voice mail • One phonebook • One bill • Access to PBX and e-mail services from One Phone • Full integration into the corporate ICT • Reduced total cost of ownership

The Ericsson One Phone Solution is available to enterprises in 3 unique win-win packages:

• The Basic Pack comes with a fixed or mobile phone together with all the fundamental features for enabling efficient on-site office performance.

• The Advanced Pack equips a user with a feature-rich mobile phone that works together with an IP soft phone for the PC or Laptop. This is the ideal performance tool for the employee who spends more than 20% of his/her time on the go – working from hotels, trains, airport lounges, at home or in traffic.

• The Advanced + Pack is the power tool for users who are highly mobile and need ready, secure access to full corporate resources and databases regardless of location. The mobile phone is equipped with advanced functionality like push e-mail, e-calendar and corporate directory access.

5.4.3 Fixed Mobile Convergence VoiceCon may be interested in implementing a Fixed Mobile Convergence (FMC) solution at some future date to increase station user productivity and performance. FMC supports seamless communications between a premises WLAN and a service provider cellular network using the same mobile communications device, with access to and implementation of IPTS features


and functions. Vendor Response Requirement Briefly describe current efforts and activities to support a FMC solution using a dual mode 802.11/GSM mobile communications device behind the proposed IPTS. Include in the response estimated availability dates of the FMC solution, required WLAN equipment to support premises roaming capabilities, QoS, and security. Also identify the means to provide seamless handoff between the 802.11 WLAN and the cellular network for active calls. Ericsson Response: Ericsson is working on three complementing tracks with the intention to provide business class telephony solutions including dual-mode technologies. It is quite clear that the most user friendly and powerful solutions have to be built on a combination of operator and enterprise provided services and components. Ericsson is working long-term in this area within the IMS for Enterprise program where proof-of-concept systems are being developed. Ericsson as well (2005) set up a test system together with a leading US operator to demonstrate IMS dual-mode handover. Multi-mode support in these contexts is just an underlying transport service. Availability of IMS oriented solutions will mainly depend on the mobile operators roll-out plans for the IMS technology and their commercial introduction of the services based on it. Ericsson was the first vendor to deploy softswitch solutions for telephony networks and leads the industry with 55 fully commercial networks. Today, Ericsson has 30 live, commercially deployed mobile softswitch networks on all continents. In parallel with the IMS development UMA development has been going on for some years. UMA is, just as IMS, integrating the mobile operator/service provider in the solution and is based on technologies that are falling in place during 2006. UMA based solutions can be provided on GSM as well as on 3G networks. Enterprise usage of UMA will focus on WIFI as the alternative radio carrier. Ericsson is testing an Ericsson UMA GSM set-up integrated with the mobility services (Mobile Extension) of the MX-ONE enterprise IPTS. The set-up provides seamless hand-over and maintain the full feature set of the Mobile Extension in the IPTS. The third track is fundamentally independent of the mobile operator as the intention in this case is to hand the call off from the cellular network to the private IP-PBX network. Ericsson will during 2006 merge the IP-softphone application to a dual-mode environment and test this with the corresponding IP-PBX mobility control functions. Performance and usability is critical to the success of these solutions


as dual-mode usage leads to a great number of new traffic cases that has to be dealt with underneath the surface of the application and the solution. In this aspect dual-mode (multi-mode) is still in its infancy. The estimated availability of the FMC (dual mode) solution is Q2 2007 which will include the terminals, access/mobility controllers and the radio base stations for the private/public environment. Independently of the call control technology, the WIFI network has to provide the means for business class quality and secure VoIP transport. 802.11e, etc., thus providing the conditions for the expected quality.


6.0.0 Systems Management The proposed communications system must be administered, monitored, and maintained through operations organized into five functional areas: Fault, Configuration, Accounting, Performance and Security. All of the systems and devices in your proposed solution should attempt to provide comprehensive operations in each area. Operations for each area must be accessible through one interface regardless of the underlying system or device being managed. If a proxy server is used for intermediate operations, there must be at most one central database for each functional area. Systems or devices may be accessed individually if no proxy server is used. EXCEPTION: Optional call center solutions may provide its own set of FCAPS management operations separate from the general enterprise communications solution. Any supplied management applications must support decentralized access from any distributed PC client across the HQ LAN/WAN infrastructure and remote dial-up PC clients. It is also desirable for the applications to support a browser based user interface for intensive remote operations. Any supplied management applications may integrate information from the five functional areas at the presentation level. Vendor Response Requirement Confirm and verify that each functional area required to manage the proposed IPTS network is supported by a single, centrally located proxy server or, alternatively, each system or device supports a single API for a given functional area. Provide a brief description of the proposed management system, including its major hardware and software components. Specify if the proposed systems management server and software is available as a bundled offering, only, or if VoiceCon is responsible for providing its own server hardware to operate the software. If third party technology is used, please indicate which components are managing your solution in a vendor agnostic fashion. Ericsson Response: The Ericsson MX-ONE™ Manager suite of products provides management functionality embedded in the MX-ONE components. Using one single workstation, administrators can manage users and extension administration of all Ericsson MX-ONE™ components, as well as fault and performance monitoring. VoIP quality of service (QoS) at remote sites ensures stable voice quality.


The Ericsson MX-ONE™ Manager suite is built on the following four groups:

• Ericsson MX-ONE™ Manager Identity – user and extension administration

• Ericsson MX-ONE™ Manager Availability – fault and performance management

• Ericsson MX-ONE™ Manager Telephony System – SNMP support • Ericsson MX-ONE™ Manager Device - distribution of digital

assets and various MX-ONE related software in Linux and Windows based servers

Ericsson MX-ONE™ Manager Identity provides easy-to-use, task-oriented functionality for administration of users and their extension related data on the MX-ONE™ Telephony System, MX-ONE™ Communication Organizer and MX-ONE Messaging. It provides a single point of entry for user and extension additions and changes, avoiding the need to enter data repeatedly for each product. The Manager Identity user can perform adds, changes, and deletes, views and prints. Manager Identity supports configuration of mobile, IP, as well as traditional digital1 and analog extensions supported on the MX-ONE™ Telephony System. The following user-related extension management features are supported:

• Extension Groups • Common Abbreviated Numbers • Subscribers name output to the telephone • Choice of language • Group Hunting • Call Pick-up • Common Service Profiles • Personal Number • Individual Authorization Codes

• Managing end-user data: departments, users, and data relating

to departments and users. • Managing configuration data:

o a Global locations o b User-defined fields o c PBX data: Common service profiles, group hunts, call

pickup groups and common abbreviated numbers • Managing the transaction log


Ericsson MX-ONE™ Manager Availability can be used locally or in the Network Operations Centre for monitoring the system. It detects faults and displays them to the network manager for immediate action. Manager Availability will monitor aspects like servers, OS and applications. A GUI will present the result to the network/systems operator. As soon as there is an alarm in any node, this will be displayed in the GUI. Ericsson MX-ONE™ Manager Availability is based on BMC PATROL (also called BMC Performance Manager) with specially developed applications to suit the Ericsson MX-ONE all-in-one communication solution. Characteristics:

• Web-based Management interface: Internet Explorer or Netscape browsers supported

• Communication between managed system and manager uses SSL.

Manager Availability consists of the following components – all prepared to be easily installed and integrated with the MX-ONE™ system to be managed:


• A Web-based management Console software (see figure) running on Windows.

• Agent (one per server) software with knowledge modules to manage detailed aspects of Windows and Linux servers, Active Directory and MX-ONE applications respectively. One agent with knowledge module(s) is installed on each managed server.

• An SNMP Bridge module for integration of the management console with an SNMP v1 capable management framework. MX-ONE™ alarms are then forwarded to the management framework. The SNMP Bridge module can be installed on the same server as the Console or it could sit on another server closer to the management framework, potentially on the same side of a firewall as the management framework to prevent SNMP v1 passing the firewall. If management framework integration is not required by the customer, this module is not used.


Ericsson MX-ONE™ Manager Telephony System is for configuration of the MX-ONE Telephony Server providing a web based graphical user interface. The GUI is functionally oriented and tasks belonging to one operation performed as one entity. System related configuration tasks are performed by the system administrator from this web-GUI (vs. user related administration which is performed through the MX-ONE Manager Identity). In order to assist the system administrator, help text is readily available on all web pages, providing assistance.

Ericsson MX-ONE™ Manager Device (not included in the proposal) is based on the HP OpenView Radia platform. Radia technology provides high levels of adaptability, flexibility and automation. Adaptability comes from embedded intelligence of platform-independent object-oriented technology. Flexibility is provided by the media-independence of Radia technology that enables content to be easily revised and customized. And Radia also automates the digital asset management across virtually any kind of network. Manager Device is based on the selected components of HP OpenView Radia. It consists of following basic components.


• The Radia Client software (Radia Application Manager and Radia Inventory Manager) runs on the client computer (i.e. the MX-ONE server). It communicates with the Radia Configuration server to receive information about the desired state of the client computer, and compares that information with the current state of the client computer. Then, the Radia Client makes any adjustments necessary to make the current state match the desired state.

• The Radia Configuration Server dynamically calculates the

desired state of the Radia clients. It can also distribute applications to client computers. It maintains the Radia Database, which stores information that the Radia Configuration Server needs to manage digital assets for distribution to client computers/ servers.

• The Radia Management Portal provides a single access point

from which Radia administrators can deploy Radia Client components, detect the current status of some Radia components, manage the Radia Database and track the completion status of all Radia Management Portal tasks. The Radia Management Portal is web-based and provides Radia administrators with the ability to manage their entire Radia environment regardless of location or computing platform. The Radia Management Portal provides the Web GUI for activating software upgrades (see Figure), monitoring the outcome, viewing inventory information etc.


Using Radia Application Manager the administrator can:

• Deploy mandatory digital content to MX-ONE servers over intranets, extranets and the internet to unattended devices.

• Select, install/uninstall and update MX-ONE servers’ software and content automatically on a scheduled or just-in-time basis transparently to subscribers.

• Restore broken applications on unattended devices automatically to a desired state.

• Control application versions.


The Radia Inventory Manager:

• Gathers information about MX-ONE software and hardware configurations automatically, and consolidates the results into Web-based reports.

• Increases manageability of enterprise digital assets by maintaining current inventory information collected across LAN, Internet and dial-up links and across a wide array of heterogeneous devices and operating systems.

Some functionality:

o SW management for IP phones and PC clients o SW management for Mobile Phones (Mobile device

management Q4 2007) 6.0.1 System/Port Capacity Vendor Response Requirement Identify the maximum number of independent IPTS communications systems that can be supported by the proposed systems management server, and the maximum number of user ports that can be passively and actively supported. Ericsson Response: MX-ONE™ Manager Identity supports the MX-ONE system and related application for up to 50,000 users and MX-ONE™ Manager Availability is licensed per user of managed MX-ONE™ system, up to 2000 users. After 2000 users, there is no additional charge per user – only a per managed server license fee as soon as 5 managed servers are exceeded. These applications are based on Right-To-Use (RTU) licenses. Additional RTU licenses for Manager Availability may be purchased to include other servers to be managed. 6.0.2 Terminal Capacity Vendor Response Requirement Identify the maximum number of configurable and active PC client terminals that can be configured as part of the proposed management server system.


Ericsson Response: There is no maximum number of configurable/active PC client terminals. Although concurrent activities should be limited to authorized users. For example, when adding/creating new users, the system will provide a list of unused extension numbers. If multiple users are accessing the list, they my try to use the same number. The number does not get allocated until the user confirms the addition. 6.0.3 Support for Open Standards The proposed management system should provide support for open protocols, such as LDAP and SNMP. The proposed management system should use open encoding schemes, such as XML and HTML. Vendor Response Requirement Briefly discuss the open standards included in your proposed management system that supports administration, operations and maintenance services. Indicate if any protocols or encoding schemes are de facto standards or are being implemented publicly by other vendors. Ericsson Response: The following “components” are implemented within the MX-ONE™ Manager suite:

• Microsoft Active Directory. • Microsoft Management Console • BMC PATROL • SNMP v1 support • SOAP-based protocol Web Services • HTTP/HTTPS protocols • XML/HTTP • Microsoft .NET

Simple Mail Transport Protocol (SMTP) and Lightweight Directory Access Protocol (LDAP) are also implemented with the MX-ONE, but are not considered as part of the management suite. 6.0.3 Security Features Unauthorized access to the communications system is a major concern. The ability to detect security problems is desirable beyond mechanisms to prevent security problems. Vendor Response Requirement Briefly describe the security features that are embedded in the proposed


management system to prevent unauthorized access and operation. Specify if media encryption is used for command signaling transmissions. What, if any, Denial of Service (DoS) and user authentication mechanisms are supported for the systems management application? Ericsson Response: Integration of a corporate telephony system into an IS/IT infrastructure raises a number of questions and concerns as to how to guarantee the security, the availability, and the quality of service of the classic circuit-switched telephony infrastructure. The information provides an overview of the security mechanisms available to protect the MX-ONE solution from threats that are typical of the IS/IT infrastructure. The described measures are either enabled in the system by default; enabled during the installation/configuration phase of the systems, or need to be enabled manually by the system administrator. The first security measure to be implemented is to preserve Physical Security. Only authorized personnel shall have access to server locations, since many data-exposure attacks can be mounted by having physical access to a host. This document does not consider security measures regarding physical security. The security measures available for the MX-ONE system are mainly based on the following open standard technologies: SSL (or TLS)

Secure Socket Layer (SSL) or Transport Layer Security (TLS) provides secure access to Web services. Web clients are authenticated with username and password while servers (Web servers) have to authenticate themselves using a valid digital certificate

SSH Secure Shell (SSH) provides secure console-based access to the MX-ONE Telephony server

IKE/IPSec Internet Key Exchange (IKE) or Internet Protocol Security (IPSec) can protect the communication between the system servers. Authentication is based on pre-shared keys.

Additionally, other mechanisms to protect the MX-ONE solution are based on the following:

• Correct configuration of the corporate Local Area Network (LAN) infrastructure

• Authentication and authorization of all users of the system, including end-users and administrators

• Security mechanisms provided by the target operating systems (SuSe® Linux and Microsoft Windows®) as well as hardening measures


The MX-ONE servers run on commercially available operating systems. From a security point of view, this is both an advantage and a disadvantage. The advantage is that these operating systems are being used by millions of users and security vulnerabilities are quickly discovered, announced and fixed.

MX-ONE Telephony Server The MX-ONE Telephony Server runs on the Suse Linux Enterprise Server (SLES) operating system, which is the enterprise version of the well-known Linux distribution. One of the main advantages of this operating system is the enhanced security features that it is equipped with. It is worth mentioning that SLES is being evaluated for compliancy with the Common Criteria Evaluation Assurance Level (EAL) 4+. The Telephony Server is the most relevant node in the system whose security must be guaranteed to keep the system available. For this reason, besides the already strict security features of the operating system, a number of additional measures are enabled by default on the Telephony Server to improve its security, its reliability and its resiliency to a number of malicious attacks.


Only required packages of the operating system are installed on the Telephony Server. The SLES operating system is extremely feature-rich but the more features that are installed; the higher the risk of potential security breaches. To decrease the risk of security vulnerabilities, the Telephony Server is delivered with only the necessary operating system features installed by default. Another important security measure is to only enable services and network ports that are necessary for the system's correct functioning. As an example, well known insecure services, such as Telnet and FTP are disabled be default. Additionally, the Linux packet filter IPTables has been configured to block access to certain services that are needed for the system but should not be reachable from the public network interface, connected to the corporate LAN. IPTables is also able to block certain kinds of attacks that have a well-known pattern and make use of certain deficiencies of the TCP/IP protocol stack. To manage the server using the Command Line Interface, SSH is the preferred solution. SSH is enabled by default on the Telephony Server. To increase security, direct root access are disabled by default. If a system administrator needs to carry out tasks that need root access, the administrator first needs to log on as a non-root administrator and then require the system to be granted root privilege by performing a second authentication procedure. To guarantee the integrity of the system and detect possible unauthorized or unwanted changes to the file system, the Tripwire tool has been configured on the Telephony Server. All relevant system files are being monitored and changes are notified as soon as they are detected. The system administrator can of course change the default settings to further increase the security level by increasing the frequency when the Tripwire tool performs the integrity check of the file system. The SLES operating system is equipped with a security tool named Seccheck. This tool is installed and enabled by default on the Telephony Server. Seccheck comprises three scripts that are run respectively each day, each week and each month. If something is detected that might indicate a security breach, a mail is sent to the root user with a description of the problem.


File permissions have to be accurately set, especially for those files that are relevant to the correct functioning of the system. The Linux operating system allows the use of the Least Necessary Privilege approach, the security golden rule that protects sensitive files of the system and avoids malfunctioning due to incorrect configuration actions done by inexperienced users having accidentally gained access to the system. MX-ONE Manager - Telephony System The Manager Telephony System is a Web-based tool that allows monitoring of a number of relevant items and configuration of some features. To protect access to this tool, SSL/TLS in server authentication mode can be enabled during the installation procedure. The administrator (client/Web browser) will be authenticated by means of username/password. The administrator credentials will be verified in the directory located on the Communication Organizer. It is assumed that the Web server has a valid pair of RAS keys and a digital certificate that can be verified by the client. This certificate can either be a self-signed certificate or issued by a well-known Certification Authority (CA). After successful authentication, the administrator is mapped to one of four possible administrator profiles, each of them holding different access privileges. The following four profiles are defined within the MX-ONE Manager framework: • Secretary/Administrator • System Administrator • Engineer • Advanced Troubleshooter For each operation requested by the administrator, the access privileges are checked against the requested privileges for that specific operation, thus implementing a fine-grained access control policy. The system administrator can configure the access privileges assigned to each role. MX-ONE Manager - Identity Manager Identity is an MMC snap-in that is used for user management. It can be installed on any PC running on the Windows operating system. Communication with the Communication Organizer Server is based on HTTP and can therefore be protected by the means of HTTPS. The user of the Manager Identity tool needs obviously to be authenticated before performing any action.


Access to the Manager Identity tool requires physical access to the host where the tool is being installed. Standard Windows security applies for controlling access to the host. It is possible to gain remote access to the host where the Manager Identity client is installed, and hence to all its functions, by making use of a remote desktop tool. The following tools have been tested: Symantec pcAnywhere , Windows® Terminal Service. In this case, security features provided by the tools apply. MX-ONE Manager - Availability Manager Availability is a tool used for advanced fault and performance management. It is based on a number of agent-component installed on each managed server, and on a set of server-side components. Communication between the agents and the server side components is based on BMC PATROL security level 2, which provides integrity and confidentiality protection based on SSL. The server-side components need to authenticate to the agent by the means of a username and a password, which are verified against the operating systems of the managed servers. Credentials are sent though the SSL connection. The system administrator using Manager Availability accesses the tool's Web-based interface. Communication between the browser used by the system administrator and the Web server are also protected by HTTPS. CLI-based Management of Telephony System Most of the management operations necessary on the Telephony System are carried out through a proprietary Command Line Interface known as MD-shell. In order to have access to this tool remotely, SSH shall be used to log on to the system. It is obviously necessary to set up authentication keys before being able to use SSH. Protection Mechanism of the MD Shell The MD-shell is a console-based mechanism to manage the MX-ONE Telephony Server. All possible management operations can be performed by the means of this tool, which makes it very powerful but even potentially dangerous. It is build on top of the Linux bash shell, which in turn is built on top of the operating system kernel.


It is necessary to guarantee that only authorized users (administrators) can manage the system; additionally, different groups of administrators might have different privileges. The MX-ONE Telephony Server defines eight different levels of user privileges for managing the system. Each time a command is issued by an administrator, the required privilege level to issue that command is checked against the privilege level assigned to the administrator issuing the command: if it is higher, the command is not performed. The root user is automatically assigned the highest privilege level, that is seven. The mapping between different commands to access privileges is stored in a configuration file that can only be modified by the root user. Additionally, it contains the mapping between Linux user groups and access privileges. The following briefly describes which operations are entitled to the different access privilege levels: Level 0: Visualizing of non-sensitive system configuration Level 1: Some Unix non-sensitive commands, call diversion, some operator-related operations Level 2: Operations on analog, IP, and generic extension, operations concerning abbreviated dialing Level 3: Simple accounting operations, number analysis, simple routing Level 4: Logging-related and dump operations, interception service, blocking operations, configuration, traffic recording Level 5: Inter-LIM signaling, Control system, LIM switch Level 6: Advanced management operations Level 7: Advanced troubleshooting; advanced diagnostic tools; advanced configuration, system-critical operations SNMP When monitoring the system with SNMP, it is only possible to read data that is not considered sensitive. It is not possible to set the value of a MIB II object. Event Logging A vital part of a good security policy is to keep track of what happens on a system, to identify the system's typical behavior and deviations that might indicate a security threat. Additionally, in case of a security incident, event logs are vital to identify where the incident originated and what vulnerability has been exploited. Additionally, event logs are extremely important for troubleshooting. All MX-ONE components log relevant events using tools available on the target operating system and MX-ONE specific tools or files.


The MX-ONE Telephony Systems has two main types of logs. The actual telephony application makes use of the common Linux logger known as Syslog. The MX-ONE Manager Telephony System allows the administrator to view relevant logs through its Web interface. The Inter-LIM signalling is protected with IPSec and pre-shared keys, the media with SRTP for telephones and IPLU and the Signalling is protected with TLS. 6.0.5 User Interface & Tools The management system should be operated using by GUI tools, formatted screens, pull down menus, valid entry choices, templates, batch processing & transactions scheduling, and database import/export. In general you should support a user interface set for each functional area: fault, Configuration, Performance and Security. The constituent users of each of these areas are distinct and your interface for each should optimize the experience for that constituent group. Management applications my integrate information from several management areas to enhance one functional area being managed. Ericsson Response: All management applications that belong to the Management System use GUI tools. MX-ONE Manager provides the management functions for MX-ONE system according to the FCAPS paradigm. FCAPS is the acronym for Fault, Configuration, Accounting, Performance, and Security management. MX-ONE Manager

• is used to configure and operate the MX-ONE system • provides a common, single point of entry for user and

extension administration • is used for advanced fault and performance management that

is easy to integrate with existing tools or frameworks • provides consistent management user interfaces across the

MX-ONE components and applications • is used for automatic software update and distribution within

the MX-ONE system See answer 6.0.0 for more details. 6.1.0 Administration Functions The proposed systems management solution must support: station user moves, adds, and changes; trunk group definitions and individual trunk circuit programming; voice terminal parameters; call restriction assignments;


class of service definitions and assignments; password resets; customer profile database; ARS routing tables; group definitions and assignments; first digit tables; dial plan; feature access codes; paging/code call zone assignments. Vendor Response Requirement Confirm the proposed systems management solution supports each of the listed administrative functions. Identify any functions not supported. Ericsson Response: The Manager Identity user can perform additions, changes, deletions, views and printouts. It supports configuration of mobile, IP, as well as traditional digital and analog extensions supported on the MX-ONE™ Telephony System.


Manager Identity implements a user-centric rather than extension-centric view. Most of the extension-related configuration data is only stored on the MX-ONE™ Telephony Server, reducing data duplication and thereby the risk for data inconsistency. Manager Identity interfaces the Telephony Server using the state-of-the-art SOAP-based protocol. Functionalities

• Managing end-user data: departments, users, and data relating to departments and users.

• Managing configuration data: o a Global locations o b User-defined fields o c PBX data: Common service profiles, group hunts, call

pickup groups and common abbreviated numbers • Managing the transaction log

The following functions are currently performed via the Ericsson MX-ONE™ Manager Telephony System interface: trunk group definitions and individual trunk circuit programming; call restriction assignments; class of service definitions; customer profile database; ARS routing tables; first digit tables; dial plan; feature access codes; paging/code call zone assignments.


Group Assignments The administration subsystem must support each of the following group definitions and assignments

• Abbreviated Dialing (System, Group, Enhanced)

• Hunt Groups

• Call Coverage Answer Groups

• Pickup Groups

• Intercom Groups

• Terminating Extension Groups

• Trunk Groups

Vendor Response Requirement Confirm administration support for each of the listed group definitions. List any and all groups not supported by the administration subsystem. Ericsson Response: The following function/s are performed outside Manager Identity via the MX-ONE Manager Telephony:

Number Series External Number Length System/Customer Call Diversion Call Discrimination Emergency Number Electronic Mail Message Diversion/Waiting Voice Announcements Branch Office Routing Server Operator Mgmt Call Center Customer/Hunt/Pickup Groups Routing, Destination, Rerouting Charging System Data IP Phone Terminal Mgmt DECT System

6.1.2 Facilities Performance Management & Reports The management system must be able to collect, analyze, and provide reports for a variety of system operations.


Ericsson Response: The Traffic Recording function provides various data from the system to be used for system requirements analysis, and will allow administrative personnel to monitor the effectiveness and/or efficiency of the system to pinpoint areas for improvement. Traffic recording data can be output to a printer on request and/or extracted by an external device. Up to 250 separate measurement operations can be simultaneously active.The measuring objects to be included in a measurement operation are specified in advance by entering commands from an I/O terminal. Advance specification means defining the measurement objects, the individuals within a measurement object, and the start and stop dates and times. A traffic recording operation may include the following measurement objects: Voice Extensions, including IP extensions Internal group hunting groups (PBX-groups) Routes External Lines, including IP networking lines PBX-Operators Dial Tone Delay Multi-Party-Unit 6.2.1 Basic Trunk Usage and Traffic Trunk traffic records should be kept for all inbound and outbound calls, identifying the trunk group and trunk channel, time and duration of call. Vendor Response Requirement Confirm that the proposed facilities management system satisfies this requirement. Ericsson Response: The requested function can be provided using the Call Information Logging feature of the MX-ONE. Please refer to 6.4.0 Call Detail Recording. 6.2.1.1 Individual Trunk Line Counters Vendor Response Requirement Confirm that individual trunk line counters measure and report: Number of call attempts; Number of blocked trunk lines; Traffic intensity (Erlangs).


Ericsson Response: A traffic recording operation can be made for external lines. The following information is provided for this measurement. Recording on external line.

TRAFF Traffic intensity in erlangs. Value range: 0.00 -

9999.99.

Note: Traffic is indicated for the recording object internal group (PBX) number even when a group member records traffic as a non-group member.

CALLS The total number of call attempts, successful as well

as unsuccessful. EXAMPLEs of the latter category are unanswered calls and calls that encounter congestion. For recording objects that may have both incoming and outgoing calls, these are recorded regardless of direction. For the recording objects data extension and IP board, calls that encounter busy state are also recorded (this does not apply to the other recording objects).

NDV The number of individuals (devices), included in the measurement. For PCM lines and cordless extension common fixed part: the number of time slots.

NBLO The number of manually blocked individuals (devices) included in the measurement. For PCM lines and cordless extension common fixed part: the number of blocked time slots. For IP boards, the number of boards with any kind of blocking or that do not answer when data collection is in progress.


6.2.1.2 Outgoing Trunk Route Counters Vendor Response Requirement Confirm that outgoing trunk route counters measure and report: Number of outgoing attempts; Number of successful calls overflowing to another route; Number of lost calls due to blocking; Number of blocked trunks in measurement; Traffic intensity (Erlangs). Ericsson Response: A traffic recording operation can be made for incoming trunk routes. The following information is provided for this measurement. Recording incoming route.


9999.99.






NBLO The number of manually blocked individuals (devices) included in the measurement. For PCM lines and cordless extension common fixed part: the number of blocked time slots. For IP boards the number of boards with any kind of blocking or that do not answer when data collection is in progress.

6.2.1.3 Incoming Trunk Route Counters Vendor Response Requirement Confirm that incoming trunk route counters measure and report: Number of incoming call attempts; Number of trunks in the measurement; Number of blocked trunks in the measurement; Traffic intensity (Erlangs). 6.2.1.4 Both Way Trunk Route Counters Vendor Response Requirement Confirm that both way trunk route counters measure and report: Number of incoming call attempts; Number of trunks in the measurement; Number of blocked trunks in the measurement; Traffic intensity (Erlangs). Ericsson Response: A traffic recording operation can be made for both-way trunk routes. The following information is provided for this measurement. Recording on bothway route.


9999.99.



OUTG.CALLS The number of outgoing calls.

INC.CALLS The number of incoming calls.



OFLO Overflow. Depending on the recorded object, overflow is defined as:

The number of calls that result in seizure attempts in some other LIM.

The number of calls that result in switch over to an alternative route.

CONG The number of calls that encounter congestion. Depending on the recording object, congestion is defined as follows:

No free device individual available

No free group member available

No free queue position available.

No free time slot available.

6.2.2 Attendant Consoles Attendant counters should measure all attendants in the system, or individual attendant positions. Record measurements include: number of answered calls; number of calls initiated by attendant; accumulated handling time for all calls; accumulated handling time for recalls; accumulated handling time for calls initiated by attendant; accumulated total delay time for recalls; number of answered recalls; number of abandoned attendant recalls; accumulated waiting time for abandoned calls to an attendant; accumulated waiting time for abandoned recalls, and accumulated response time for all types of calls. Vendor Response Requirement Confirm that attendant counters measure and provide reports for each of the listed parameters. Identify attendant parameters which are not measured.


Ericsson Response: A traffic recording operation can be made for Attendant positions. The following information is provided for this measurement. Recording on individual PABX operator.

CORGC The number of answered calls to a group of

origin.

OPIC The number of calls initiated by a PBX operator/attendant.

HCORGC The handling time (in seconds), which means the time from the moment a call to a group of origin is answered to the moment the handling procedure is completed.

HOPIC The handling time (in seconds) of operator- initiated calls, from the moment the call is initiated to the moment the handling procedure is completed. The value of HOPIC is rounded down to the nearest ten.

OPC The number of answered calls sent to an individual PBX operator.

ABND The number of abandoned calls to a PBX operator. HOPC The handling time (in seconds) for calls to an individual PBX

operator. See also HCORGC. WABND Waiting Time for Abandoned Calls. The waiting

time (in seconds) for abandoned calls, i.e. the time from the moment the call is detected (placed in queue) until the moment it disappears without being attended to. The value of WABND is rounded down to the


nearest ten.

DLYOPC The time of delay (stated in seconds), which means the time from the moment a call to a PBX operator is detected, (queued) to the moment it is answered by the PBX operator. Delay time = queue time plus response time, see also RESPT. The value of DLYOPC is rounded down to the nearest ten.

ABNDREC The number of abandoned recalls for an individual PBX operator.

REC The number of answered recalls.

WABNDREC The waiting time (in seconds) for abandoned recalls. The value of WABNDREC is rounded down to the nearest ten.

HREC The handling time (in seconds) for recalls. See also HCORGC.

RESPT The total response time for all calls. The response time (in seconds) for each call is recorded from the moment the call is displayed on the PBX operator console to the moment it is answered. Queue time is not included in response time. See also DLYOPC.

DLYREC The time of delay (in seconds) for recall. See also DLYOPC. The value of DLYREC is rounded down to the nearest 10.

6.2.3 Stations Station counters should measure individual stations or station group traffic statistics, including: number calls; number of stations in measurement; number of blocked stations in measurement; traffic rating (Erlangs). Vendor Response Requirement Confirm that station counters measure and provide reports for each of the listed parameters. Identify station parameters which are not measured. Ericsson Response: A traffic recording operation can be made for stations. The following information is provided for this measurement.


Recording on voice extension.


9999.99.






6.2.4 Traffic distribution When applicable, traffic distribution across the internal switching network should be measured for each local TDM bus, traffic over each highway bus, and traffic across the center stage switch by each switch network interface link.


Vendor Response Requirement Confirm that traffic distribution is measured and reported for each switch network element listed. Identify what is not measured and reported. Ericsson Response: Not applicable. The proposed solution is a single system. 6.2.5 Busy hour traffic analysis Busy hour traffic analysis measurements for trunks, stations, and the internal switch network should be performed and reported for any one hour interval for any time of the day. Vendor Response Requirement Confirm busy hour traffic measurements for trunks, stations, and the internal switch network for any one hour interval for any time of the day. Ericsson Response: The term busy hour is defined as the latest four consecutive 15-minute periods for the day during which the highest traffic carried value is recorded. If there is no traffic recorded, no busy hour information will be given. In this case, the busy hour field will indicate NONE. If the busy hour is to be calculated for a period longer than one day (24 hours), for instance, a whole week, this calculation must be done outside the exchange. 6.2.6 Erlang Ratings Erlang rating should be calculated and reported for individual trunk lines, each trunk group, and all trunk groups. CCS ratings should be calculated for individual stations or groups of stations. Vendor Response Requirement Confirm Erlang and CCS rating calculations and reporting for each listed item. Ericsson Response: Traffic reporting is presented in Erlangs only. 6.2.7 Processor Occupancy System call processing performance is measured in terms of Busy Hour Calls (Attempts and Completions). The percent of maximum call processing capacity should be reported for programmed time intervals. Threshold reports should also be generated to monitor system load factors.


Vendor Response Requirement Confirm measurement and reporting of processor occupancy and threshold levels Ericsson Response: MX-ONE™ Manager Availability provides fault and performance monitoring for MX-ONE™ servers and applications, including also Microsoft Active Directory/Application Mode used by MX-ONE™ Communication Organizer. Filtering and basic correlation is provided to ensure that the administrator/operator can focus on the important alarms and protect from overload of the customers management framework. Some of the key features included are:

• Server Monitoring – monitors the performance, resource consumption and capacity of such critical server components as CPU, memory, cache, physical and logical disks.

• Application Monitoring – picks up and handles events, keeps status of critical applications.

Call processing performance, measured in terms of Calls are available. Parameter Description EXTENS/TRMECalls Number of calls per 15 minutes for all

voice extensions and all LIMs. IPXBRD/TRMECalls Number of calls per 15 minutes for all IP

extensions and all LIMs. TRUNKS/TRMECalls Number of calls per 15 minutes for all

trunks and all LIMs. ROUTExx/TRMECalls Number of calls per 15 minutes for route

XX. ROUTExx/TRMETraffic Traffic in Erlang for ROUTExx ROUTExx/TRMECongestion Number of calls per 15 minutes for route

XX that encounter congestion. Only for outgoing routes.

It also provides two types of trend reports/files: Type Contents for each parameter Current Month Max, min, average (for current month) and one value per

day. Monthly Max, min, average (for month) and one value per day.

6.2.8 Threshold Alarms For a variety of system hardware devices it should be possible to define a congestion threshold value, and measure generated alarms. Alarms are


recorded in an Alarm Record Log. The types of devices that can be tracked include: tone receivers; DTMF senders and receivers; conference bridges; trunk routes; modem groups. Vendor Response Requirement Confirm recording and reporting of alarms for each listed item. Ericsson Response: The MX-ONE Telephony Server has a built in alarm log and alarm handling facility. Checking the alarm log should usually be the first step when trying to isolate a fault, malfunction or incorrect configuration. It is good to make a habit of checking the alarm log often, as the alarm log might indicate service actions that are needed in order to avoid malfunction. The alarm log is distributed. The log is held in the program unit AL (Alarm Log). There is also a program unit called ALDP (ALarm Device Program). ALDP handles actions configured for alarms and alarm input/output (see Alarm Input/Output ). Every alarm has a code, a domain, and a severity. The combination of a code and a domain identifies the alarm type and gives the alarm name (which is shown when listing alarms). The severity of the alarm can be from 4 (most critical) to 0 (alarm condition was detected, but does not exist any more). The alarms can also have (and usually have) other optional information that assist in finding the cause of the alarm. Every alarm instance is uniquely identified by its handle and the LIM number. The handle is a number that is automatically assigned to an alarm when it is stored in the alarm log. A program unit that detects a fault/malfunction and sends an alarm is said to "raise" the alarm. When the alarm condition no longer exists the program unit will "clear" the alarm. A "cleared" alarm will remain in the alarm log, but with a severity of 0. When a system administrator removes an alarm from the log, it is said to "erase" or "reset" the alarm. With the use of an SNMP agent, alarm information can be propagated to external systems. 6.2.9 Feature Usage Feature usage counters for selected station features, e.g., call forward, call transfer, add-on conference, and attendant system features, e.g., recall,


break-in, should be measured and reported for programmed intervals. Vendor Response Requirement Confirm recording and reporting of feature usage counters for both station and attendant operations. Ericsson Response: Feature usage is not available. 6.2.10 VoIP Monitoring The management system should collect and store data to track usage and performance data of IP gateway devices, IP phones, and VoIP intercom/trunk calls. VoIP information reports may include: tracking of IP gateway devices and calls that pass through each gateway; gateway congestion; assignment of services or routes to gateways; tracking of phone numbers dialed or originating off-site numbers; and IP gateway addresses. Vendor Response Requirement Briefly describe all VoIP monitoring information records and reports that are available. Specify if VoIP QoS parameters such as jitter, call delay/latency, and packet loss are tracked and reported, and if a system administrator can monitor VoIP calls in real-time for QoS observing? Indicate if any third party equipment is being proposed as part of your solution. Ericsson Response: The MX-ONE Manager Availability offers VoIP QoS monitoring for each individual LIM using three parameters VoIPQoSRed, VoIPQoSYellow and VoIPQoS which will be summary of the other two. This is for individual LIM or Telephony Server. Administrator can set thresholds for these parameters and will get alarms/events when it is reached and getting reports.


The next release will include Jitter, Delay and Bandwidth for all IP phones and report to the central server and the adminstrator will be able to set thresholds on these three parameters for IP phones.

For more advanced VoIP QoS reporting and monitoring we have tested MX-ONE with Viola Networks' VoIP QoS solution. 6.3 Optional Reports Directory records may include each subscriber’s name along with a variety of phone numbers such as primary, published, listed, emergency, and alternate, as well as authorization code information, job title, employee number, current employment status and SSN.

Inventory records and management is used to administer any kind of inventory product part, including: PBX common equipment (cabinets, carriers, circuit cards); voice terminals and module options; jacks, and button maps. The reports allow administrators to accurately re-charge items. Inventory can be tracked by data such as user, system (PBX or other networks), jack, serial number, asset tags, trouble calls, recurring and non-recurring costs, and general ledger codes. The inventory management system may also include records containing the following data: purchase date, purchase order number, depreciation, lease dates, manufacturer and warranty information.

Cabling records keep track of all cable, wire pairs, distribution frames, wiring closets and all connections (including circuits) down to both the position and the pair level. Cable records include starting and ending locations, description, type and function. Individual cable lengths are maintained and automatically added, as is the decibel loss, for the entire path. Information can also be provided on the status of all cable runs, as well as the number of pairs it contains, the status of the pairs, and the type of service it provides. Vendor Response Requirement Identify and briefly describe your proposed management system’s Directory, Inventory, and Cabling reports, if available.


Ericsson Response: The MX-ONE solution implements Microsoft Active Directory. MX-ONE Identity provides the ability to create “user-defined” fields, in addition to the standard fields, that may be user to store most any type of data. For example, a field could be created to store a user SSN. This field could be marked as “confidential”. A user has to have the “access confidential data” privilege to view this information. Ericsson does not provide Inventory and Cable record systems. 6.4.0 Call Detail Recording Call Detail Record (CDR) data should be compiled for all successful incoming and outgoing trunk calls. Call record fields typically include the following:

• Date • Time • Call Duration • Condition Code (categorizes information represented in the call record) • Trunk Access Codes • Dialed Number • Calling Number • Account Code • Authorization Code • Facility Restriction Level for Private Network Calls • Transit Network Selection Code (ISDN access code to route calls to a

specific inter-exchange carrier) • ISDN Bearer Capability Class • Call Bandwidth • Operator System Access (ISDN access code to route calls to a specific

network operator) • Time in Queue • Incoming Trunk ID • Incoming Ring Interval Duration • Outgoing Trunk ID

Vendor Response Requirement VoiceCon will purchase its own third party call accounting and billing system. Identify all available CDR reports that can be generated for any or the entire call record field data listed above.


Ericsson Response: The MX-ONE provides the Call Information Logging function. The Call Information Logging function generates records for storage of call data. Each record contains data for one call. All types of calls can be registered, e.g. internal calls, outgoing external calls and abandoned calls. The following call data can be included in a record:

• Date • End time • Start time • Call duration • Calling party's number • First and second access code • Time in queue to a busy external line or route • Queuing time for incoming call to PABX operator • Ring time duration • Queue time duration • Dialed number • Number of metering pulses • Authorization Code • Account Code • Outgoing/Incoming External line identification • Condition code

Commands can be entered to determine what calls should be output to external equipment. This is done by defining one or more output criteria for an output file. One or more external equipment can be associated to an output file. The following call criteria can be defined:

• All calls are to be output • Call duration exceeding a preset time • The calling party's number • The dialed number • The calling party's number in combination with the dialed

number • The calling party's number in combination with the dialed

number and call duration exceeding a preset time • The calling party's number and call duration exceeding a preset

time. • The dialed external number and call duration exceeding a

preset time. There may be up to 60 output criteria records.


6.5.0 Maintenance System maintenance operations should, at minimum, support the following: Monitoring of processor status; Monitoring and testing of all port and service circuit packs; Monitoring and control of power units, fans, and environmental sensors; Monitoring of peripherals (voice terminals and trunk circuits); Initiate emergency transfer and control to backup systems; Originate alarm information and activate alarms. Vendor Response Requirement Confirm support of each listed maintenance monitoring activity. Identify any activity not supported. Ericsson Response: Manager Availibility is Ericsson’s answer to this question. Based on BMC Patrol, which already can monitor different equipment. Ericsson has enhanced the functionality to include monitoring of MX-ONE. MX-ONE™ Manager Availability provides fault and performance monitoring for MX-ONE™ servers and applications, including also Microsoft Active Directory/Application Mode used by MX-ONE™ Communication Organizer. Filtering and basic correlation is provided to ensure that the administrator/operator can focus on the important alarms and protect from overload of the customers management framework. Some of the key features included are:

• Server Monitoring – monitors the performance, resource consumption and capacity of such critical server components as CPU, memory, cache, physical and logical disks.

• Application Monitoring – picks up and handles events, keeps status of critical applications.

The MX-ONE™ Manager Availability web-based Console GUI (see figure) provides functionality for the administrator/operator to: • adjust thresholds • chart various system/application parameters current values as well as history data • issue selected managed system commands – for example initialization of the MX-ONE™ Telephony System traffic measurement view alarm list, reset alarms, or create various reports. • view and manage events • perform managed system queries • create custom views • organize your managed system environment • centrally configure monitoring for all your systems


6.5.1 Alarm Conditions There are usually several types of communications system alarm conditions: Major, Minor, and Warning. Vendor Response Requirement Briefly describe how your management system defines a Major, Minor, and Warning alarm. Ericsson Response: The errors that may occur are stored in the system alarm log. Each type of error has its own unique fault code. For the fault code to be stored in the alarm log it is necessary that it has been assigned an alarm class (1-4). The alarm class states which priority an alarm has. Alarm class 4 has the highest priority.


An alarm class (0) also exists where an alarm that has been acknowledged by the system will be placed. System acknowledged alarms may also be placed in one of the other alarm classes if this is stated by command. Via command it is also possible to define how many alarms may occur in a specific alarm class before an alarm in the next higher alarm class (incriminations alarm) is generated. On delivery the fault codes, except external fault codes, are assigned an alarm class and an alarm class after system acknowledgement. Incriminations alarm has also been set. Using the PATROL Event Manager from the MX-ONE Manager Availability you can see the Telephony Server’s alarms and events.


Manager Availability may optionally be integrated into the Simple Network Management Protocol (SNMP) Manager of your Management Framework like OpenView, Tivoli etc. 6.5.2 Maintenance Reports Vendor Response Requirement Identify any and all available maintenance alarm reports provided by your management system. Ericsson Response: When the alarm is stored in the alarm log, or is system acknowledged, and if the alarm belongs to one of the specified alarm classes, an automatic printout to a pre-programmed I/O port can be provided. The format of the printout message is the general alarm message format or a special format in ASCII. The format in ASCII is used at communication with an operating and maintenance center. At any time printouts of alarm information can be obtained for all alarms in one or more alarm classes.


The following can be printed out: Alarm in a specific position in the alarm log Alarm with a specific fault code Alarm with a specific alarm class and/or a specific alarm group All alarms in the alarm log

Manager Availability may optionally be integrated into the Simple Network Management Protocol (SNMP) Manager of your Management Framework like OpenView, Tivoli, etc . 6.5.3 Remote Maintenance Vendor Response Requirement Briefly describe the available options used to support remote maintenance operations for both customer access and for an outside maintenance service provider. Specify how the system alerts a remote service center when an alarm condition occurs, the trunk circuit requirements for alert transmissions, and security measures to prevent unauthorized access. Ericsson Response: We can do remote maintenance in different ways: For the LINUX Telephony Server, a web interface for Manager Telephony System is used and it can also be accessed from customer's premises as well as remotely. This also goes over secure connection and takes care of user authorization. This is a tool which can be used to do remote configuration of the Telephony System. The other option for LINUX Telephony server is SSH-session. Manager Availablity is a tool which is used for Fault and performance Management of the whole system both at customer's premisis and remotely at the service provider's premisis. It uses SSL – encryption for security and all unauthorized accesses are prohibited. 6.6.0 Provisioning All services should be provisioned in one step. Services should include station configuration, voice mailbox configuration, E-911 location, billing attributes, directory attributes, and mobile Email attributes (Blackberry) and the configuration of other end user applications. For example, if your solution includes a zone paging application, the ability to assign a station to a zone and change the zone membership as a whole must be accessible through the configuration (provisioning) interface. Templates must be supported to organize different settings across different


systems according to organizational need. At a minimum, the voice station configuration and the associated voice mailbox must be provisioned in one step through one interface. Your proposed provisioning application or interface must create a complete audit trail and must allow groups of changes to be scheduled for a future time. Further, the solution must support mass create, delete and modify functions to support bulk operations. Vendor Response Requirement Describe the provisioning workflow you recommend showing how each of your proposed solution components is utilized. List any functions above which are not available. List any systems or devices which are not now part of your provisioning interface and provide a roadmap statement of how you will treat this situation going forward. Ericsson Response: With Manager Identity all basic services for a user are performed in one step. This includes definition of a user, configuration of user priviligies, definition of mail box. There are templates available for the user.


Audit trail is supported. With MX-ONE Manager Telephony System Batch operations can be used when you want to create several configuration tasks in a batch, for repeated or frequent operations that are time consuming to do manually. It is possible to record several configuration tasks into one batch operation and change the order of the operations.

Support for bulk operations.


7.0.0 Integrated Messaging System VoiceCon requires a HQ-based voice messaging system that must be fully integrated with the proposed IPTS network solution. VoiceCon also requires integration of the proposed voice messaging system with a Microsoft Exchange messaging system to provide “unified” messaging applications. The proposed voice messaging system solution must be centrally located at the VoiceCon HQ location, and be capable of supporting station users at all remote VoiceCon faciliities (RO and SBs). The voice mail system will also serve as an automated attendant position for select incoming trunk calls, and also as a secondary point of coverage as an automated attendant system for designated stations. All software and hardware necessary to interface with the existing telephone system will be provided under this bid. The sizing requirements are:

Five (5) automated attendant ports are included in the requirements. A Grade of Service level of P.01 is required. Vendor Response Requirement Briefly describe the proposed integrated messaging solution, and provide details about the voice mail system architecture and it’s interconnection to the voice communications system and Microsoft Exchange system. Include processing system platform information in the discussion. Verify that the system being bid can comply with each of the proceeding requirements. Ericsson Response: Ericsson is proposing its MX-ONE Messaging Unified Messaging system. With MX-ONE Messaging, organizations can integrate their telephone systems with their computer networks, providing a versatile, flexible, truly unified messaging environment for their employees and customers.

Installed/Equipped Capacity Maximum Capacity Number of Users 2000 3,000 Number of Ports 64 96 Hours of Storage 1000 1200


MX-ONE Messaging is a state-of-the-art Mobile Messaging application giving users access to their messages – anytime and anywhere. All messages – whether by voice, fax, or e-mail – are available through your mobile phone via text-to-speech or computer desktop via Microsoft Outlook, Lotus Notes or Novell GroupWise. This instant accessibility leads to greater productivity and efficiency, giving your organization a vital competitive edge. MX-ONE Messaging now combines the best of two worlds, namely Data and Voice into an integrated, easy to manage convergence-based communication server. By providing your workforce with advanced voice mail, inbound and outbound faxing, or best of all, the Unified Message System, which combines these and other options, you are giving them that vital competitive edge, both individually and as part of a team. The advanced networking of MX-ONE Messaging makes it the solution of choice for large, multi-site enterprises. MX-ONE Messaging supports both analog and digital networking formats as well as Voice Profile for Internet Messaging (VPIM) and the industry standard Audio Messaging Interchange Specification (AMIS) for networking with other vendors' messaging systems. With MX-ONE Messaging, you can network an unlimited number of systems together to create a solid, enterprise-wide communication solution. MX-ONE Messaging Voice Mail

• Call answering. Recording an incoming message

• Voice messaging. Send and receive voice messages

• Automated Attendant. MX-ONE Messaging UM can automate the work that normally is performed by the company’s telephone operator

• Graphical User Interface via MX-ONE Messaging Message Manager

• Personal Automated Attendant. Up to ten different options can be given to the caller. For example Press 1 to talk to my secretary, press 2 to be forwarded to my mobile phone and press 3 to leave a voice mail message.

• SMS notification for new messages, which allows the user to be, instantly informed about new messages that have arrived. On an individual basis the criteria for when to notify the user can be set. Hence notification can be based on criteria such as Time-of-day, type of message, sender, and urgency.

• Voice Intercept Messaging (VIM) support allows subscribers to activate a diversion via telephone. Callers are told why the user is absent and the planned time for the user’s return. “John Hollander is out for lunch and will be back at 13:00pm.


Please leave a message after the tone or dial zero for the operator.”

MX-ONE Messaging Unified Messaging

For customers with requirements for a complete Unified Messaging system, MX-ONE Messaging™ offers the best functionality available in the market. In addition to the voice and fax mail functionality mentioned above, an MX-ONE Messaging™ customer can take advantage of:

• Choice of integration with Microsoft Exchange/Outlook, Lotus Notes, or IMAP.

• Choice between client and server based Unified Messaging

• An extremely easy to use, graphical, interface, where messages are displayed in the e-mail client, with the ability to access, manage and store them as e-mail

• The tightly integrated plug-in for MX-ONE Messaging™ which

enables a user to listen to and record messages directly from the PC (multimedia) or via the phone.

• The ability to mix media, where for example a voice mail can be replied to with an e-mail or where a fax is forwarded either with a voice mail annotation or as an e-mail.

• E-mail can be accessed over the phone and either forwarded as


faxes to a fax machine of your choice, or “read” to you directly through MX-ONE Messaging™ advanced Text-To-Speech engine

• The web browser ability to give access to your Outlook/Exchange or Notes account even from another terminal than your own.

MX-ONE Messaging Administration

• Single Point of Administration System via MX-ONE Communication Organizer. Administration of MX-ONE Messaging and the Ericsson MX-ONE can be managed through the MX-ONE Communication Organizer. Moves, additions, and changes can easily be performed from the Manager Identity.

• Global User Administration. Administrators of multiple, networked systems can simultaneously manage the subscriber and distribution list databases of all systems in the MX-ONE Messaging network. This system management can be accomplished from a single global view. Additions, changes, and deletions of subscriber mailboxes can be done.

• The configuration wizard allows installers and system integrators to quickly configure turnkey systems at the customer site. When buying a turnkey solution, which includes the server hardware, the system will come pre-installed with the Windows 2003 operating system, and the MX-ONE Messaging Telephony Server application. The configuration wizard is launched when you start up your server for the first time, and will guide you through the following configuration areas: Customer Specific Windows NT Settings, Telephone System Integration Information and Language Prompt Set Selection.

7.1.0 Support for Open Standards Vendor Response Requirement Describe voice messaging system’s support for open standards. List the clients that can be used with your proposed solution. For proprietary clients, detail minimum hardware and software requirements Ericsson Response: MX-ONE Messaging supports the following open standards:

• ODBC database standard

• AMIS Networking Standard

• Voice Profile for Internet Mail (VPIM) standard

• IMAP RFC standard 2060 e-mail

• Group III Standard or Fine Mode


• TCP/IP

• SIP

E-mail access means integration of e-mail, voice mail, and fax systems. Messages can be accessed via client PC application or telephone. Full server based UM client integration can be achieved with systems using: • Microsoft Outlook , 2000 (v9.0), XP (v10.0), 2003 (V11.0) • Lotus Notes/Domino R5,12, R6.0.3 (Microsoft Platform Only). IMAP based UM telephone integration can be achieved with systems using: • Novell GroupWise 6.5 7.1.1 Security Features Vendor Response Requirement Describe security features available with the voice messaging system to prevent abuse and unauthorized access. 7.2.0 Voice Mail Features Ericsson Response: MX-ONE Messaging provides the following security features:

• The system can be configured to lock subscribers out of their mailboxes if someone makes an excessive number of unsuccessful attempts to log on to those mailboxes. This protects the server against anyone who might attempt to break into your telephone system by trying to log on with a succession of mailbox numbers and passwords.

• The MX-ONE Messaging Administration utility provides several levels of security, allowing the company to create administrator accounts with different degrees of authority over the telephony server and its mailboxes.

• When the system is initially installed, are subscribers “forced” by the system to change their password upon entering their mailbox the first time.

• The system encrypts passwords so that they are unavailable to the system administrator.

• The administrator requires subscribers to select new security codes after a specified number of days to enhance mailbox and system security.


• The system track and report failed attempts to access mailboxes.

• The system administrator set a minimum password length

• The system administrator set a password expiration time span so that subscribers must select new passwords periodically

7.2.1 Forwarding The system must provide access for forwarded calls from: * Customer telephone system * Direct central office (Business or Centrex lines) * 800 Service lines Vendor Response Requirement Confirm support for each forwarding requirement. Ericsson Response: MX-ONE Messaging supports all three requirements. 7.2.2. Disconnect Detection The system should detect that a caller has hung up and immediately disconnect and restore the line to service. Vendor Response Requirement Confirm support for this operation. Ericsson Response: MX-ONE Messaging provides this capability. 7.2.3. Station Dialing In addition to the menu/route, callers may access an individual station either through the input of the extension number or the input of the called party's last name. A total of 2,000 names plus 100 extension numbers will be possible. Vendor Response Requirement Confirm support for this operation. Ericsson Response: MX-ONE Messaging provides this capability. 7.2.4 Answer Announcement Individual, personalized announcements of 15-30 seconds


for each mailbox user will be possible. A user's dictated answer message will only occupy the number of seconds dictated, with the remainder to be pooled so as to be available to: 1) all other mailbox owners; and, 2) for message taking. A system announcement of up to 30 seconds will be possible and also will be available in the event of switching system failure. It will be possible for the mailbox owner to input separate greetings for calls received internally or externally on the system. It will be possible for several individuals to share the same mailbox extension number. A caller reaching such a mailbox will be able to select between individual mailboxes. Vendor Response Requirement Confirm support for these operations. Ericsson Response: MX-ONE Messaging provides these features. 7.2.5 DTMF Signaling The system will be capable of receiving and generating standard DTMF tone signaling. Vendor Response Requirement Confirm support for this feature. Ericsson Response: The MX-ONE Messaging system provides DTMF signaling. 7.2.6 Greeting Voice mail calls will be answered on the first ring and be time- and date-stamped. Vendor Response Requirement Confirm support for this feature. Ericsson Response: The MX-ONE Messaging system provides DTMF signaling. 7.2.7 Escape A caller reaching the voice mail system will have the ability to re-route to an extension by dialing up to five digits or the operator by dialing "0" before or


after leaving a message. It will not be possible for a caller reconnected to the telephone system to be connected to the public network. Vendor Response Requirement Confirm support for this feature. Ericsson Response: MX-ONE Messaging provides this capability. 7.2.8 Trunk Access It will be impossible for a caller passing through the attendant to reach an outside line. Vendor Response Requirement Confirm support for this feature. Ericsson Response: MX-ONE Messaging in conjunction with MX-ONE provides this capability. 7.2.9 Distribution Lists The system will contain a minimum of 80 distribution lists of at least 25 names each plus "all broadcast." Vendor Response Requirement Confirm support for this feature. Ericsson Response: MX-ONE Messaging provides this feature. A distribution list can contain up to 200 entries, including other distribution lists. 7.2.10 Message Forwarding Messages may be forwarded to single or multiple destinations with or without introductory comments. Vendor Response Requirement Confirm support for this feature.


Ericsson Response: Message Forwarding is supported. 7.2.11 Audit Trail It will be possible for a user to designate a necessary written record of message destination, input time and receipt. This audit trail will be printed on the administrative console together with daily reports. Vendor Response Requirement Confirm support for this feature. Ericsson Response: MX-ONE Messaging provides the Report utility, which enables the administrators to obtain information about the MX-ONE Messaging system, its usage, and its mailbox configurations. It also enables the user to determine which subscribers are using the system, how often they call in for messages, and how many messages they currently have stored in their mailboxes. The Reports utility can create a number of standard reports that can be used to review the system. It also allows the user to export report information to a number of file formats that you can use to create user’s own custom reports. MX-ONE Messaging provides two standard reports for managing user messages: Message Log and Message Status report. The Message Log report displays activity on messages – when they were created, listened to, and deleted. The report is organized by mailbox number and shows the date and time at which each mailbox performed any of the following actions on any message:

• Create

• Save

• Play

• Skip

• Deleted

The Message Status report displays the status of all messages, including network messages. Administrators may use this report, for example, when they need to verify the status of a certain message—whether it exists as a new


message, has been saved for further action by the mailbox owner, has been set for future delivery (but has not yet been delivered), or has been purged by the telephony server. They can also see who sent the message and when the message was posted (date and time). 7.2.12 Message Indication The receipt of a message in a mailbox will cause a message-waiting lamp or "stutter" dial tone upon lifting of the station handset to indicate a message-waiting condition. Vendor Response Requirement Confirm support for this feature. Ericsson Response: MX-ONE Messaging in conjunction with MX-ONE provides this capability (both message-waiting lamp and stutter dial tone). 7.2.13 Identification Code Users accessing the system will input a discrete six-digit identification code which will be positively validated prior to access to their mailbox. Identification codes may be changed by mailbox owner. Vendor Response Requirement Confirm support for this feature. Ericsson Response: MX-ONE Messaging provides this capability. The password length can range from 2-15 digits. 7.2.14 Message Recovery The mailbox owner accessing the mailbox will be automatically told how many new messages have been received since last access and how many saved messages exist. Upon accessing the messages, the subscriber will have the choice of deleting, skipping or saving a message. Saved messages may only be deleted by the subscriber or by the system administrator. Vendor Response Requirement Confirm support for this feature.


Ericsson Response: MX-ONE Messaging provides this capability. 7.2.15 Message Reply A mailbox owner may respond to a message input by another system mailbox owner by simply depressing a single key. Vendor Response Requirement Confirm support for this feature. Ericsson Response: MX-ONE Messaging provides this capability. 7.2.16 Message Review It will be possible for a user to review and edit either an announcement or input a message. Vendor Response Requirement Confirm support for this feature. Ericsson Response: MX-ONE Messaging provides this capability. 7.2.17 User Controls A user accessing their mailbox will be capable of the following control functions: 1. Playback messages 2. Skip to next message 3. Cancel review 4. Replay last message 5. Replay faster or slower 6. Pause 7. Append information 8. Forward message (to mailbox or list) 9. Create new answer announcement 10. Increase play-back volume Vendor Response Requirement Confirm support for this feature. Indicate if any function is not supported.


Ericsson Response: The listed features are supported by MX-ONE Messaging. 7.2.18 System Management Console The system will be equipped with a CRT and printer to provide system management functions. The administrative programs and traffic information secured will be possible during system operation. Traffic reports will be available on customer demand or automatically on a pre-programmed basis in quarter, half or one hour time frames or daily and weekly. At a minimum, they will indicate the following: 1. Storage space used for announcements or information mailboxes. 2. Storage space used for messages. 3. Maximum storage space used during the interval. Vendor Response Requirement Confirm support for this feature. Indicate if any requirement is not supported. Ericsson Response: MX-ONE Messaging provides the following utilities for system management functions: The Administration utility provides several levels of security, allowing you to create administrator accounts with different degrees of authority over the telephony server and its mailboxes. The MX-ONE Messaging SNMP extension agent can provide management information about the telephony server to any SNMP management console that can use management info base (.mib) or trap definition (.tdf) files. The MIB provides information such as Hours and Minutes of Storage Remaining, Service Name, Service Status. Once the extension agent has been installed and a management console has been configured to manage it, you can use it to manage the telephony server from another computer on the same LAN or WAN. The Report utility enables the administrators to obtain information about the MX-ONE Messaging system, its usage, and its mailbox configurations. It also enables the user to determine which subscribers are using the system, how often they call in for


messages, and how many messages they currently have stored in their mailboxes. The Reports utility can create a number of standard reports that can be used to review the system. It also allows the user to export report information to a number of file formats that you can use to create user’s own custom reports. 7.2.19 Traffic Reports Traffic reports will be available on customer demand or automatically on a pre-programmed basis in quarter, half or one hour time frames or daily and weekly. At a minimum, they will indicate the following: 1. Storage space used for announcements 2. Total calls answered 3. Total calls routed to station 4. Total calls routed to default 5. Total calls abandoned 6. CCS use and call count by input Vendor Response Requirement Confirm support for this feature. Indicate if any requirement is not supported Ericsson Response: MX-ONE Messaging provides the standard reports Port Usage and Call Handling Statistics traffic type reports. The Port Usage report displays overall usage of each port in the system, including the number of calls each handles and the total length of time it was in use for each day in the specified range. You can use this report to determine whether or not the system requires additional lines in order to handle the current workload. The Call Handling Statistics report displays both detailed and summary information about system activity over a specified period of time for the automated attendant. The report includes categories for tallying the total number of calls answered, total transfers, and results of transfers, hold requests, messages taken, directory requests, and time/port usage information. Some data on the report is provided in both numbers and percentages. You can use this report to determine how the system is being used by subscribers and outside callers, including what services or features they are using. Other useful information that can be gained through this report includes the following: • How effectively the system’s ports are being used

• Whether or not callers are staying on the line when they hear the


initial recorded announcement

• How many times callers transfer to the operator

• How many times callers access the directory

• How often callers leave messages after being placed on hold

• How many transfers are not completed and why they are not completed

• What portion of incoming calls are handled by the telephony server’s automated attendant features

• What portion of incoming calls are placed by subscribers retrieving or sending messages

The information in this report will help you determine how well your application is received by those who call your organization. 7.2.20 System Changeability It will be possible for the system administrator to add and/or delete mailboxes, change general recordings and perform other administrative duties while the system is in operation. Vendor Response Requirement Confirm support for this feature Ericsson Response: The above operation is supported. MX-ONE Messaging provides this capability. 7.3.0 Networking VoiceCon plans on networking it new HQ messaging system to other VoiceCon locations equipped with messaging systems. 7.3.1 AMIS The proposed messaging system should support AMIS networking standards. Vendor Response Requirement Confirm support for these features Ericsson Response: The AMIS networking standard is support by MX-ONE Messaging. 7.3.2 Digital IP Networking The proposed messaging system should support VPIM networking standards.


Vendor Response Requirement Briefly describe digital networking capabilities of your proposed messaging system solution. Indicate if VPIM is supported. Ericsson Response: MX-ONE Messaging supports VPIM digital networking standard. NetConnect digital networking is an advanced MX-ONE Messaging application that allows telephony servers to exchange voice and fax messages over any network based on the TCP/IP protocol—a local area network (LAN), a wide area network (WAN), or the Internet. This section provides a quick overview of this powerful application. Two different digital networking options are available for MX-ONE Messaging telephony servers: • Basic NetConnect digital networking - Can exchange voice and fax

messages with other MX-ONE Messaging telephony servers

• NetConnect digital networking with inter-vendor support - Can exchange voice messages with voice mail systems supporting the Voice Profile for Internet Mail (VPIM) standard.

7.4 Integrated Messaging Application Vendor Response Requirement Briefly describe how the proposed voice messaging system is to be integrated with VoiceCon’s text messaging system, based on a MS Exchange server, to provide unified messaging system functionality. Station users must be able to view and access all messages (voice, text, fax) from their PC display monitor. Email text messages must be accessable from a telephone using text-to-speech conversion. Ericsson Response: With Unified Messaging for Microsoft Exchange, subscribers can manage voice, fax, and email messages using Microsoft Outlook. Unified Messaging accomplishes this by enhancing the Microsoft Outlook email client so that it can support voice and fax messages in addition to email messages. The concept of managing voice, fax, and email messages within a single application program is known as unified messaging. Unlike other Desktop Suite applications that store messages on the voice messaging server or in the email client, Unified Messaging for Microsoft Exchange stores all voice and fax messages on the Exchange server along with email messages. As


each voice and fax message is received, it is automatically moved from the MX-ONE Messaging server to the Exchange server, where it is still accessible in its native form as a voice or fax message. Because the messages are stored on the Exchange server, Unified Messaging for Microsoft Exchange is sometimes referred to as server-based unified messaging. With Unified Messaging for Microsoft Exchange, subscribers have two options for accessing their messages from the Exchange server’s unified message store. They can use either the telephone user interface (TUI) or the graphic user interface (GUI) by using the enhanced Microsoft Outlook email client. With TUI access, subscribers can manage their email messages by telephone using MX-ONE Messaging telephone commands. They begin this process by logging into the MX-ONE Messaging server, which then checks their accounts on the email server and enumerates their messages. MX-ONE Messaging presents messages so that the subscribers can retrieve their information in the easiest way possible over the telephone: • Voice messages are played back directly.

• Email messages are read aloud using text-to-speech capabilities, starting with information about the email messages’ subjects and senders.

• Fax messages are announced as such with their delivery dates, delivery times, and page counts, as well as the sender’s name if the sender was another subscriber. The subscriber must send the fax message to a fax machine for printing to view it.

During the installation of the Unified Messaging software, Microsoft Outlook is modified to support voice and fax messages as follows: • New icons are added to the GUI. In the Inbox, a voice message is

signified by a telephone icon, whereas fax and voice-annotated fax messages are denoted by a fax sheet icon.

• MX-ONE Messaging messages are identified as such in the subject line.

• New voice and fax message forms are included. The voice message form includes media player controls that support both the playback and recording of voice messages. The subscriber can select either the computer sound device (if present) or telephone for playback and recording.

• Allows subscribers to listen to, create, reply to, and forward voice messages over a computer sound device (such as a PC sound


card), allowing them to use MX-ONE Messaging functions without a telephone.

• Allows subscribers to record their name and greetings over a computer sound device.

• Allows subscribers to set call blocking, call screening, and Extension Specific Processing (ESP), if those features are allowed for them.

E-mail

Fax mail

Voice mail

E-mail

Fax mail

Voice mail


8.0.0 Contact Center (Informational, only) VoiceCon has future plans to install and operate a mid-size contact center solution across its three HQ locations. The contact center would integrate incoming voice, email, and web contacts from customers, and also support outgoing voice calls to potential customers. It is anticipated that the contact center will require 50 multifunction agents positions, and 5 supervisor positions. The contact center features and functions are NOT to be included in the configuration or pricing proposal. 8.1.0 Incoming Voice Call Center The voice contact center solution should support call prompting, detailed call screening, and intelligent call routing capabilities. Agent groups should be both fixed and virtual based on skill profiles of the agents. Client/server CTI applications must be supported at all agent desks. Agent group assignments must be able to be distributed across the three HQ locations. The system should be designed to minimize agent requirements and call waiting times. Realtime supervisor reports and detailed historical reporting is required. Vendor Response Requirement Briefly describe you’re the system architecture of your incoming voice call center solution to satisfy VoiceCon’s basic requirements (see below). Include specific information about the system design architecture of your solution (hardware and software requirements), and specific capacity parameters for agents, supervisors, groups, announcements, queue slots, trunks and trunk groups, et al. Ericsson Response: Overview of the Solidus eCare™ Application Suite The Solidus eCare application suite is made up of eight core applications. These core applications are divided into three fundamental categories:

Agent Applications

Desktop Manager • Desktop Manager Standard – provides call control capabilities

to the agent desktop.


• Desktop Manager Supervisor – extends the standard capability

by enabling additional intrusion and monitoring capabilities. • Desktop Manager DDE & COM – extends the Desktop Manager

standard capability by enabling integration to external applications and databases. Typically used for screen-pop applications.

• Desktop Manager Messaging – extends the interactive capability between agents and within the business by facilitating internal messaging communication.

• Desktop Manager Directory - extends the Desktop Manager standard software module by enabling agents to locate personnel within an organization for on-line support or customer query confirmation/support.

• Desktop Manager Outbound – extends the Desktop Manager standard software module by enabling basic preview outbound voice calls to be placed.

• Desktop Manager Agent Recording – extends the Desktop Manager standard software module by enabling conversations between agents and customers to be recorded and stored for quality assurance programs, training and/or legal indemnity purposes.

• Desktop Manager Agent Scripting – this module, used in conjunction with the Desktop Manager Outbound agent enables agents to conduct efficient customer questionnaires within the context of a campaign.

• Desktop Manager Web Agent – extends the Desktop Manager standard module by enabling the use of alternative media including chat and web collaboration.


• Desktop Manager E-mail Agent – extends the Desktop Manager standard module by enabling agents to interact with customers via e-mail. When used in conjunction with the Internet Suite Creator, Auto-email response functionality is provided.

• Desktop Manager IP Agent – allows Desktop Manager agents to use configured IP extensions for all call control features, thereby eliminating the need for agents to have a physical telephone.

Route Manager This agent module is used for mobile agents, or non-Desktop Manager agents. Therefore, warehouse staff, security staff or agents with mobility, can be incorporated into the contact center.

Management Applications

Report Manager A flexible reporting tool that provides historical statistical reporting and information on all contact center activities.

Configuration Manager A graphical windows application that provides configuration management and the editing of contact center elements such as call flows, rules and guidelines.

Information Manager Provides real time information on all contact center activities.

Knowledgebase Manager Provides an authoring interface towards the knowledge bases. Knowledge bases are used with the Web-based self-help application (Virtual Agents) and auto e-mail response interaction.

Customer Self-service Applications


Script Manager A fully integrated Interactive Voice Response (IVR) application that extends the routing intelligence and capability of Solidus eCare suite. Used to enable advanced customer access to database lookups and PIN code verifications, the primary use of Script Manager is to provide voice bound customers with self-service. Simultaneously, Script Manager is used to accurately identify the needs of the customer, prior to the customer being allocated to a Solidus eCare agent.

Virtual Agent An interactive Web response application that automates customer self-service. The Virtual Agent resides on your website, resolves customer enquiries without agent intervention through the use of customized knowledge bases.

Automated Attendant Automated Attendant is used to greet voice caller when Script Manager is not used. This feature enables auto-answering of incoming calls together with the offering of menu choices. When answered, the caller will be offered with an initial welcome greeting message and then menu choices where live transfer will be facilitated. 8.1.1 Basic Call Control Capabilities At a minimum the proposed solution must be able to provide call control based on: • ANI/DNIS • call volumes • performance criteria • priority queuing Vendor Response Requirement Briefly describe the call control methodology used by your system that analyzes, routes, and queues calls based on each of the criteria.


Ericsson Response: Call routing may be performed based on DNIS, ANI database look-up, current queue situation, and agent availability. Each service (queue) can be assigned a priority on a scale of 1 to 100. 8.1.2 Advanced Call Control Capabilities As an option the proposed solution must be able to provide call control based on: • agent skills • customer preference • inbound and outbound call levels • multi-media Vendor Response Requirement Briefly describe your system’s call control methodology that analyzes, routes, and queues calls based on each of the criteria. Ericsson Response: Solidus eCare is a skills-based routing system, where each user (agent) is given a unique skill-set that is matched against the needs required by the customer. It is a fully blended system, where agents can work seamlessly with inbound/outbound voice, email and live chat, based on user defined criteria’s. 8.1.3 Caller Notification of Wait Time The proposed solution must be able to notify callers of expected wait times and “place” in queue and support information collection (such as an automated attendant feature) using “internal” hardware and software. Vendor Response Requirement Describe how the application calculates wait time and any optional hardware or software required. Include a statement addressing if the announcement of wait time has an impact on a caller’s state in queue? Ericsson Response: Solidus can provide queued caller with estimated wait time and/or place in queue (queue position). The system can calculate EWT in two different ways based on what works best for a particular customer. One way is to base EWT on the average wait time for the last 10 queued calls to a particular service. This works well for most customer, but has the drawback of not considering change in agent availability. The other (patented) way is to also consider number of serving agents (with correct skill-set) in the formula. This way works


very well for sites that experience heavy call load, and need to take changes in agent availability (e.g. 10 agents suddenly logs off) into consideration. 8.1.4 Transfer to Voice Messaging Application After a configurable time, the caller should be able to transfer to a voice messaging system to leave a callback message. Vendor Response Requirement If the caller chooses to continue waiting rather than hanging up after leaving a message, describe how the call is placed back in queue. Ericsson Response: This is a standard feature in Solidus. The option to leave the queue can be given at any time to the caller and is fully user configurable. 8.1.5 GUI Administration Tool Supervisors must be able to reconfigure call control and assignments in real time, change priority of multiple calls simultaneously, view details of orphaned calls and retain customized settings regardless of log-on location. The solution must use a GUI administration tool and provide a graphical editor and what-if modeling as standard. Vendor Response Requirement Describe the system’s GUI administration tools. Ericsson Response: Changes to the configuration (skills, messages etc.) take affect immediately and can be done in real-time. All configuration changes can be done at a central location and is done in an easy to use graphical environment. 8.1.6 Soft Client A soft client agent telephone and supervisor console will be highly desirable for both premises and off-premises locations. Vendor Response Requirement


Describe the soft clients available for agent and supervisor use. The soft client must provide on-line help, ability to reserve calls or change call priority. For proprietary clients, detail minimum hardware and software requirements. Ericsson Response: Solidus provides an embedded VoIP client (H.323) as well as soft client support for any type of telephone (analog, digital, IP telephone, mobile extension etc). From this application, agents and supervisors can view service statistics in real-time, change routing by adding/removing skills for self or others (if privileged), ask for and provide assistance (for voice calls, emails and chats), communicate via desktop messaging for quick questions/answers, monitor agents by listening in and many more functions. 8.1.7 ACD Voice Terminal IP desktop voice terminal instruments will be required for agent positions. Vendor Response Requirement Briefly describe any telephone instruments designed specifically for ACD agents. Include any and all feature/function attributes unique to ACD operations. Provide a photograph of the instrument, if available. Ericsson Response: Agents can use any telephone connected to the MX-ONE. There is no special/dedicated telephone needed for the agents. All information related to the call/contact center is presented to the agent via the Desktop Manager client.


Desktop Manager Screen 8.1.8 Supervisor Real-time Call Handling and Performance Status Supervisor terminals must show, in real time, all logged-on agents, the status of each agent, caller queue information and thresholds and alarms. Users must be able to customize displays. Vendor Response Requirement Describe the proposed solution's real time supervisor console display capabilities for assisting supervisors with managing the customer interaction center. Include a diagram illustrating two or three screen displays available to the supervisor. Ericsson Response: Solidus provides this type of information to supervisors to monitor members of their agent group and to agents (to monitor themselves).

Information Manager Enables the viewing of real time information on:

• Service accesses • Service groups • Agent groups • Agents


• Virtual agents View performance alarms that activate when limits are exceeded

View alarms that activate when media traffic exceeds a predefined threshold

Configuration and definition on real time information for wall boards


8.1.9 Agent Display Information Vendor Response Requirement Describe real-time display information provided to agents at their desktop via their hard telephone instrument and the softclient solution.


Ericsson Response: Agent display information is provided via Desktop Manager. The Real Time Information will give agents the possibility to see status on each queue, how many agents are logged in, the number of agents busy, and status on each agent etc.

8.2.0 Reporting VoiceCon requires call center system operation reports in various formats. 8.2.1 Statistical and Configuration Reporting VoiceCon requires sophisticated reporting to track and further enhance its CIC operations. Reports must be available on terminal display and paper printout and be able to be downloaded to a PC. The proposed solution must provide open storage capability. Vendor Response Requirement


Describe the number of and type of information standard statistical, configuration and audit reports provided. Ericsson Response: Solidus provides a flexible reporting application, Report Manager. All historical data, including detailed CDR (cradle to grave) are stored in an open SQL database. Using report Manager, the user can view reports on screen, send to printer, save to file (.csv/excel or HTML formats), or send reports as email. The user can schedule daily, weekly or monthly reports (to file, printer, web, or email). Produces reports using

• Standard templates

• Customized templates

Schedule reports to be created at specific times or intervals

• Email or HTML

Produces reports to communicate and analyze

• Agent and service access status

• Call flow and call record status

• Outbound call campaign activities

Cradle-to-grave reporting

8.2.1 Graphical Reporting The proposed solution must provide graphical reports as a standard feature. Vendor Response Requirement Describe the available graphical reports with your system.


Ericsson Response: Solidus provides a graphical reporting package (based on Excel) where the user can choose from 13 ready made templates and produce graphical reports in various formats.

8.2.2 Call-by-Call Reporting The proposed solution must provide call-by-call reporting as an optional feature. Vendor Response Requirement Describe your system’s call-by-call reporting capabilities, if available. Ericsson Response: All detailed events for all transactions (voice, email or chat) are logged, event-by-event, in an open SQL database. The Report Manager application provides tools (with filtering capability) to view these CDRs.


8.3.0 Self Service The proposed solution must support self service (e.g., IVR) integration as an option. Callers must be able to retain their place in queue while using IVR features Vendor Response Requirement Describe your system’s ability to support inbound calling, call control services, messaging for agents, speech recognition, text-to-speech, TDD and CTI and integration with a customer self-service interaction application. Ericsson Response: Self service is one of the key aspects of the Solidus contact center. Solidus includes an integrated Interactive Voice Response (IVR) application, Script Manager. This IVR includes tools to build very sophisticated self service application. It supports speech recognition and Text to speech by integration with engines from Nuance and Scansoft, it supports access to any ODBC database, playing and recording of voice files, sending and receiving of DTMF tones and much more. It provides the capability to extend the functionality by Visual basic and java scripting, and incorporation of C++ hooks. For the internet, Solidus uses knowledgebase technology to provide Q and A responses to questions. The customer interacts in a chat session with a SW based agent, who replies with knowledgebase answers and pushes relevant web pages to the customer. For emails, the same knowledgebase (KB) can be used to provide self service. Solidus can scan incoming emails for questions, send these to the KB and pre-fill the answers (including associated URLs in an automatic reply to the customer. 8.3.1 Script Development Vendor Response Requirement Describe the design tools/environment for IVR script development, the method used to test applications and changes prior to putting them into production and the method of putting changes into production.


Ericsson Response: Applications are developed in an easy to use drag and drop graphical environment. A tracer application is included, where the IVR developer can view in real-time what is happening in the script during debugging and testing.

8.4.0 Workforce Management System The proposed solution must provide forecasting and scheduling capabilities as an option. Vendor Response Requirement Describe your system’s workforce management capabilities.


Ericsson Response: Solidus has certified integrations with several vendors of WFM systems. These include Blue Pumpkin, Aspect/TCS, Invision. and TeleOpti. Solidus provides real-time adherence APIs, and database interface kits for any WFM system to use. 8.5.0 Integrated Email Call Control The proposed solution must integrate customer email messages as an option. It is also desirable that agents be able to handle a mix of voice and email messages on a call-by-call basis, and that all incoming voice calls and emails be routed into the same agent queue(s). Vendor Response Requirement Decribe your system’s capability to integrate email contact center functions with your voice call center system. Include information about the hardware and software requirements for this application. Ericsson Response: Email is fully integrated into the Solidus system. Solidus works with MS Exchange or Lotus Domino email servers. Incoming emails are routed to agents using exactly the same routing principles as other medias (voice, chat etc.). Agents can be configured to handle voice/chat/emails simultaneously or if busy on email should also busy him/her out for voice. Also, it is configurable how many emails that are provided to each agent at the same time. 8.6.0 Web Center VoiceCon anticipates that it will require integration of its call center with its web server system. The proposed solution must support customer-initiated contact through the Internet as an option. Vendor Response Requirement Describe how your call center can be integrated with the VoiceCon website to allow agents to respond to customer callback requests via the website. Include in the discussion whether agents can collaborate in realtime with callers during an online website transaction. Ericsson Response: Web-call back is a standard feature of Solidus. A link for the customer to enter their phone number, and optionally time/date (or immediately) for the call-back. The call back will be routed to agents as any other type of request, and the system will automatically dial


the number for the selected agent. The Internet Suite of Solidus provides web self service, live chat, page pushing and web-collaboration. 8.7.0 Outbound Dialing The proposed solution must support automated outbound predictive dialing as an option. Vendor Response Requirement Describe your system’s capabilties to perform outbound predictive dialing, and include necessary hardware/software requirements. Ericsson Response: Solidus Campaign Manager provides the functionality to configure outbound campaigns. Phone numbers are imported to a call list, compared to a do-not call list, and required agent skills are defined. Calls are automatically dialed by the system, and the agent can be prompted by an associated agent script. The results from the agent’s scripts are stored in the database for reporting on effectiveness and hit rate etc. 8.8.0 Server-Based CTI Call Control The proposed solution must support server-based CTI applications as an option. Vendor Response Requirement Describe the capabilities of the proposed solution to simultaneously route a call and data screen populated with the caller's identity, location or reason for calling. Ericsson Response: Solidus runs on a call control and media server called OAS (Open Application Server). Any information about the call (could be information collected by the IVR from caller input and/or database look-ups) will be delivered together with the call and presented to the agent. If the agent transfers the call to another agent, or is asking for assistance from a supervisor, the caller information travels with the call. The caller information can also be used to provide integration with other applications used in the contact center, using either server based or client based integrations.


Part 2: System Pricing 1.0 System Pricing Requirements Summary system and voice terminal pricing data will be presented to VoiceCon workshop attendees and be deemed for public use. Detailed pricing data will remain confidential, and used to verify if the proposed system configurations satisfy RFP requirements. Installation fee pricing data is required, and must be included in the RFP response. Indicate if the proposed installation fee is based on direct sales/service or a channel partner pricing schedule. The proposed system price must also include a 1-year warranty to the customer. If this is a pricing option in your pricing schedule include it as part of the installation fee, and identify it as such. 2.0 Summary Pricing – VOICECON NETWORK (all five locations) Complete and submit the attached EXCEL data table for your proposed system pricing summary data. The submitted data will be made available to the general public. System Summary Pricing All Common Equipment (call processing, port interfaces, media gateways, housings, power, feature/application servers, et al) Generic Software (Standard Features) Optional Software Features/Packages IP Port License Fees (if applicable) Desktop Voice Terminals Systems Management/Administration System Messaging System Installation Fee (including 1-year warranty)


TOTAL Ericsson Response: System Summary Pricing has been provided in the Excel “04_PART2 2.0 Summary Pricing.xls” 3.0 Desktop Voice Terminal Pricing Complete and submit the attached EXCEL data table for your proposed Desktop Voice Terminal pricing summary data. The submitted data will be made available to the general public. Voice Terminals Economy Desktop IP Telephone Instrument Administrative Desktop IP Telephone Instrument Professional Desktop IP Telephone Instrument Executive Desktop IP Telephone Instrument IP Audio conferencing Unit PC Client Softphone (Station User) License Fee PC Client Softphone (Attendant) License Fee Key Module Add-on Gigabit Ethernet Module Add-on Display Module Add-on WLAN Module Add-on Desktop Power Module Option

Ericsson Response: Desktop Voice Terminal Pricing has been provided in the Excel “04_PART2 2.0 Summary Pricing.xls”.


4.0 Detailed Configuration Components and Pricing Submit a separate EXCEL file with a detailed listing of proposed communications system components/elements and associated unit pricing, also indicating the proposed unit quantities included in the configuration for the base system (HQ facility). Also include an additional section with the configuration hardware/software elements and associated pricing data to satisfy each of the remote facilities (small, medium, large). Provide English language descriptions of all price configuration system components and elements in addition to any proprietary order codes. At minimum, the configuration component list should contain:

- All common control elements - All common equipment port cabinets/carriers - All port circuit interface cards for station and trunk ports - All media gateway equipment for station and trunk ports - All call control signaling interface cards - All voice terminals, including audioconferencing units - Generic software - All port license fees - All optional software packages

o Include all optional adjunct server equipment to support of required features o All voice messaging system elements (cabinet equipment and memory storage)

- All systems management elements The detailed pricing file will NOT be made public, but will be used by VoiceCon, only, to verify adherance to system configuration performance requirements and pricing summary data.

Ericsson Response: Detailed Configuration Components and Pricing has been provided in the Excel “05_PART2 4.0 Detailed Configuration Components and Pricing.xls”.

voicecon request for proposal for an ip telephony system€¦ · voicecon request for proposal for...

Documents