Hi,

about the first comment, perhaps the customer has forgot to consider that you need to pick-up the receiver in order to do 'live keypad'. This way a cisco phone will NOT need to press dial softkey.

Of course if doing a speakerphone call, either press speaker button bfore dial, or press dial after composing the number.

Wrt to the comment about the 'legacy' being 'better' and doing 'more things', what I've found instread that features available on legacy PBX are either, poorly documented, complicated to program, rarely used.

If you are uncomfortable with MAC addresses, routing issues, and whatever else, it's exactly because in the past 20 years you are not been exposed to these. - IP telephony it's really not a big deal having just a little IP background.

All in all, I see the IPT not only has filled the gap wih legacy, but it's leading by ages now.

Go and implement something like voicemail, automatic call distribution, conferencing with legacy sysems now. Report on the amount of money and time spent. You will see there is no justifications in using legacy anymore.

In respone to the last comment I have been working with IP for 15 years, cisco and microsoft accreditations.

I have worked with and installed CCM Unity and IPCC since around 1999.

Ths is for a number of large multi nationals and Gold Partners.

I would still say that, at the moment, legacy still has the edge in terms of funcionality and most certainley reliability.

I agree with your comments, how you dial a call really doesnt seem that important.

To qoute one example of where funcionality is lost their is a thread currently on this forum regarding selecting PRI channels to dial out on to test them, so far no one seems to think this can be done with CCM however with a PBX this would be a very simple test to do from a handset using a trunk select short code.

I similarly , at the moment, am running a Nortel Meridian / CCM 4.1.3 Hybrid with about 4000 handsets.

Every time we have a power down the IPT is a nightmare to bring back up, the Nortel doesnt even need to be looked at, it just works !

Hey Andy,

Beleive me, I understand your comments completely :) I have also been working in the Telecom field since 1977 and with Nortel products for 25 years. This transition to IPT has been very very hard for me to say the least! But, most of these transitional problems I have to take responsability for due to my lack of understanding of the parts and peices that go into setting up and maintaining a "stable" IPT rollout. With learning comes understanding, and the realization that these "new to me" technologies require a great team with special skill sets. I have also come to understand that comparing these systems is not really comparing "apples to apples" anymore. I have learned to live with the growing pains associated with this transition.

Just for fun compare the time required for the DST change on the two systems.

Nortel 10 minutes last Spring

CCM - I hate to even think :( Still ongoing.

Again, just my two cents my friend.

Rob

Indeed from what is seen here it becomes legitimate to think that DST issues in CM are developed under the auspices of the proponents for it's abolition :)

Seriously, what is clearly happening with the CM (but CME in a part too) is that someway they lack:

1- overall responsibility of a primary customer issue by dedicated management with the needed resources to systematically locate and fix bugs to a bring software to 'very good' and consistent quality level - that is NOT the case now.

2- overall vision of all the interdependencies in the system (admittedly there are many), and coordinated coding action.

Andy,

wrt the channel selection for test, I have to say, during all my years with cisco and outside, no problem on PRI has been properly diagnosed by selectively testing channels or bring them out of service. That's perhaps it's the reason no such facility exist.

Beside, I'm not even sure how you can properly test just using a steering code from handset, without looking into a trace at the same time. Suppose the calls fails, how do you know that the select B-chan wasn't simply busy at the time ?

I do agree however that the overall architecture of CCM is extremely complex and prone to failure especially when you have so many handsets to resemble a small town already. I'm positive that huge improvements should be made by Cisco in that area and the overall software quality issue.

But still I do prefer to use a product in which 99% of the issues are immediately visible to everyone rather dealing with legacy, where the documenting approach is exactly the opposite.

Nicely exposed by Rob, I've rated his valuable contribution that brings real and sensible experience, in the picture.

It is also matter of education to customers. Often they won't spend any time in reading and understanding the documentation provided, so it's up to you to get them by the hand and show how to use profitably the 'new world' telephony.

I've learn that supporting telephony requires much more patience and human skills than regular networking. Nevertheless I'm delighted by the chance and try to get the most by each customer input. In many occasion I've got new ideas, problems to look at, and even solutions by talking with customers.

I would continue, but I have to go back at the job of proper tuning a multi-group call-center, with differentiated answer hours, caller queue system, multiple trunks in and out, that makes use of both CME AA and CUE.

Try doing this admin for a legacy system, from home.

My 2 cents worth. Been involved with Telephony since 77. Project manager for installation of first 2bESS ever installed outside the "Bell System". That 25,000 line install went a lot more smoothly than my 1000 line CCM project.

My old digital key system ran 10-years before hard drive failures took their toll and I had to move to something else. In the 10-years not one patch/hack/software change was required. Not one network change affected the "phone system".

In the first 3 months of operation of the CCM over 60 patches were applied and I am still applying monthly pathces and chasing "bugs".

The CCM is showing progress but there are

still many items that it can't do, or that require too many steps to accomplish that were simple in the PBX world.

As to remote maintenance, I have access to all of my "legacy" equipment and don't need to be on site to perform most programming jobs.

The legacy systems also don't croak if someone modifies the routing tables on the gateways, or performs an IOS upgrade in the switches or heaven forbid plugs a "router" on the network with DHCP turned on or with a looped up connection.

I like VoIP, but prefer the simplicity of the legacy systems.