Driftwood

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.
We are not yet into the testing phase but expect an update in a day or two at most.

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

A group got together yesterday with a couple of pizzas for a two hour discussion regarding the LAN topology to be put in place for the SoftPhone project. SoftPhone is the current title of the voice portion of the SIP communications project, coined to indicate a SIP client on a personal computing device used to call PSU IB-wide by providing the UserID of the person with whom you wish to communicate.

The concept is not new and much collective experience exists with SIP. The high level of the project includes several phases, the first phase actually takes a step back from an ongoing field trial where complex customization tied the open system SIP to the legacy VoIP system. I'll provide further details in a next set of posts on this topic.

The meeting -- Mark Linton, Scott Reed, Sven Schulz and I explored some really interesting LAN and some Layer 3 ideas to help move forward with completion of phase one. At the end we had a couple of questions -- one regarding how our edge security plays into the LAN topology -- is answered but we have some further work prior to moving forward. The quick take is we will architect a pair of SBCs to act as firewalls, positioned front and center of the traffic from the rest of the world. We have some design questions for the SBC vendor (Ingate) before deciding on how to best proceed.

These first steps sound important and they are for several reasons -- the phase one time line looms close (don't they all?), our next steps are equally critical -- completing AAA and a front end which needs reworked from the original trial, then some opportunities to talk, listen, sell, and provide additional knowledge transfer.

John Balogh, Tom Bayly, Ken Miller, Scott Reed, Sven Schulz

Meeting notes:

Update on OSTN -- a meeting is coming up this Thursday.

CATV -- service planning discussion.

Some what-ifs:

Commoditization of not only CATV for UP RHs; where (vendor name) provides
basic service level, but also consider opportunity for a
vendor convergence of commodity internet connectivity to include IPTV content. E.g., Verizon FiOS (not available here?) or something along the lines of ATT streaming video over an ATT I1 connection.

General strategy discussion:

Futures -- Define the level of service needed for CATV in the RHs. Perhaps legacy CATV is status quo, out of available channel space.

We should establish future requirements of CATV.

There are customers that we haven't considered yet -- we have CATV taps in
buildings for special interest programs which are currently carried over the
UP CATV system. These programs, such as the College of Communications
Weather, are high quality programs and would be valuable as streamed content
within PSU.

AN opportunity to listen, talk, sell, and explain network capabilities as well as provide some knowledge transfer towards how to stream PSU-produced video on the PSU IB.

------ End

Items discussed:

Core topology with redundant, private-IP machines, both of which are behind
the SBC. SIP service psu.edu points to the SBC (firewall).

A plan for a second SBC to provide failover in the event of a single
firewall failure.

Phase 1 is PSU IB-wide,
userID to userID and all users will expect service continuity
when compared to UP. Or do we strictly adhere to the written Phase 1
definition.

We are at the point where we need to re-create the voip.psu.edu server front end to
provide AAA of the SoftPhone user. The next steps of the process is to
generate a strong SIP password to be cut and pasted by the authenticated
user into their soft client.

Complete the 15 steps for a new service creation.

Review Asterisk clustering as an option for this or the second phase.

Future meetings:

Review timelines found on \NPI\SoftPhone Versions\Soft Phone Version Control
Document

Help desk involvement -- would we consider a wiki-based support function for
Phase 1.

SNMP logging and developing maintenance / support functionality

SBC configuration overview

SIP trunk for Phase 2 reviewed