SOA/Web Services

TMCnet - World's Largest Communications and Technology Community


August 14, 2006

The Telephone and the SOA

By Alan Rosenberg, BlueNote Networks

If you accept the assertion that telecommunications is succumbing to the service-oriented architecture movement, the logical question to ask is: “What happens to the telephone?”
On one level, the answer seems self-evident: the phone is an I/O device, and should be treated as such in the architecture in general. It is like a keyboard, or a mouse; it is just an audio I/O device.
However, at a deeper level, the answer is not so obvious. To access an enterprise’s applications, there is an assumption that a keyboard and mouse exist – there is an assumption the user has a computer! Last I checked (most) computers don’t come with telephones.
It turns out this problem is harder to solve than it seems. The current crop of phones assumes that the telecommunications complex is an island unto itself. Softphones are PC applications that leverage a headset to turn the computer into a phone that connects to the PBX. PBX vendors sell “hard phones” and there are adapters to turn an analog phone into an IP phone that once again connects to the PBX. Cell phone and PSTN phones suffer from the same malady.
Is this what we really want? Desk phones don’t travel very well (forget the lug-and-configure problems, think about international power conversion). Softphones move in the right direction but it’s hard or even impossible to integrate them into other applications. Portals and Web page integration is out of the question.
Most of us do have a phone where we work (most of the time) but it is not “connected” to the application environment--it’s connected to a dedicated network. You have your home PSTN phone, your office PBX phone, or your cell phone. Barring cell-service issues in some hard to cover areas, most nomadic users have access to a phone that accepts incoming calls. The trick now is to bridge the I/O device of choice with the SOA environment and make it act like “your phone.”
So why can’t we assume that the phone exists, just as other applications assume a keyboard, mouse and display exist? If we base the assumption on the assertion that the telecommunication system separates the bearer channel from the services channel, it turns out we can.
This is one place where the traditional PBX functionality suffers. To treat “your phone” as an I/O device for applications, the control plane and bearer plane need to be separated. That is, the technology used to carry the “voice bits” should be distinct and separate from the technology used to carry the “services bits.”
The problem can be illustrated with an example from the PSTN – your POTS phone. Caller ID information is carried over the same technology (not just the same physical infrastructure) as the information that represents your speech. Caller ID information is transmitted as “modem like tones” between the first and second ring-pulse. Caller ID is a service carried over POTS.
The promise of VoIP was the separation of the service (or control) channels from the bearer channels, and yet strangely vendors still mandate VoIP bearer technology match the IP service technology. While the separation is much simpler with VoIP than POTS, the connection between IP service applications and VoIP voice transmission seems persistent. Unfortunately, the insistence of this linkage is one of the reasons the PBX marketplace is so old fashioned. 
So, what is it that we want? I think that we want to leverage the enterprise SOA for the “services bits.” The IT application space is where enterprises use technology to increase customer reach and satisfaction, improve employee productivity, or reduce or eliminate business process burdens.
The IT application architecture of the “future” is Web services and the SOA (bold sweeping generalization – that’s OK). I think enterprises need a telecommunication system that bridges the “PBX/PSTN world” of tightly coupled control and bearer channels with an SOA service infrastructure that treats them as separate, but integrated, resources.
Now what the “phone” becomes is more obvious. The phone becomes an I/O device that interfaces with the bearer services, is linked to the control channel via the SOA service infrastructure, and this in turn ties the control channel to Web-service applications, which are reachable from the PC we assumed the user had access to in the first place.
Simple, no?
No? Ok, consider your cell phone. Your cell phone, most likely, is a full-duplex radio that eventually is bridged to the PSTN. This enables it to “act as a phone” for your purposes. Other telecommunication systems connecting to the PSTN can call (or be called by) your cell phone; addressing information is called “your phone number.”
Now, if the telecommunication system connecting to the PSTN was itself a bridge between the tightly coupled control and bearer channels of the PSTN (lets say ISDN D and B channels respectively), and this system split the control channel out into technology available to the enterprise SOA, and the bearer channel out to – well, any technology you want – you’d be able to couple the cell phone as an I/O device for a Web-service application running on the users PC, on the Web or reached via a portal.
If you accept the assertion that telecommunications is succumbing to the service-oriented architecture movement, the answer to the question “What happens to the telephone?” is that it becomes an I/O device for the Web-service applications. The telecommunication system that bridges the handset to the application domain is itself a reusable business asset in the SOA. The service that it provides includes the necessary technology to once and for all separate the mechanism we use for audio transmission from the technology we use to control that transmission.
Brian Silver is chief technology officer with BlueNote Networks, which is pioneering the collision of SIP-based interactive communications with service-oriented architectures (SOA) by delivering the first enterprise-class interactive communication platform: SessionSuite. He can be reached at

Technology Marketing Corporation

2 Trap Falls Road Suite 106, Shelton, CT 06484 USA
Ph: +1-203-852-6800, 800-243-6002

General comments:
Comments about this site:


© 2020 Technology Marketing Corporation. All rights reserved | Privacy Policy