Driftwood

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

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.

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.