There are those that are going to embrace Voice-Data convergence, and those that are wasting time and money.
I’ve always thought along these lines, but my recent trip to see a large call centre in action reinforced it.
It’s difficult to gather my thoughts on this issue and explain, so start here:
Traditionally, the voice world has been dominated by big iron, running on leased lines, and making the network the intelligent part. Think of how dumb your phone is… You pick up the handset, the other end sends you a dialtone. You press buttons that make music, the other end decyphers it into a number. The other end figures out where to send the call. The other end rings the other person’s phone.
The old world is only good at building channels from person A to person B. Anything else.. Call waiting, voice mail, and call hold, is done on the PBX end.
Compare this to the Internet. Your web browser speaks HTTP. The web server speaks HTTP. You talk. The network doesn’t know what you’re doing, nor does (or should) it care. It’s just a packet.
Bring this into the voice world.
An organization needs flexibility and to be cost effective. TDM lines take weeks to be installed. PBX programming is complex. Getting into the SS7 integration is expensive and even more complex.
Data connections are built and rebuilt thousands of times a second. All you need are two endpoints, and it’s there. An organization that needs to connect two voice endpoints over its WAN just needs IP addresses.
Moving the PBX functionality to the network, and onto a piece of open hardware allows tighter integration of existing software into the system. Suddenly you have access to everything you need. You have the flexibility to easily monitor the system in real time. You can move agents between queues or change queues in a flash.
While I am rather PBX naive, I know that a lot of these things can still be done on big iron. But I know enough that the stupid network, the one that just flips packets, is a better bet than one that has all the smarts in the centre.