Conversely, developers can also tap into data-centric application services through the same kind of abstraction model, using the same type of tools. For example, a voice-centric application that also ties into e-mail servers or business-process servers through Web services (assuming those systems have the appropriate interfaces) could bring that data into the resulting CTI application through a common interface. Trying to do this with SIP, or some other voice-specific interface, means embedding agents into ap-plications in order to effectively integrate the apps into the voice network.
Another point of consideration: There is no SIP-to-SOAP binding defined in standard form. Although there have been multiple stabs at this, none of these efforts has resulted in a standardized binding, so you'll be on your own if you want to operate at that layer.
Theoretically, wrapping traditional communications services into well-defined XML messages, which are transferred across SOAP, will allow organization to bring telephony and messaging services directly to their applications. Better still, Web services also have the potential to provide an abstract interface into the telephony service, regardless of the underlying telephony protocols; Web services can provide interfaces to devices on SIP and H.323 networks, and even PSTN networks. And, applications must become peer devices of those networks only if the application needs to be voice-enabled.
On the surface, Web services interfaces to traditional telephony systems don't appear all that different from existing interfaces. All provide a collection of functions that computer-based applications can tap into; the only real visible difference is in the transport mechanisms. For example, platform-specific interfaces usually rely on local transports, such as plain old RS-232 serial connections, while network-oriented interfaces use network protocols to extend the interface across a data network. From a cursory examination, the same appears to be true for SOTA interfaces.
However, the real difference with SOTA interfaces is additional layering. Whereas traditional interfaces merely extend the telephony API outward but still require data-oriented applications to conform to that interface, SOTA interfaces provide an abstract service-control layer that is separate from the telephony layer. Moreover, the applica-tion interface looks and feels like any other application-oriented interface, and does not require connected applications to become telephony devices. Executing a telephony task is the same as any other kind of task—you can initiate a phone call just as easily as you can issue a database lookup, or anything else that is available through a parallel Web service, and you can do so without having to become a peer device on the telephony network.
In the SOTA model, a simple WSDL interface exposes a variety of telephony and communication functions to the application plane, thereby allowing applications to make use of whatever communication services are needed. Meanwhile, back-end systems do whatever is needed to make the task succeed, whether that be placing a call through an available telecommunications interface or communicating with an IVR system through a serial line. In other words, the SOTA model provides an abstract interface for applications to use that is entirely separate from the telephony and communications infrastructure; this is a significant difference from traditional interfaces that simply extend the telephony infrastructure outward without any separa-tion.
Bob Friday, Chief AI Officer for Juniper Networks, explains how the advanced technology is transforming operations.
Contact center leaders from 8x8, Awaken Intelligence, and 360insight discuss the importance of agent experience.
AI may force enterprises to rewire parts of their data centers so they are fully optimized to run such workloads. The question is do you use Ethernet or InfiniBand?
