SIP 'n SOA: Are our phones ready?
When it comes to phones, we're all seeing new innovations coming into play, such as widespread adoption of IP-based telephony through Session Internet Protocol (SIP), or the ability to access the We
b and e-mail from cell phones. There's no doubt that telecom is quickly converging with SOA. Which led Brian Silver, chief technology officer for BlueNote Networks to ask a very simple but compelling question in this new article: “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."
Silver goes on to observe that we have softphones, "which are PC applications that leverage a headset to turn the computer into a phone that connects to the PBX." Hard phones come from PBX vendors, "and there are adapters to turn an analog phone into an IP phone that once again connects to the PBX." Ditto for cell phone and PSTN phones.
Silver argues that applications should recognize phones as I/O devices as easily as they recognize keyboards, mice, and interfaces. However, traditional PBX systems still tightly couple the technology used to carry the “voice bits” and the technology used to carry the “services bits.”
The telecommunication system that bridges the handset to the application domain "is itself a reusable business asset in the SOA," Silver writes. "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."
Ultimately, the “phone” as we know it will evolve to become "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."