PDF of this tutorialTrue convergence is more than the mere ability to transport voice and data on the same physical wire. True convergence entails the convergence of tools as well—doing the same things we do in the data world with voice and vice versa. To give an example, in real life one might use Microsoft Outlook to read e-mail, and an interactive voice response (IVR) to listen to voice mail. Why should one not be able to use Outlook to check voice mail and/or use the IVR to check e-mail? In the next-generation network, one will be able to do this and much more.
In fact, one of the brightest hopes of the next-generation network is the ability to unlock the power of service creation and place it in the hands of service providers and ultimately their customers. No longer will service providers be dependent upon monolithic time division multiplexing (TDM) equipment vendors to create services for them.
Under the old regime, service creation was not only slow but also limited by the user interface—memorizing arcane series of codes on the telephone keypad greatly inhibited the usage and adoption of value-added features. Of the thousands of CLASS features, only 30 or so generate any revenue.
The next-generation network also has the opportunity to revolutionize the interaction between end users and their telecommunications needs. End users will be empowered to self-provision features and services via Web, personal digital assistants (PDAs), and other wireless interfaces. They will be able to specify the selection and usage of features with unprecedented flexibility. As examples, users can create priority ring lists, set up onetime conference calls, be charged for individual usage, and set dependencies on the usage of certain features (time-based call forwarding, etc.).
Striving to fulfill the above-mentioned promises of next-generation telephony brings up a number of architectural issues for telecom software vendors. For one thing, the question of whether applications run directly on the softswitch or on application/feature servers with an SIP connection between the softswitch and the application server must be decided. This distinction can have implications for feature interaction, scalability, and also reliability (because SIP as a protocol is only a signaling service and does not have responsibility for reliability).
Another challenge in implementing services is that they must be implemented across all protocols uniformly, consistently, and reliably. Call waiting must work the same in SIP as it does in H.323 as it does in MGCP, and it must interact with other features, i.e., caller I.D., in the same way across all protocols, and it must work well across all protocols. Clearly, this is a daunting task and is the reason why many softswitch vendors have shied away from offering local-exchange features (Class 5 in the United States) with their platforms.
Lastly, unless the softswitch vendor has a proprietary service creation environment (SCE), the vendor must provide open APIs based in widely implemented standards such as JAIN, C++, and Parlay to be able to run third-party applications and/or empower service creation with third-party SCEs. Even with a proprietary SCE, chances are a vendor will still have to publish open application programming interfaces (APIs) to create services with that SCE because most service providers will not want to be locked in by any one vendor. Service providers will, however, expect service creation to occur independently of proprietary software.
