|
Archives
 April 1999 Issue
Focus on Telephony
The Convergence of Switched and IP Telephony
The Future Is Closing In
By Justin J. Junkus
A few months ago, I observed that serious entrants into the telephony market need to deploy circuit-switched technology now to capture the market of feature-conscious consumers. Before Internet protocol (IP) telephony can flourish, the technology must evolve to close the feature gap, and those changes are coming.
A word of caution, though: These changes are on the engineers and developers desks now, but they wont be in the field for another three to five years. When they are ready for prime time, circuit-switched technology indeed will give way to an IP telephony alternative, but the cable industry cannot afford to wait for this to happen.
Its all about features
The market, rather than technology, drives the near-term implementation of cable telephony. Becoming a player in telecommunications requires an operator to have a feature-rich telephony solution today. In the longer term (three to five years), continuing to play in the telecommunications arena will require an operator to have a flexible, hardware-independent environment for feature creation and maintenance, as well as a full-featured service.
Todays IP telephony solutions cannot yet provide that environment. Circuit-switching is the only viable choice we now have to give our customers what they want.
By the first third of the next decade, however, products that have roots in the data industry will give IP telephony the capability of defining user features in a distributed, software-driven architecture. Such an architecture makes feature changes easy to implementessentially, just a few lines of new code in a server on a network change the feature for every subscriber served by the telephony provider.
Circuit-switched telephony systems based upon hardware-driven networks simply do not have the flexibility to rapidly change or deliver new features across an entire installed base of switches.
Directory assistance
A key element of this distributed, software-defined architecture is a directory database.
Directories keep track of network "objects," such as telephony features, access privileges, customer information or billing rates. They reside on one or multiple servers in a network. (Start thinking Internet here.)
The use of such a directory to support an application is called the directory service. Although each directory provides a specific service, certain information may be common between directories and services, such as the subscriber name.
You can gain a great degree of flexibility by allowing separate directories to share certain common entries. For example, imagine the phone, electric, gas and cable companies all having the most current name, address, phone number and home appliance inventory in the same fields of databases with a common format, which could be accessed by each utility.
Think of how easy it would be to add new services involving Internet control of multiple home appliances. Even if you just consider telephony applications, life would be easier for consumers if a centralized server could coordinate their cellular and land-line phone numbers across service providers for "find me" service and end-of-period billing. One call could provide address or other changes for multiple service providers.
This sharing between directories is called a "global directory service." Such flexibility would require cooperation between service providers, but it also would require a standard for directory structure that multiple vendors and service providers could accept. Well talk about standards later, but for the time being, lets assume that both issues can be solved.
Policy servers
Now, lets allow the global directory service to communicate with another database containing a set of rules that specify what privileges are associated with specific entries in the global directory. An example might be that Joe Cablesub is entitled to forward calls from his home to his business phone number between 8 a.m. and 5 p.m. each day. The computer containing this second database is called a "policy server." You may be starting to see the potential here.
Today, IP telephony provides a call routing mechanism that is an alternative to the public switched telephone network (PSTN). Routing is all it can provide
because features reside in a telecommunications switch. If the routing functionality of IP telephony could be combined with policy-based decisions coming from servers distributed on the Internet, IP telephony could provide the equivalent to switch features.
The big difference between using a policy-based network for feature delivery and using a conventional switch is that policy-based network decisions
are made at a computer (think computer in the Internet) that is independent of any telecommunications switch. Features can be added to subscribers Internet phones at the policy server by associating them with the phones Internet address. Furthermore, the features can be combined or changed at the centralized policy server, provided the changes are made by the authorized network manager.
Standards
To reach this ideal situation, we assumed that standards issues were solved. This is the biggest obstacle to implementation today. The data industry, particularly the part of it that serves large wide area networks (WANs), has been working on a standards solution to global directory services since 1988. The first attempt is X.500.
X.500 specifies how information in a directory is referenced and organized. It describes a "schema" for information that applies across different types of computer hardware and software, similar to a business form with boxes for specific entries.
It provides a way to secure information against unauthorized access, specifies the types of operations that may be performed on data in the directory, and defines how a directory service could be maintained across hundreds or thousands of servers.
The problem is that X.500 is too complicated. It requires too much code to run on many servers. Worse yet, it doesnt work well with transmission control protocol/IP (TCP/IP), which is the protocol for the Internet.
In an effort to remedy the problem, software developers created the lightweight directory access protocol (LDAP). As the name suggests, LDAP is a watered-down version of X.500. It began as a way for smaller computers to communicate with the large machines needed to hold the X.500 code, and it has evolved through three versions to a self-contained protocol for directory access.
For now, server vendors cannot agree on standard implementations of LDAP on their products. Because of the complexity of X.500, it is not acceptable for widespread use on communications directory servers, either. Several taskforces are attacking the problem, and eventually consensus or de facto implementation by a predominant vendor will solve it. When that happens, features and flexibility will become part of IP telephony.
For the time being, IP telephony is well-suited to application on the network side of a telecommunications switch. There, it can provide economical call completion over managed networks where quality of service (QoS) problems have been solved.
In the meantime, technical people in cable have some time to learn new technologies. If you arent data proficient, its not too soon to learn about networks, servers, databases and packets. For telephony and any other new service, these technologies are the future. CT
Justin Junkus is president of KnowledgeLink, a consulting and training firm specializing in the cable telecommunications industry. To discuss this topic further, or to find out more about KnowledgeLink, you may e-mail him at .
 Back to April Issue
Access Intelligence's CABLE GROUP
Communications Technology | CableFAX Daily | CableFAX's CableWORLD | CT's Pipeline
CableFAX Magazine | CableFAX databriefs | Broadband Leaders Retreat | CableFAX Leaders Retreat
|
