Title of Invention: Universal protocol conversion Abstract: A scalable, programmable software based application run on a programmed general-purpose digital computer is used for interconnecting a plurality of heterogeneous network nodes. The application has the ability to convert between any two signaling protocols used, such as those used over a telecommunications network, by converting an originating protocol to a universal non-protocol specific representation, and then converting the universal non-protocol specific representation to a receiving protocol. A call context is used to store information elements created from the originating protocol so that a universal call model applies inter-working rules. The universal call model is also in communication with state machines associated with both the originating and the terminating sides in order to supply the appropriate response signals anticipated by the originating and terminating sides received when each is in communication with its own protocol. As such, the universal call model allows both the originating and terminating sides of a call to operate independently of each other by virtue of the fact that each side deal through the universal call model and not directly with the side for which the protocol message is being converted. Therefore, any protocol is easily converted to any other protocol by first translating the protocol message to the universal protocol non-specific format. Detailed Description: Part general_description_paragraphs: Part CROSS-REFERENCE TO RELATED APPLICATIONS; PRIORITY CLAIM: This application claims benefit under 35 U.S.C. §120 as a Continuation of application Ser. No. 09/375,844, filed Aug. 16, 1999 now U.S. Pat. No. 6,741,610, which is a Continuation of application Ser. No. 08/904,295, filed Jul. 31, 1997 now U.S. Pat. No. 6,111,893, the entire contents of which are hereby incorporated by reference as if fully set forth herein. Part FIELD OF THE INVENTION: The present invention relates in general to apparatus and methods for protocol conversion between telephony systems, such as advanced intelligent networks, having incompatible telephony signaling protocols. In particular, the present invention relates to a configurable, universal signaling protocol converter, a system or network having such a protocol converter and a method of protocol conversion that enables communication between signaling protocols of two or more pieces of telephony equipment. Part BACKGROUND OF THE INVENTION: In the past decade, the pace of deregulation of the telecommunications markets around the world has accelerated rapidly. Federal telecommunications liberalization legislation in the United States, the European Community's mandate that its member nations liberalize their telecommunications markets by January 1998, and the World Trade Commission's agreement on freeing trade in telecommunication's markets world wide have combined to result in a period of unprecedented growth in the global telecommunications market. New carriers are being created to compete against the old monopolies, established monopolies and carriers are merging and forming joint ventures to create global giants, and fringe market players (resellers and call back operators) are expanding their product lines and extending into new markets. As carriers build new networks and extend existing networks to new markets, they are encountering many technological challenges, which they did not face when they operated only in a single, domestic, market. One of the most significant challenges is that of managing the myriad of communications network protocols that are used in different markets. Telecom operators must interface with a variety of customer Private Branch eXchange (PBX) equipment, and must also interconnect with other operators for access and egress. Today, there are between 35 to 50 variants of base protocols. The ability of the new entrants to support customer access, local, long distance and international protocols often determines their ability to compete successfully. Communications protocols are the “languages” that allow telecommunication equipment (switches, routers, customer premise equipment, etc.) to communicate with each other. It is essential for a new carrier to be able to support the protocols of its customers, to provide access for their existing Customer Premises Equipment (CPE), and the other networks with which it must interconnect, via switch-to-switch interconnections. Moreover, the creation of more advanced services, such as Intelligent Networking, requires that communication's protocols contain increasingly detailed information and the migration towards ATM (Asynchronous Transfer Method) network backbones requires the capability to support voice network protocols through data networks. The technical solutions to this problem, that are available today, have not sufficiently met the requirements of the network operators. Traditionally, network service providers have supported protocols directly on the network switches. This was an adequate solution when the carriers operated only in a single market, but as they expand, their switches do not support the new protocols and the development time and cost for adding all required protocols to their switches are prohibitive. Voice protocol conversion solutions available in the past have been managed on a one-to-one basis which result in small, hardware based solutions. These solutions are inflexible, have limited scalability, are unstable, and do not operate as truly integrated parts of the carrier's network. One example of the problems with the prior art is in a connection between a protocol used by Deutsche Telekom AG and another protocol, such as G1. When a party using the protocol of Deutsche Telekom AG generated a call signal and the other protocol generated a busy signal, the Deutsche Telekom AG threw away the busy signal and continued to generate the ring signal to the calling party. Rather than change their protocol, Deutsche Telekom AG used a mechanical solution of monitoring the tone. Another example of a problem with conventional equipment arises when large multinational corporations use a first protocol, such as DPNSS, to provide a “call hold” between the company's PBX's using leased trunk lines. However, these trunks cannot be extended across national boundaries due to high expense, national regulations, and incompatible service providers. The telecom service provider used by the company determines that each country supports a similar, but not exact, Integrated Services Digital Network (ISDN) public facility signaling system. Both systems, for example, are compliant with ITU Q.931, but use two network-dependent fields in a different manner. The requirements for connectability then become: 1. Convert a DPNSS “call hold” message sequence to an ISDN message sequence for Country A; 2. Convert ISDN messages in Country A format to ISDN messages in country B format; and 3. Convert ISDN messages in Country B format to DPNSS for deliver to the remote PBX. Consequently, a convoluted, multi-conversion process must be implemented. Accordingly, there exists a need for a universal, simplified, but easily configurable protocol converter that can be used by many different protocol systems; that can be easily configured for new protocols and changes to existing protocols. This need has existed for a long time and has not been solved by the existing equipment. Part SUMMARY OF THE INVENTION: The present invention was developed to provide a solution to protocol conversion by providing customers with a flexible, any-to-any, protocol conversion platform which is integrated in the network as a network element. This product is unique in its market and provides telecommunications service providers with new capability to quickly, and in the field, adapt their networks to the needs of a new protocol, which facilitates their ability to launch new products and extend into new markets and to compete in the rapidly changing global market environment. Accordingly, the present invention provides an intelligent signaling protocol converter that, for example, can be used for multiple Common Channel (e.g. C7 or PRI) and Channel Associated Signaling (CAS) protocol conversions and that is designed to support voice to data protocol conversions in its next generation. The present invention is a true network element that is scalable, will operate in a fault environment, and provides interfaces to network management systems typically used in a telephone company central office environment. An advantage of the present invention is that it can be programmed by a customer through an interface that allows the user to build, map, alter and logically convert between multiple protocols. Thus, the present invention offers programmability, flexibility and a dynamic environment not currently provided by traditional protocol conversion alternatives. It eliminates the need for the traditional list of supported protocols commonly associated with switches and one-to-one protocol converters by providing a library of pre-defined protocols and it is relatively easy to add new protocols and protocol variations quickly. The present invention provides advantages in network applications where it can be used to cost effectively expand a network and deliver central office functionality such as digit manipulation, billing and intelligent network interfaces close to the end user at significantly less cost than PBXs used as network switches. As such, a protocol converter according to the present invention can be paired with any tandem switch as traffic grows and switching becomes desirable. This enables system operators to support all current and future protocols, regardless of switch capability while freeing the switch from CPU-intensive conversion routines. This also eliminates long and costly development typically necessary to accommodate protocols and feature inter-working. As a remote access node, the protocol converter would be transparent to the bearer channel thus enabling only one leg of compression all the way from the customer site to the network switch. The present invention has significant benefits for a carrier such as enabling rapid customer interconnection of any PBX and its associated access protocol, avoiding expensive and time consuming switch development to support new protocols, and facilitating the wider distribution of access nodes through cost effective and scalable implementations. The present invention maximizes the inter-working of supplementary features (e.g. a caller identification feature and a call forwarding feature), improves operational efficiency through remote access to real time date, provides continuous call state analysis, and permits rapid fault isolation. The invention facilitates the interconnection between networks, supporting network access and egress requirements, by sitting in-between the connecting switches to convert between the core network protocols used by each network. The software can be ported to equipment developed internally or by third party vendors to manage protocol conversion internal to existing or future network elements. The application software can be distributed among many platforms and storage media, or can reside on a single computer. Finally, the software's design utilizing the universal call model facilitates the capability to map from voice protocols to data protocols to allow operators to migrate voice and data networks onto a single ATM backbone. The present invention has significant benefits for a carrier such as enabling rapid customer interconnection of any PBX and its associated access protocol, avoiding expensive and time consuming switch development to support new protocols, and facilitating the wider distribution of access nodes through cost effective and scalable implementations. In addition, the present invention maximizes the inter-working of supplementary features (e.g. a caller identification feature and a call forwarding feature), improves operational efficiency through remote access to real time data, provides continuous call state analysis, and permits rapid fault isolation. Another advantage of the present invention is the elimination of decompression and recompression of the telephony signals at the access node thereby improving quality. In one aspect of the present invention, a programmed general purpose digital computer receives signaling messages and logically converts the signals based on protocol definitions and customer-specified parameters into a non-protocol specific form (e.g. a generic protocol) and then converts the generic protocol into the requisite protocol of the receiving network. In this way, only one protocol converter is needed to service the expected protocols of an international telephony system, and this same converter, because it is receiving all of the incoming traffic, is capable of being used to provide valuable network usage data to generate network statistics and reports such as answer seizure ratio, call attempts, percentage failures and average holding time. In one specific environment where there is a conversion from a CAS or PRI protocol to a C7 protocol, the present invention can concentrate the signaling channels with the attendant advantages of eliminating the requirements for signaling terminals and the resulting need for costly switch expansion. One specific embodiment of the present invention is directed to a universal protocol converter that converts the protocols of a first system to the protocols of a second system and that is comprised of an interface means for connecting with the first and with the second system; and a call instance for a call in which the call instance includes a means for converting the first protocol to a non-protocol specific representation, and then from this representation to the second protocol. This one embodiment can also include a generic state means for keeping track of the call by storing only data obtained from the non-protocol specific representations. It can also include a means for storing call context data of the generic protocol that is generated during the call, and it can include a means for manipulating the non-protocol specific representation when converting to the second protocol. Another embodiment of the present invention is a telecommunications network that includes bearer channels and data channels and has first and second telecommunications systems having first and second protocols, respectively. The network also includes a means for converting between said first and second protocols that comprises a means for grooming the data on the data channels for data that both comes from the first and second telecommunications systems; means for converting the data to a non-protocol specific representation; means for temporarily storing the converted data; means for inter-working said temporarily stored data in accordance with a set of stored rules that depend upon the first protocol; means for converting the inter-worked data to conform with said second protocol; and means for reintroducing said converted data to said data channels of said second telecommunications system. The present invention also includes a method by which a call control data stream of a request for bearer services is intercepted in transit between an originating communications node having a first protocol and a terminating communications node having a second protocol and is converted to a call control data stream of a terminating communications node. The method comprises intercepting the call control data stream that contains a plurality of information elements and transforming them into a non protocol specific form, storing the intercepted and transformed data elements; inter-working at least some of said stored data elements in accordance with predetermined rules; storing said inter-worked data elements; placing selected ones of said stored inter-worked data elements in the protocol of said terminating node; initiating an intermediate origination of a call control session; and using said data elements in the protocol of the termination node, by which such originally requested bearer services are obtained. Generally speaking, the present invention is a software based, scalable, programmable, means for interconnection of a plurality of heterogeneous network nodes—including, by way of example and not limitation, switching infrastructure, customer premises equipment, and intelligent network adjunct processors—to enable the resulting combination to communication and interoperate with each other in providing network services and features that would not otherwise be within the individual or collective capabilities of such heterogeneous network nodes. Other features and advantages of the invention will be set forth in, or apparent from, the following detailed description of preferred embodiments of the invention. Part DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS: With reference now to the figures, wherein like elements are represented by like numerals throughout the several views, the basic concept of the present invention will be described. An important aspect of the present invention is the translate between heterogeneous signaling systems to provide fast, accurate connections in a reliable telephony service. Referring to FIG. 1, there is depicted an example of a communications topology illustrating some of the applications of a Universal Protocol Converter 100, according to the present invention, to support several different communications needs. Universal Protocol Converter 100 is hereinafter sometimes abbreviated as “UPC” and is further identified in FIG. 1 by a “100” along with a lower case letter to distinguish between the same UPC component that is located in a different configuration. At the center of the figure is a communications Network 102 that includes a plurality of network infrastructure comprised of switches, transmission equipment, and customer premises equipment and which for this example uses a first protocol that is designed Protocol A. A first subscriber or user 104 is connected to a first UPC, designated UPC 100a, through a Network Node 106 that supports a second protocol that is designated Protocol B. A second Network 108, which includes a plurality of network infrastructure comprised of switches, transmission equipment, and customer premises equipment, supports a third protocol that is designated Protocol C. UPC 100a, as depicted, supports communication among any of its subtending elements (comprised of Network 108, Network Node 106, and Subscriber 104) and Network 102. When used in conjunction with a second UPC, denoted 100b, UPC 100a supports communication among any of its subtending elements through Network 102 with a second User 110 served by a Private Branch Exchange (hereinafter referred to as “PBX”) 112 to which it is connected and that supports a fourth protocol that is designated as Protocol D. When used in conjunction with another UPC 100c, to which they are interconnected by Network 102, UPC 100a and UPC 100b support communication among their subtending elements and a Subscriber 114, served by a PBX 116 to which it is connected and that supports a fifth protocol that is designated Protocol E. Intercommunication through Network 102 provides similar support for communications among subtending elements of itself, UPC 100a, UPC 100b, and UPC 100c with a Subscriber 118 that is connected to and served by a Network Node 120. Network Node 120 supports Protocol A and therefore no UPC is needed to communicate with Network 102 or other elements in the illustrated topology. In general, FIG. 1 illustrates multiple configurations in which the present invention facilitates communications among network elements that use different protocols. Referring now to FIG. 2, there is depicted a particular configuration of hardware 200 in accordance with the present invention, which is one implementation of many different configurations. Hardware 200 includes a Computer 201, which serves as the host for the application software in accordance with the present invention. Hardware 200 is comprised of a motherboard 202 on which a Central Processing Unit (“CPU”) 204 and a Random Access Memory (“RAM”) 206 are located, and which is equipped with a Hard Disk 208 and slots for interconnection with Input/Output (“I/O”) Cards 210 and 212. Such application software is resident on Hard Disk 208, and upon initialization of Computer 201 appropriate elements of the application software, along with configuration information and other data references used by the application software, are loaded into RAM 206. A Video Monitor 216, connected to a Video Card 214, and a keyboard 218, of Computer 201, permit operator interaction with the application software. Functionality with the present invention is achieved through interception of the control signaling messages and data associated with a telecommunications network, storage of such control signaling messages and data in an internal format, manipulation of such control signaling messages and data according to inter-working rules applicable to the specific protocols supported, and transmission of such resulting control signaling messages and data to the destination. In FIG. 2, the hardware 200 of the present invention also includes a conventional Multiplexor/Digital Cross Connect (“MUX”) 220 connected to computer 201 with digital circuits that include control channels 222 and 224. For simplification, only one bearer channel 226 and only one control channel 228 are depicted to connect MUX 220 to a network node or customer premises equipment 240, and only one bearer channel 230 and only one control channel 232 are depicted to connect MUX 220 to a Network Node or customer premises equipment 242, respectively. Those skilled in the art recognize that digital facilities used in communications networks general conform to an accredited standard and are comprised of a plurality of bearer channels and typically one control channel, all of which are Time Division Multiplexed onto a single physical circuit. The role of the MUX 220 then is to receive the incoming circuits from Network Elements 240 and 242 and groom off the control channels to be passed in an individual time slot of a digital circuit (for example either ANSI T1 or ETSI E1 standard form), to the I/O Cards 210 and 212 of the host computer 201. Such grooming is represented by control channel 222 as the carrier of information from control channel 228, and control channel 224 as the carrier of information for control channel 232. In the associated discussion regarding FIG. 5, that follows, an example involving multiple bearer channels and control channels is provided. An exemplary complement of hardware that will support the illustrated embodiment of the present invention would include: a Sun™ ULTRA SPARC™ computer, equipped with one (or more) 167 MHz (or higher) CPUs, 128 Megabytes (or more) of RAM, two 4 Gigabyte Hard Disks; two Newbridge Sprite™ I/O Cards, a Monitor and Keyboard; and one Newbridge Main Street™ Multiplexor. Referring to FIG. 3 wherein a schematic diagram of the architecture of the present invention is presented, the UPC 100 is comprised of four major software architectural elements—a Protocol Conversion Engine 300, a Management Interface 302, a Channel Manager 310 (and its associated I/O Channel Controllers 312), and an Execution Environment 320. The Management Interface 302 and the I/O Channel Controllers 312 communicate with external systems and interconnected Network Nodes and/or Customer Premises Equipment through an External Interface 340. The Protocol Conversion Engine 300 is a central part of the present invention, within which the actual inter-working of signaling messages occurs. The Execution Environment 320 functions as the Software Framework within which the Protocol Conversion Engine 300 operates. A Report Manager 322 provides for the communication of reports through the man-machine interface. A Data Manager 324 provides for management of the databases required for operation. A Configuration Manager 326 addresses the configuration needs of the Host Computer as well as the application software. An Alarm Manager 328 provides for the registration of and tracking and reporting alarm conditions generated by hardware and software. A Measurement Manager 330 provides for the capture of statistics concerning the operation of the system, in the context of the present invention, and calls processed. A Command Manager 332 supports the Management Interface 302 that permits interaction with the functionality of the applications software. A Log Manager 334 provides the services for logging of activities and messages within the applications software. A Dumper 336 is a multi-purpose utility that collects statistical information, information about call related data and other data about certain key hardware and software events and prepares them for processing by an operating system (e.g. Unix) and other external applications. The Channel Manager 310 is responsible for coordination of the communications between the Protocol Conversion Engine 300 and the individual I/O Channel Controllers 312 that provide communication with the interconnected Network Nodes, Customer Premises Equipment, and/or External Applications Systems. The Management Interface 302 provides the mechanism for operator interaction with the UPC 100 as would be required for configuration data entry or modification, alarm acknowledgment or response, and network element management functions traditionally associated with communications network elements. Depicted in FIG. 3 are three principal management interfaces, that include a Man Machine Language (“MML”) 304—an interactive interface generally conforming with the provisions of ITU Recommendation Z.300; a Common Management Interface Protocol (“CMIP”) 306—a protocol interface generally conforming with the provisions of ITU Recommendation X.720; and a Simple Network Management Protocol (“SNMP”) 308 a protocol generally conforming with the provisions of RFC-1157 of the Internet Engineering Task Force. Referring now to FIG. 4, a diagram of the Protocol Conversion Engine 300 is schematically depicted. Comprised of a Call Instance 402 and a plurality of Protocol Adapters 404, 406, and 408, Protocol Conversion Engine 300 interfaces with external equipment, and therefore with interconnected networks and network elements, through a conventional I/O (Input/Output) Subsystem 418. It should be noted that Protocol Adapter 406 is a special form of Protocol Adapter, and unlike Protocol Adapters 404 and 408, it supports the interconnection of external systems that may be involved in real time call control (such as Transaction Control Application Part—TCAP—communications with a C7 network Service Control Point—SCP) as well as those that may not be involved in real time call control (such as use of a proprietary protocol in communicating with a Fraud Control System). Protocol Adapters 404 and 408 are the mechanism by which calls are instantiated, and responsible for maintaining the environment in which the Call Instance 402 executes. External Systems Interface Protocol Adapter 406, operating in a manner similar to Protocol Adapters 404 and 408, provides a means for communicating to external systems and/or entities. In addition, Protocol Adapter 404 acts as the mechanism that provides an interface between the Originating Call Control (“OCC”) 410 and the I/O Subsystem 418 and similarly, Protocol Adapter 408 act as the mechanism that provides an interface between the Terminating Call Control (“TCC”) 412 and the I/O Subsystem 418. Call Instance 402 is comprised of three functional state machines—two Call Control State Machines, one designated for an originating call control OCC 410, one designated for a terminating call control TCC 412; and one designated as a Universal Call Model State Machine (“UCM”) 414. Call Control State Machines 410 and 412, working in conjunction with Protocol Adapters 404 and 408, respectively, convert signaling messages received from originating and terminating networks through I/O Subsystem 418 to non protocol-specific Internal Primitives. Internal Primitives are the events that are passed among a call control state machine (i.e. Originating Call Control 410 or Terminating Call Control 412), the Universal Call Model state machine 414, the originating or terminating protocol adapter 404 and 408, and the External Systems Interface Protocol Adapter 406, respectively. An event in this context is a stimulus delivered to or from a state machine that may dictate a particular action, an example of which is a signal sent in response to a timer expiring. Internal Primitives are defined depending on how the protocol control is implemented, and are vehicles for carrying signaling information data and/or signals. In the exemplary model depicted, Call Instance 402 is servicing a call that is originating from one network element operating with a first protocol and terminating on another network element operating with a different protocol. Using a process and information obtained as more fully described below with respect to FIGS. 7, 8A, and 8B, Protocol Adapters 404 and 408 respectively take the signaling messages coming from or going to the originating party and take the signaling messages coming from or going to the terminating party and parse and assemble the signaling messages. Call Instance 402 also includes a reserved portion of memory that is called Call Context 416. Call Context 416 is a collection of data elements that describe the contents of the messages passed through Protocol Conversion Engine 300. The description is in a physical representation-independent, protocol-independent form. For each active call, there is exactly one instance of Call Context 416. The data elements of Call Context 416 are accessible to both OCC 410 and TCC 412, as well as protocol independent UCM 414 for the duration of the call. Together with the current state of the call, Call Context 416 completely specifies the state of the call, so that both OCC 410 and TCC 412 have all information that is needed and such that they communicate with UCM 414, rather than directly with each other. State machines 410,412 and 414 are comprised of states, primitives, alternatives, decisions, saves, and procedures. In addition to addressing the states of a call, the present invention addresses signaling messages within a call, that are defined as data structures that contain information passed between two connection points. Although each base protocol uses a different way of specifying the structures of its messages, in all protocols a message is comprised of header information and a series of discrete information elements. In particular UCM 414 is comprised of states, primitives, alternatives, decisions, saves, and procedures that are invoked in response to Internal Primitives sent by OCC 410 and TCC 412 in such a way that a Call Instance 402 is processed in a protocol independent fashion. In this fashion, UCM 414 acts as an intermediary between OCC 410 and TCC 412 by utilizing its knowledge of all possible Internal Primitives it may get from OCC 410 and/or TCC 412, for which UCM 414 might have to send to the opposite side or to respond to the side of the call sending the Internal Primitive. Specifically, in the case of receiving an Internal Primitive from OCC 410, the UCM 414 determines the Internal Primitive that must be sent to TCC 412; and, where applicable, sent to OCC 410 as may be required in the case where OCC 410 needs to know the state of the call. Internal Primitives may contain state signals and Information Elements and, therefore, in fulfilling the role described, UCM 414 may perform manipulation of certain data elements within the Internal Primitives and such manipulation is accomplished via population of Call Context 416 and/or extraction from Call Context 416 of Information Elements. As one skilled in the art will recognize, there is not necessarily a one-to-one correspondence between the Information Elements and/or states of one protocol versus those of another and therefore, another function of UCM 414 is to recognize the need for and provide for the population of Call Context 416 with required default or other required values. It should be noted that, for purposes of clarity in description of the functionality, Call Control State Machines 410 and 412 and Protocol Adapters 404 and 408 have been provided with function labels “Originating” (including “OCC”) and “Terminating” (including “TCC”). The association of “Originating” or “Terminating” functionality with any element is only applicable for the duration of a single call. Protocol Adapter 404 and Call Control State Machine 410 may provide “Originating” functionality in one call, and “Terminating” functionality in another. Similarly, Protocol Adapter 408 and Call Control State Machine 412 may provide “Originating” functionality in one call, and “Terminating” functionality in another. Referring now to FIG. 5, wherein an exemplary depiction of the Protocol Conversion Engine 300 is presented, and within which five individual Call Instances 402a, 402b, 402c, 402d, and 402e are illustrated. Each Call Instance, created by the origination of a call from within the Interconnected Network Nodes and/or Customer Premises Equipment 502, is depicted as associated with one of five Protocol Adapters 510, 512, 514, 516, and 518, each of which supports a unique protocol or protocol family (comprised of a group of protocols which differ only by minor variance). In addition, an External Systems Interface Protocol Adapter 520 is shown supporting an External System 530 in conjunction with the requirements of Call Instance 402a. The exemplary depiction of this singular association is not a limitation of the present invention in which plurality of call instances may be associated with the External Systems Interface Protocol Adapter 520. Within this exemplary depiction Protocol Adapters 510, 512, 516, and 518 are shown as supporting multiple Call Instances 402a, 402b 402c, 402d, while Protocol Adapter 514 is shown as supporting only one Call Instance 402e. However, as it would be appreciated by those skilled in the art, the limitations depicted in FIG. 5 of a particular Protocol Adapter being connected to one or two Call Instances, are for the purpose only of display and are not a limitation that exists within the present invention that permits any Protocol Adapter to support one or many Call Instances. Referring now to FIG. 6 there is a schematic depiction of one possible network topology that would correspond to the example of multiple call instances as described in FIG. 5. In this exemplary topology, UPC 100, comprised of Protocol Conversion Engine 300 and I/O subsystem 418), is configured to support five different telecommunications protocols as required by five heterogeneous Network Nodes 602, 614, 624, 636, and 644, to which a plurality of subscribers 600, 610, 612, 620, 622, 630, 632, 634, 640, and 642 are connected, and one External System 690. Protocol Adapters, a plurality of which are shown in FIG. 6 and abbreviated “PA” at 510, 512, 514, 516, and 518, provide support for each of their particular protocols. External Systems Interface Protocol Adapter 520 provides support for the requirements of External System 690 and communicates with External System 690 through an I/O Card 660. More specifically, UPC 100 has been configured to support conversion between the protocols used by a Network Node 1 624 and a Network Node 4 644; a Network Node 2 614 and a Network Node 5 636; a Network Node 3 602 and Network Node 5 636. It should be noted that this is only one of many possible topologies, and it should not be inferred that there is any limitation in the mapping of one protocol to another. For example, a Subscriber 600 is served by Network Node 3 602 that uses a Channel Associated Signaling (“CAS”) protocol. A CAS Application Module 604 is connected to Network Node 3 602 and facilitates conversion between a conventional Channel Associated Signaling protocol and a conventional Common Channel Signaling protocol. CAS Application Module 604 functions by decoding the in-band tones and creating control messages that represent the tones and placing such control messages on a separate control channel. Similarly, control messages received on the separate control channel are converted to tones that are injected into the bearer channel. It should be noted that circuits using CAS may be either analog or digital, and therefore the “tones” would be either analog tones or the digital representation of such tones, according to the specific type of facility. Thus, the bearer channel output from 602 is split into a bearer channel (shown in dashed lines) and a control channel (shown in solid lines) as it leaves the CAS Application Module 604. While the bearer channel passes through the MUX 220, the control channel is groomed into an I/O Card 654 and then passes to a PA 514. From there the control channel passes to Call Instance 5 402e and thence to PA 518, to an I/O Card 658, and finally to Network Node 5 636 where it is directed to any of Subscribers 630, 632 or 634 according to the dialed digits. While for purposes of describing this example call, the traditional convention of moving from left to right on the diagram has been used, the present invention has no such limitations and is fully bi-directional. Therefore, any of Subscribers 630, 632 or 634 could have originated the call to Subscriber 600, in which cases the call processing would follow the previously described path, in reverse. It should be further noted that for purposes of clarity FIG. 6 depicts a plurality of additional separate I/O Cards 650, 652, and 656. Subject to the capabilities of the specific I/O Card used in an embodiment, there is no limitation or requirement in the present invention that there be a one-to-one relationship between the number of supported protocols, and the number of I/O cards. In fact, one of the functions provided by MUX 220 is to allow the aggregation of control channels from a number of circuits into time-slots of a single circuit. Thus, in the example of FIG. 6, it would be possible to substitute a single I/O Card one or more of I/O cards 650, 652, 654, 656, and 658, by simply using a different timeslot within the digital circuit that connects MUX 220 with the UPC 100. For reasons of redundancy most communications carriers would, however, use at least two I/O cards, and would balance the load between them. A limitation of the exemplary embodiment depicted in FIG. 6 is the fixed correlation between protocols for which inter-working conversion is supported. This fixed correlation is the consequence of the “pass through” in the MUX 220 of the Bearer Channels between Network Nodes. An alternative embodiment that would not be subject to such limitation may be created by replacing MUX 220 with a switching device under control of the UPC 100. One method for effecting such control would be through use of the External Systems Interface 660. A second alternative embodiment that would not be subject to such limitation may be created by replacing MUX 220 with a Dynamically Reconfigurable Digital Cross Connect system that is capable of having its mapping dynamically changed by remote control, and effecting such remote control, for example, through use of the External Systems Interface 660 of the UPC 100. To depict these alternative embodiments, MUX 220 would simply be replaced by a symbol or an object representing an appropriate, conventional switch; or, in the case of the other alternate embodiment, to show control line connections between External Systems 690 and a symbol or object representing the remote controllable digital cross connect that replaces the MUX 220. As those skilled in the art will recognize, the facilities carrying bearer channels in Non Facility Associated Signaling (“NFAS”) networks—such as ETSI C7 and ANSI SS7—are often separate from the facilities containing the control channels. In the previously described preferred embodiment and the two alternatives presented, the NFAS bearer channels would not necessarily have to pass through MUX 220; however, the NFAS signaling channels would, allowing the present invention to support NFAS protocols. Referring now to FIG. 7, a high level illustration of the present invention has been depicted using the Data Store and Process Flow conventions of the Yourdon-DeMarco Software Engineering methodology. For this reason the call-out numbers used in this diagram do not repeat previously assigned call-out numbers for items with the same name. Data stores, indicated by the dual horizontal black bars, are comprised of information that exists in a plurality of files stored within an appropriate medium or media—e.g. hard disk, or random access memory. In the present invention, the Channel Detail Data Store 702 (depicted within this figure in two places for purposes of clarity) is comprised of configuration information about the communications facilities that are connected through the Network Interface 700 to the present invention. Such configuration information includes the logical identification of channels from the interconnected Network Node or Customer Premises Equipment, and identification of time slots used in the physical facilities connecting MUX 220 and the UPC 100. **As was illustrated in FIGS. 2, 5 and 6 each originating bearer channel has a corresponding mate. This is because the exemplary embodiment of the present invention does not interrupt the flow of the bearer channel. In the previously mentioned alternate embodiments the mapping between originating and terminating bearer channels, and therefore the mapping of the required protocol conversion, is accomplished by Channel Detail Data Store 702 containing information that mapped groups of channels. The Protocol Definition Data Store 704 (depicted within this figure in two places for purposes of clarity) is comprised of information about the communications protocols to be supported by the specific embodiment of the present invention. Protocol Definition Data Store 704 is a library of information about the communications protocols, and includes Message Definitions (“MD”), State Machine Definitions (“SMD”), Call Context Population Rules (“CCPR”), and Call Context Extraction Rules (“CCER”). Message Definitions are the collection of information about messages including format, content, and coding as would be required for a software process to receive, analyze, and reconstruct messages, or a state machine to recognize and respond to signals. State Machine Definition are the collection of information that describe all possible states and the process flow of operation among such states that are required to instantiate and operate a state machine. Call Context Population Rules are the collection of rules relative to formatting and placing Information Elements in Call Context 416. Call Context Extraction Rules are the collection of rules relative to extracting Information Elements from Call Context 416. The UCM Definition Data Store 706 contains information necessary to instantiate logical instances of calls, including Call Context Definitions (i.e. the templates for creation of Call Context 708 data), State Machine Definitions for the Universal Call Model 716, and Inter-working Rules (“IWR”). Inter-working rules define specific logic that is used to process Internal Primitives flowing between Call Control State Machines 714 or 718 and the Universal Call Model State Machine 716. An advantage of the present invention is the requirement that the author of a rule or rules need only be knowledgeable of the relationship between a single communications protocol and the universal protocol represented in the Universal Call Model 716. The consequence of such advantage is that new protocols can be added individually, and at different times as required. Call Context Data Store 708 is unlike the other, permanent reference Data Stores depicted in this figure, as it represents a temporary Data Store. This temporary Data Store contains the information required by the various state machines in processing of a single instance of a call. The Call Context Data Store 708 only exists for the duration of the associated call instance. In the preferred embodiment of the present invention, Data Stores 702, 704, and 706 reside in an appropriate storage medium or media. In a preferred embodiment of the present invention, such information is copied to random access memory at time initialization so as to enable rapid use by the software. Unlike previous figures that specifically identify an “originating” and a “terminating” element, FIG. 7 recognizes the inherent bi-directional nature of communications control. Therefore, the protocol adapter processes, depicted within circles, are labeled as Protocol Adapter Receiving Message 712 and Protocol Adapter Sending Message 720, respectively. In the same manner, the processes comprising the Call Control State Machines 714 and 718, are labeled as Call Control Receiving Message and Call Control Sending Message, respectively. The process flow of the handling of a new call by the present invention is traced by starting at the Network Interface 700 which represents the point of interconnection with the present invention provided by the I/O Cards, as previously described. An incoming Protocol Specific Message (designated by the PM on the interconnecting arrow) is received at 700 and passed to the I/O Sub-system 710. Using Configuration Data (as denoted by the CD on interconnecting arrows) from the Channel Detail Data Store 702, the I/O Sub-system transforms the Protocol Specific Message into Protocol Data Units (denoted as “PDU” on the interconnecting arrows) that are sent to the Protocol Adapter Receiving Message 712. Using Configuration Data (CD) from Channel Detail Data Store 702 to identify the incoming protocol, the mate of the incoming channel, and the protocol of the outgoing channel, and Message Definition information (designated by the MD on the interconnecting arrows) from the Protocol Definition Data Store 704, the Receiving Protocol Adapter instantiates a new Call Instance. As depicted in 402 of FIG. 4, the new Call Instance is comprised of three state machines 714, 716, and 718 and a Call Context 708. At the time of this instantiation, Call Control Receiving Message 714 and Call Control Sending Message 718 are provided with State Machine Definitions, Call Context Population Rules, and Call Context Extraction Rules from the Protocol Definition Data Store 704. Protocol Adapter 712 then sends Internal Primitives (designated by the IP on the interconnecting arrows) to a newly instantiated Call Control Receiving Message 714 where, using the Call Context Population Rules, Control Receiving Message 714 formulates Information Elements (designated by IE on the interconnecting arrows) that are written to the associated Call Context 708. Call Control Receiving Message 714 also sends appropriate state signals contained within Internal Primitive (designated by IP on the interconnecting arrows) to UCM 716. UCM 716 makes use of the Inter-working Rules (designated by “IWR” on the interconnecting arrows), State Machine Definitions (designated by SMD on the interconnecting arrows), and Call Context Definitions (designated by CCD on the interconnecting arrows) received from UCM Definition Data Store 706 at the time of Call Instance instantiation, and Information Elements in Call Context 708 to manipulate existing and/or create new Information Elements and write them to Call Context 708. UCM 716 then signals (through and Internal Primitive) Call Control Sending Message 718 which, using Call Context Extraction Rules, extracts the Information Elements from Call Context 708 to formulate Internal Primitives for transmission to a Protocol Adapter Sending Message 720. Protocol Adapter Sending Message 720 then uses Configuration Data from the Channel Details Data Store 702 and the received Internal Primitive to send a Protocol Data Unit to the I/O Sub-system 710. I/O Sub-system 710 then sends a Protocol Message to Network Interface 700 associated with the mate of the incoming channel. The same logic is used to process messages between the Originating and Terminating network elements. In the preceding example an incoming message from the Originating Network Node was traced, and Call Control Receiving Message 714 corresponds to OCC 410 as referenced in FIG. 4, and Call Control Send Message 718 corresponds to TCC 412 as referenced in FIG. 4. Similarly, Receiving Protocol Adapter 712 corresponds to the Protocol Adapter associated with the Protocol being used by the Originating Network Node, and Protocol Adapter Sending Message 720 corresponds to the Protocol Adapter associated with the Protocol being used by the Terminating Network Node. For a response message from the Terminating Network Node, the process flow of the example remains valid; however, Call Control Receiving Message 714 corresponds to TCC 412 in FIG. 4, and Call Control Sending Message 718 corresponds to OCC 410 in FIG. 4. In addition, Protocol Adapter Receiving Message 712 corresponds to the Protocol Adapter associated with the Protocol being used by the Terminating Network Node, and Protocol Adapter Sending Message 720 corresponds to the Protocol Adapter associated with the Protocol being used by the Originating Network Node. With reference now to FIGS. 8A and 8B, a high level flow chart of the internal process flow of a part of the present invention illustrates the manner in which protocol specific signaling messages are received, converted into a generic internal UPC format, processed and manipulated as necessary in the circumstances and converted again to protocol specific signaling messages that are transmitted. The process depiction begins at a point that is designated Start 800 where a message is received at the UPC. A protocol specific signaling message is received from the event handler of the present invention, depicted at 802 in the process flow. The program logic then develops an internal call reference identifier 804 from data in the incoming signaling message and attempts to determine if this call reference already cassandra45@example.com. If at a decision point 808 the call is determined to exist, processing proceeds at 850 as described in conjunction with FIG. 8B. If at decision point 808 it is determined that the subject call is not found, this means that this is a new call that must be instantiated. The program logic then proceeds at 810 to inspect the incoming signaling message to ascertain the type of message and at 812 conducts a fundamental check of the message header. If an error is detected, an appropriate error message is generated and sent to the originating side of the call and control is returned to 802. If no error is detected, the originating bearer channel identification is cassandra45@example.com. Processing continues at 818 by deriving the originating signaling channel identifier, the terminating bearer channel identifier, and the terminating signaling channel identifier—and thus the terminating protocol adapter. It should be noted that a “channel identifier”, whether signaling or bearer and whether originating or terminating, may be associated with one channel or a plurality of associated channels. Subsequently at 820, the program logic asks the terminating protocol adapter to create a call reference and insert the new call reference into the internal call map. If the processing occurs normally to this point, a new call is cassandra45@example.com. Referring now to FIG. 8B, processing then continues with an incoming Internal Primitive, as described in conjunction with FIG. 7, containing a signaling message, arriving from the originating side of the call to be processed. The message is decoded through program logic 850 that, using the originating side protocol definition from Data Store 704 and cooperating with other internal program logic, decodes the message. Once the message is decoded at 850 using the Protocol Definitions as from the Data Store at 704, the message is inspected at 852 to determine whether or not the message is correctly formed, as cassandra45@example.com. If not, this means that the message received is an unknown or unintelligible message. As indicated by the off-page connector, processing then proceeds at 802, as depicted in FIG. 8A and in addition, an appropriate error message is generated and sent to the originating side of the call. If the message to be processed is fundamentally sound, a decision is made at 856 to ascertain that the message is acceptable in the state of current processing. If the message is not correct for the current processing state, it is rejected and at 850 an error message is constructed that indicates that the message received is an improper message for the current state. This message is then sent to the originating side of the call. In addition, as directed by the off-page connector, control is returned to 802 and
{'bibliographic_information': "{'country': 'US', 'doc-number': '10844880', 'kind': 'B1', 'date': '20040512', 'disclaimer_text': 'This patent is subject to a terminal disclaimer.', 'invention_title': 'Universal protocol conversion'}", 'source_file': './grant/2005/ipg051122.xml', 'source_data': 'USPTO-Grant'}