Introduction to Softswitch
Softswitch is the generic name for a new approach to telephony switching that has the potential to address all the shortcomings of traditional local-exchange switches identified above. This section explains the basic concept and describes the functional components of local-exchange softswitching.
The Local-Exchange Softswitch Concept
By far the most complex part of a local-exchange switch is the software that controls call processing. This software has to make call-routing decisions and implement the call processing logic for hundreds of custom calling features. Today’s local-exchange switches run this software on proprietary processors that are integrated tightly with the physical circuit-switching hardware itself.
The inability of existing local-exchange switches to deal directly with packet voice traffic, however, is a major barrier to packet voice migration. In the future, delivery of local telephony will come over a purely packet-based infrastructure. But for years to come, the migration path to end-to-end packet voice will require working with a hybrid network handling both packet and circuit voice.
One possible solution to this is to create a hybrid device that can switch voice in both packet and circuit formats, with all the necessary call processing software integrated into this switch. While this approach may help address the question of migration, it does not necessarily lower the cost of local-exchange switching or improve the prospect for differentiated local voice services.
The telecom industry appears to have reached broad consensus that the best answer lies in separating the call processing function from the physical switching function and connecting the two via a standard protocol. In softswitch terminology, the physical switching function is performed by a media gateway (MG), while the call processing logic resides in a media gateway controller (MGC).
There are a number of reasons why this separation of functionality is believed to be the best approach:
- It opens the way for smaller and more agile players who specialize in call processing software and in packet-switching hardware respectively to make an impact in an industry that has been dominated by large, vertically integrated vendors.
- It enables a common software solution for call processing to be applied in a number of different kinds of networks, including combinations of circuit-based networks and packet voice networks using multiple different packet voice formats and physical transports.
- It allows standardized commodity computing platforms, operating systems, and development environments to be leveraged, thereby bringing considerable economies to the development, implementation, and processing aspects of telephony software.
- It allows a centralized intelligence in a service provider’s voice network to remotely control switching devices located in customer premises, a key requirement for the full exploitation of IP telephony in the future.
- Separation between MG and MGC requires a standardized protocol for communication between the two, and an appropriate standard is now emerging. The next section will discuss the evolution of this protocol in more detail.
Protocols for Media Gateway Control
The softswitch concept has been around for several years, and a number of early implementations exist, some of which have had real operational exposure. So far, softswitch solutions have only been applied in core network switching functions, where the call processing functionality is largely limited to call setup and teardown, and where the complex features required for local telephony are not applicable. Nevertheless, early experience in this field has done much to shape the design of the protocol that MGCs will use to communicate with MGs.
Today’s softswitch solutions are mostly based on a protocol called media gateway control protocol (MGCP), which evolved from two earlier proposals called simple gateway control protocol (SGCP) and Internet protocol device control (IPDC). MGCP has been published as RFC2705, but its status is "informational" and it is not on the standards track.
Figure 2. Comparison between Local-Exchange Switch and Softswitch
MGCP is a very IP–centric protocol and does not have effective capabilities to handle other packet voice transports, such as voice over ATM. Operational experience with MGCP also identified some practical shortcomings, such as the lack of an effective method for an MGC to obtain information about the capabilities of an MG. As a result, MGCP itself has largely been abandoned, but work continues within the Internet Engineering Task Force (IETF) on a new protocol known as Megaco. The International Telecommunications Union (ITU) has assigned the identity H.248 to this new protocol and has adopted the text of Megaco from the IETF work. The two organizations are working together to finalize the Megaco specifications by the end of 2000.
Capabilities of Megaco
The Megaco protocol provides a comprehensive solution for the control of MGs. As with earlier generations of MG control, Megaco is based on the principle that all call processing intelligence resides in the MGC. The MG does not retain knowledge of call state; it provides only the capability to cross-connect various kinds of media streams under the control of the MGC and to detect and transmit various kinds of signaling associated with those media streams.
Megaco views the MG as a collection of terminations, each of which represents a certain kind of media stream. A termination may be a fixed physical entity such as an analog line or a digital signal level 0 (DS–0) time slot in a DS–1 interface, or it may be a logical entity such as a voice-over–IP (VoIP) packet stream. Logical terminations may be created and destroyed by means of Megaco commands.
Cross-connections within the MG are created by means of Megaco commands that request two or more terminations to be placed in the same context. If the media streams associated with terminations that are in the same context are of different types (for instance, one is a DS–0 time slot while the other is a VoIP packet stream) then the MG is expected to perform appropriate media conversion between them. To support this, terminations have various media stream properties associated with them such as the identity of the voice encoding that is to be used.
Terminations have other properties, such as a list of signaling events that they are expected to notify to the MGC and a list of signals that they are capable of transmitting on request from the MGC. For example, an analog line termination should be capable of notifying the MGC when it sees an off-hook or an on-hook event taking place; it should also be capable of applying ringing on the line when requested by the MGC. The events and signals that are associated with a specific type of termination are described in a package.
Megaco is designed to be an extensible protocol, and it includes a mechanism to permit the specification and registration of new packages. This extensibility overcomes a major shortcoming of earlier media gateway control protocols, such as MGCP, since it addresses the needs of packet voice protocols other than VoIP and provides the means to handle country-specific variations of analog telephony services.
Transport of Megaco
The Megaco protocol is designed to be transport independent, although the specification does include some appendices that describe the use of both transmission control protocol/IP (TCP/IP) and user datagram protocol/IP (UDP/IP) as transport options. Most softswitch implementations are likely to use an IP–based transport for Megaco, although there may be good reasons to use a native ATM–based transport, such as I.366.1 (segmentation and reassembly sublayer for AAL2), to support remote MGs that operate with VoATM connections.
0 komentar:
Posting Komentar