Driftwood

Soft Phone Phase 1.0 - Identity Based Voice Communications

Points to be Addressed in a Proposal for a New Service:

1. Why is the proposed service believed to apply to the case at hand (what is the purpose for wanting to add the service, what are the user issues, what deficiency is thought to exist)?

The case at hand is a legacy voice service which was a major step towards utilization of PSU network resources for voice communications. While the suitability of call manager was largely based upon interoperability with network standards, the requirements and expectations of legacy telephony influenced the deployment of the system. The result is a voice system that is administratively complex and where the relationship with the vendor places both system administrators as well as the network design groups into a position where we are pulled along with regular upgrades in order to meet the vendor’s internal support requirements and are routinely drawn towards a one-vendor model when we look towards improvements to security and emergency services.
This proposal addresses the first phase of what is known as Soft Phone, a project where open source applications reside on industry-standard, supportable hardware and operating system platforms. This phase addresses the fundamentals of an open source application where a secure, customer driven service can be further developed to challenge legacy voice services across the University.
Users will be able to contact each other via the PSU IB by inputting a PSU UserID. It is expected that users will find this method of communication highly flexible, as calls can be placed to their fellow PSU users from any network.
Phase one has within it limitations which will be readily realized by our users. The following phases will address most of these limitations, those which we may have overlooked will be reported to us directly.

2. Would this service apply or be beneficial to others at UP?

This first phase of the Soft Phone deployment would benefit both UP and all other PSU campus locations and is seen as a calculated first step of development, thus allowing major design adjustments prior to the second phase being readied for release.

3. Would this service apply to all University locations?

All PSU locations will be able to intercommunicate with phase one.

4. What are the benefits to this service over existing offerings, or does this service provide something completely new (from a global perspective, not a single case perspective)?

Phase one (and all subsequent phases – there are currently six) are rooted in a user controlled domain, where identity is defined via PSU UserID and the system will be highly integrated. The base protocol, SIP, is a communications enabling protocol, thus allowing any real time protocols (video, among a few others) to utilize this basic phase one infrastructure.

5. From a strategic standpoint, what are the long-term benefits/drawbacks of providing the service?

Ease of use and with a lower cost than vendor provided communications services are notables in the benefits realm. With reliance upon software clients for the end users and open-source software, legacy support strategies are challenged.

6. Can the service be provided by another University group or by an outside third party?

No.

7. What options does the user/customer have if TNS does not provide the service?

None.

8. What are the proposed one time, recurring and usage rates for the service, and how do they compare to other available options (assuming there are any)?

One time costs and recurring rate should be reserved for phase 2.0 and subsequent phases. Chargeback for usage in this first phase is not necessary due to carriage is all via the PSU IB .

9. What are the operational support issues - do spares need to be carried and how many are suggested, does it use proprietary equipment, what are the delivery (lead) time issues?

The hardware platforms utilized are standard servers or are vendor-supported hardware units (such as the SBC/firewall devices). The operating systems are Linux, all are covered under the Red Hat Enterprise license. Spares for hardware should be reviewed in the same light as what has been done with Cisco Call Manager. For phase one the core redundant servers and the Session Border Controller (SBC) security devices will enable the service to be made available.

10. What are the training issues for operations, ITS user training staff and user training?

Hardware should be transparent in terms of what is being designed for core servers, the SBC devices are appliances and are supported by the vendor, and network topologies are documented. The service runs on Asterisk and IpTel SER software. Proficiency in core architecture of the service will be required.

ITS user training will require interaction with TLT for user training and will include help desk involvement. Both of these considerations will utilize service documentation as a basis. User training will require discoverable documentation as well as a knowledge transfer to the trainer and related customer support personnel.

11. What are the start-up costs (including operational support and training costs) for TNS?

The estimated one-time cost of $40,000 is to complete phase one requirements. Hardware support is estimated at 12-14% of the one time costs. The establishment of subscriber registration as well as an unrated billing for the service will be included with phase 1.0.

12. What are the technical issues - will technology changes make the service unnecessary in the future, is it a mature technology or prototype, has it been proven (tested) to work in the applications suggested (and what was the process for testing), what are the expectations regarding reliability, can it be applied to the existing infrastructure, etc.?

This is in reverse of the Question #1 above. The existing infrastructure will be used to enable the service and the reliability of the service will be as reliable as our infrastructure. The core hardware and software are well documented and well known for reliability. The architecture of the phase one service is a secured and limited-entry version of open SIP. Technology changes will be welcomed and the phase one architecture will change to enable future communications options using our secure SIP architecture.

13. Will new equipment be required?

Yes.

a. If applicable, what exactly is the proposed equipment (manufacturer and model numbers)?
HP DL380 G4 or G5 or similar capacity Dell branded servers.

aa. SBC hardware, software, and support contracts.

b. If applicable, what is the expected life cycle of the equipment (is it stable or will it require frequent change-outs until the technology stabilizes)?

Standard lifecycle is expected for the core equipment.

14.What is the projected start date for this service?

Fall 2007