Here's are some reasons why this is a huge milestone:
1) GV uses available networks to transport communications sessions. Currently we pay exorbitant monthly charges for dedicated circuits to the Public Telephone Network (PTN) for outbound and inbound voice paths used for phone calls. (For 9-1-1 we would maintain a group of dedicated circuits to identify the local origination of call for emergency services.)
2) Integrated directory information is immediately available when I place a GV call. GV looks in my address book for matches and displays choices. It might be worth a chat with GV to determine if we could link a central database of names and numbers as well as local look up. The result could be a streamlined method to contact any CIC University as well as any PSU student, faculty or staff person currently contained in the LDAP entries.
3) There's promise with this new change and we might be able to leverage it to save infrastructure dollars in the near term. How? It's not as easy as it could be, since GV does not support Session Initiation Protocol (SIP). If it were possible to use SIP we could easily point all of our outbound calling to GV. I guess they know the inevitable outcome if SIP was supported and have chosen to develop a business case at some point to enable direct connection with an associated cost. If you know more about this possibility, then please fill us in on the future steps.
4) It's one more brick off of the wall. Phone numbers were once user identifiers. Certainly they will remain as business and departmental portals when voice communications are in play. But there are some distinct advantages in identifying a person rather than a department in most every case except a quest for general information. If you think I'm wrong, then call one of the larger retailers. They auto-answer your call and subject you to a set of choices. Why? Because you want something and they have a person who can help. When they find out what it is you want, then the person who is most skilled in the thing you want will answer.
5) It's free, it's cool and Google is doing the right thing here.
If you are interested in SIP and SIP trunking, this link is marketing-heavy but can lead you to more information http://tinyurl.com/5w97ce
This is the first phase of several ongoing developments. The first phase enables the SIP protocol to contact any other registered PSU user via their UserID. Because SIP is an open protocol, anyone from anywhere in the world is capable of contacting you by entering your userID and domain (e.g., pjc8@psu.edu).
-----------------------------
Soft Phone Service Announcement
All ITS Staff members are invited to participate in the release of a new communications service that enables Voice, Video, and Instant Messaging chat through a software client you install on your computer. The service, currently referred to as, "Soft Phone," is in its initial phase of development and is being offered in a controlled release to ITS personnel-only, at this time. This first phase is expected to end in Summer of 2009.
Please note this service is EXPERIMENTAL and DOES NOT offer emergency services or 9-1-1 dialing capability. The users of this service are responsible to configure their PC, Mac or Linux computing platform client and are encouraged to participate in providing feedback and input regarding this new service offering.
The Soft Phone service enables ITS Staff participants to communicate to others using their computer via any TCP/IP network. After the download and configuration of the recommended open source software client, a Soft Phone client will appear as a display panel on your computer screen. Communications can then be established to fellow ITS staff participants or to anyone in the world where internet connectivity is available. This is accomplished by using your computer keyboard to input a Penn State user ID (i.e. xyz1) or a Fully Qualified Domain Name (FQDN) if the person you wish to contact is not a registered Penn State user. An active example is 904@mouselike.org. (This link is a test server in London, UK, and provides an automated site where a few interesting tests can be performed.)
People from outside of Penn State are able to contact your Soft Phone client and are not required to sign up for the Penn State service to do so. This is accomplished by the other party installing a Soft Phone client on their computing platform and inputting both your user ID as well as the full domain name, e.g., userID@psu.edu.
Additional information and set up instructions are provided at https://wikispaces.psu.edu/display/softphone/Home. ITS Staff participants are encouraged to provide feedback and input regarding the Soft Phone offering. In order to improve this future service offering, please submit your comments to the wiki space link shown above.
Questions regarding client configuration are answered via http://kb.its.psu.edu/search?SearchableText=softphone . Difficulties encountered during client configuration should be reported to the VoIP Help Desk (ais-support@psu.edu) or by calling 814-863-4032. Thanks in advance for your assistance and participation. We look forward to your feedback.
--------------------
I will describe where where we are now in terms of voice service choices for end users and will attempt to provide some details on the strategic implications of each service. Today and in the past, business analog service is availble to those users who choose not to upgrade to VoIP or cannot do so because of infrastructure limitations. Verizon Centrex provides business analog dial tone services for the UP residence halls and provides emergency as well as elevator phones. At some point business analog could be contracted through a alternate vendor if costs rise to a point where alternates are sought; but for the foreseeable future TNS will continue to offer a business analog service.
By 2001 a group at U.P. had begun testing with the second generation of VoIP hardware. A large part of the testing was related to developing network specifications in order to ensure a reliable and supportable VoIP system to be overlaid onto the University Park Campus portion of the network. As a result of the testing as well as the ongoing administrative overhead of proving and procuring a scalable VoIP system was put in place. The VoIP system today has almost 13,000 IP phones and we are driving towards the migration of a portion of the 5,000 or so business analog phones to VoIP. The University Park VoIP system connects to the outside world primarily via the PSTN, although a secured link from a field trial SIP system allows inbound calls to reach the VoIP system. Strategically this UP VoIP system is expected to remain in place for the foreseeable future, beyond five years -- due to the limited capabilities of crystal ball I use (smile). TNS' focus is to upgrade the system regularly in order to preserve supportability (by Cisco, the vendor) and to continue with network changes towards continuous improvement to the availability of UP VoIP.
The field trial of the SIP system is over and Soft Phone service will begin this September. We're very close and we need to complete the access and authentication portion, the "front end" of this service, before it can be released. Soft Phone is similar to Skye in that it enables identity based communications. What all does it do -- Soft Phone provides the feature set based upon the client you choose. If the client you choose supports voice, video and chat, then these will function with the first and all subsequent phases of Soft Phone. The first phase of this new service is straightforward and simple - it will enable authenticated and authorized users the ability to connect PSU UserID to UserID from any network to any network. The next phases include an improvement in functionality to enable inbound calling from Soft Phone to translate a PSU UserID to a phone number and to ring the telephone at the campus end. Soft Phone will leverage the central directory service already exists within our IP network in order to enable translations between PSU UserIDs and the telephone number listed in PSU LDAP. The next phases of Soft Phone (over the next 1 to 3 years) will see additional features and move system features up to a level where inbound calls from the public telephone network are delivered to soft phone clients.
The Soft Phone service is a standards based service, describing that end users can select their own SIP client and that the core equipment of Soft Phone will use open source code products such as Asterisk or SER. By using a standards based service TNS will achieve voice and video interoperability between unlike systems. A caveat needs to mentioned as some vendors have extended the standards and this will no doubt cause some features to fail, but overall the standards ensures that common functions will be successfully connected through network links where bandwidth and delay are within specification. Since Penn State’s IB is within these specifications, the structure of Soft Phone will enable inter-campus communications with relatively little effort and with modest cost for the core equipment . Since each campus location can decide whether or not to participate in Soft Phone; where participation requires dollars be spent to construct an IB connection and to put a security device in place, a team from TNS is already working with one campus to ensure the Soft Phone model is established via a field trial.
The end of the campus PBX upgrade project saw seventeen PBXs upgraded, including the two here at (UP) PSU Hospitality Services. The upgrade marked the new age of IP-PBX systems at all PSU campuses. As a partner to this change, TNS has worked closely with SOS and with end users to come up with an agreeable method to secure these sensitive systems while maintaining access for authorized functions. The PBXs are now protected by firewalls and the network routing is limited to PBX administrator access via the VPN.
In short, the idea found in the title of this post cannot be easily accomplished due to the structure of the University Park PBX dialing plans. Here's the why -- our on-system extensions are all five digit dials with the leading digit a 3,5 or a 7. Missed calls from on-system can be dialed from the missed calls list since the match is affected without requiring any editing.
Missed calls from the local area, such as 237-XXXX must include an exit code in order to be dialed successfully. An 8 was the exit code in centrex and this continued as a requirement for the purpose of dial plan transparency between the two systems. The 8 in front of a seven-digit number sends the call to the local calling routing table for a match.
Missed calls received from domestic long distance all require an 8+1 in order to complete when dialed, but you already know this if you use our PBX. The complexity involved in the solution we seek occurs because we need to match routes on calls for local and long distance without an exit code being present while contained in the missed calls list.
To further complicate matters, area codes and local exchanges are added fairly regularly creating a support nightmare for any ideas of growing the existing routing tables exponentially to support an easy solution.
A group of us met yesterday to detail the scope of the challenge and so far we have only the idea to create a method requiring two extra button pushes for dialing from the missed calls list. It's a very creative approach and utilizes the octothorpe to redirect the routing into a pattern and insert the necessary digits.
September 19, 2007
Connectivity Requirements List
_______________________________________________
Must be Ethernet RFC compliant media
Must include sufficient bandwidth for G.711 codec with 15,000 endpoints
Must scale to include 200% of the purchased bandwidth between the vendor’s PoP and Penn State’s call management server clusters, thus allowing for fail-over between the clusters while preserving 100% of inbound and outbound delivery capabilities.
Must be distributed on diverse fiber paths to buildings where core servers and gateways are located
Should contain options for alternate node routing of inbound calls
Should enable the option of co-locating Penn State’s core servers and gateways in vendor premises
Service Requirements List
_______________________________________________
Must accept E.164 outbound number delivery utilizing PSU station ID
Must provide CLID and Name on inbound calls, when available
Must provide 911 phase one compliance (ANI / ALI)
Must provide unlimited, non-metered, local calling within the State College MSA.
Should provide an unlimited CONUS calling package
Should provide Enhanced 911 (E911) service for registered subscribers
Should provide call detail containing PSU station ID information with date/time/duration information.
May contain translation of E.164 numbers to Penn State IP addresses, with ENUM or similar.
You may have already been nearby during one of my informal soapbox talks on open communications and implications of the Internet model on services in general. Every once in a while I read an article which offers not only an interesting analogy but also serves to capture the issue in a what I think is a unique perspective.
If you missed this month's issue of Von Magazine, then you probably did not see Bob Frankston's column. Here's the link to one of my favorite authors most recent diatribes:
http://vonmag.com/editorial/columnist/voip-visions-a-fine-way-to-run-a-railroad-but-not-an-internet
I like a strong challenge. Though I'm not always the standout who tends to offer one. As I continue my development it is clear that I want to rely upon past experiences and my gut-feel to maintain reassurances and control. Having been in the organization for more than a dozen years, I routinely offer a verbal challenge to what I label as "legacy thought". Upon further examination, I find that quite often my direction looks quite a bit as if it is following a similar path.
Finding new paths often means hiking in new areas. Proving the zest for challenge exists becomes the new paradigm with such a change. I'm interested in finding value in achieving validation with my new peers and gaining more confidence in the idea that long term institutional significance can be achieved for those who seek to drive change.
Communications are crucial to moving forward and I've learned that being a leader and succeeding means many things. Not always leading, trusting your folks to do what they think is correct and taking criticism as a constructive by-product of communications have all played an important part in my development to date.
I possess good analytical skills and have had success as a facilitator in complex projects. I'm a good listener and have a solid understanding of several levels of organizational function. Not surprisingly I harbor opinions on how to achieve change and seek others to commiserate with to make it so.
From talking with others who have attended ITLP I have come to expect this program represents an opportunity to help me realize how to see beyond some of my less useful assumptions and learned behaviours. I'm interested in participating and hopeful to help develop the group dynamic towards both learning and fun.
I was fortunate to be included in a most useful discussion with RhondaB, JimmyV and key folks from OSTN. We were together to finalize the last few technical steps toward activation of the OSTN channel on the Portal. We're very close and need to take a breath while the agreement makes its way up the chain.
The current OSTN offerings are multicast or unicast using MPEG-4. Offerings plural, as OSTN offers a set of services and is actively developing new ideas on how to further leverage network capabilities for video sources. The new stuff promises to be open source and seeks to improve an already robust and affordable means to stream video.
The future offerings will require multicast (yeah!) be in place for end user networks to successfully receive streams and will have a much broader set of options for locally created content as well as specialty video content such as foreign language channels, Al Jezeera and other notable sources.
I'm keen on working with OSTN to better understand their direction and how we can be participants in testing our collective ideas. In one of our next IPTV meetings we will include OSTN folks to discuss our ideas and directions prior to planning for some cycle time for actual testing.
--Phil
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
