METHOD AND APPARATUS FOR NETWORK TELEPHONY AND
MESSAGING
REFERENCE TO RELATED APPLICATION
This application claims the benefit of U.S. Provisional Application No. 60/194,978.
FIELD OF THE INVENTION
This invention relates to the field of networks and, more specifically, to telephony and messaging systems used in networks.
BACKGROUND
General purpose-computers are computers that are designed to operate on various different functions. General-purpose computers are popular with telecommunication solutions providers (TSPs) because general-purpose computers may simultaneously handle multiple users. Compared with prior telecommunication (Telco) standard hardware used by TSPs, general-purpose computers may offer a cheaper and quicker solution for a variety of business telecommunication and messaging applications.
One problem with using general-purpose computers in Telco systems, however, is that general-purpose computers are not necessarily built to handle telecommunication applications and, therefore, may require extra hardware in order to operate on telephone calls. That extra hardware, in turn, may require extra software. In addition, the complexity of general-purpose computer hardware and software for telecommunication systems may increase as different higher-level languages are used to accomplish an interface that is user friendly.
Figure 1 illustrates a prior telecommunications platform for telephony and messaging applications. The telecommunications platform utilizes a general-purpose computer platform; a suitable operating system; Telco hardware; networking hardware; a low level application programming interface (API) that defines an interface to the hardware, and a higher level programming language interface to an application. A general-purpose computer equipped
with Telco and network interface cards may be used with a low level API to write an application that performs a specific fixed function. On top of that application, a JAVA API may then be written to act as the interface for the user.
One problem with such a platfor.n, however, is that the API will only be as powerful as the low level API provided by the Telco hardware. Another problem is that the integration of such a platform, and cost differentials of the platform components, may be significant, thereby decreasing the desirability of such telecommunications system.
In addition, the complexity of such a platform may increase if networkability is required. Given the complexity and possible unreliability of general-purpose computers, it may be more difficult to provide Telco standard communication hardware and software to support certain applications. For example, designing a software layer that can handle complex telephony and messaging applications may be very time consuming. Also, the complexities of an operating system (OS), which may be out of the developer's control, may arise as newer OS versions impose more requirements.
Another area where the use of such a platform may add complexity is scalability. Expansion within a general-purpose computer may be very limited given the small number of expansion slots in a general-purpose computer. Another limitation of using existing general-purpose computers in telecommunication systems may be their high power and space requirements. Telecommunication and messaging systems, which may be used by millions of people every day, need to provide high volume applications that require scalability to be effective. For example, hundreds of general-purpose computers may be required to handle a small number of messaging or telecommunication users. However, a large number of general-purpose computers may not only be inefficient, power and space- wise, but may also be very expensive to maintain given the rate of failure of components that go into existing general-purpose computers.
Yet another problem with prior telecommunications systems may be their inability to provide businesses with a platform that does not burden them with
technology implementation issues. Many businesses are not able to outsource the development of their telecommunication and messaging applications. These businesses buy or lease Telco equipment and then put in the engineering effort into developing an application that suits their business needs. Ac ieving this goal may require much time and effort and may not outweigh the risk that the application may not be as good as the latest technology. Moreover, such a solution may not be configurable or customizable over a network.
Networks may contain a collection of clients that are interconnected by transmission lines to enable the transfer of data between them. Data is typically transmitted in the form of packets that are made up of smaller data cells. Packets include an address field that specifies the destination for which the data is intended. A network typically includes multiple access points (e.g., servers) that may switch and /or route packets between transmission lines to regulate data traffic between clients on the network. A network that is based on packet switching uses a network layer that defines an official packet format and protocol called IP (Internet Protocol). This type of network is referred to as an IP network.
One type of data that may be transferred on an IP network is voice data. A server on the network may have a controller and a switch that facilitate the movement of voice data passed through the server. When data arrives on an incoming transmission line, the switch must choose an outgoing line on which to forward the data based on its packet address field. Servers may also be used to connect different types of networks together. At one time, voice data was exclusively carried on a Traditional Plain-Old Telephone System (POTS), or Public Switched Telephone Network (PSTN), using a copper wire transmission line that connected multiple clients through the POTS to a central office.
Later, other types of networks were developed using higher bandwidth transmission lines that enabled greater amounts of data to be transmitted over a given time. For example, some companies use a private branch exchange network (PBX) having higher bandwidth transmission lines such as Tl/El,
T3/E3, or fiber physical interfaces. A PBX uses service modules at network
access points to facilitate the transmission of data, such a voice, over the network.
However, prior telecommunications systems using general-purpose comput rs and Telco standard hardware may not be able to efficiently combine POTS based telephony and IP based telephony due to the technical and financial problems discussed above. SUMMARY OF THE INVENTION
The present invention pertains to a system for network telephony and messaging. In one embodiment, the system may include a control switch coupled to multiple transmission lines. The control switch may receive and transmit data from the transmission lines. The system may also include a bus coupled to the control switch, a control server, and service servers. The control server controls the movement of data among the service servers.
Additional features and advantages of the present invention will be apparent from the accompanying drawings and from the detailed description that follows.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which:
Figure 1 illustrates a prior telecommunications platform.
Figure 2 illustrates one embodiment of an embedded system.
Figure 3 illustrates one embodiment of a control switch of an embedded system.
Figure 4 illustrates one embodiment of a network having an embedded system. DETAILED DESCRIPTION
In the following description, numerous specific details are set forth such as examples of specific components, devices, methods, etc. in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that these specific details need not be employed to
practice the present invention. In other instances, well-known materials or methods have not been described in detail in order to avoid unnecessarily obscuring the present invention.
The method and apparatus described herein provides an embedded system for network telephony and messaging. The embedded system employs dedicated functions that may be incorporated onto a control switch. The control switch may be coupled to servers as part of a larger system to operate with various applications. The embedded system may include a control server having one or more software modules and associated hardware to operate on telephony applications. In one embodiment, the embedded system may provide a dedicated resource to operate on voice data and the ability to route and /or switch voice data from a PSTN to an IP network and an IP network to a PSTN.
Figure 2 illustrates one embodiment of an embedded system. In one embodiment, embedded system 205 includes control server 220, control switch 210, and one or more service servers 225. Control server 220 may be configured to run multiple servers and clients coupled to control server 220 in order to combine access to different services into one interface.
Control switch 210 may be configured to transmit and receive data on various types of transmission lines, for examples, POTS 211, TI 213, El 212, and wireless 214. Control switch 210 may be coupled, via bus 227, to one or more service servers 225 that operate on the data. For example, control switch 210 may be coupled to control server 220 having a module manager and service servers 225 that include database server 250, messaging server 230, and billing server 240. In an alternative embodiment, control switch 210 may be coupled to other types of servers.
In one embodiment, control server 220 is configured to run on a LINUX operating system. In an alternative embodiment, control server 220 may be configured to run on another operating system, for example, UNIX. The control server 220 provides a central point for all the hardware of the embedded system to log in and be configured.
Control server 220 may also provide a fast and secure way of communicating to database server 250 and modules on other servers such as a messaging server 230 discussed below. The control server 220, along with module managers such as voice mail (VM) and Structured Query Language (SQL), provides a way to route the requests and respond back and forth between the modules. SQL is an international standard language for defining and accessing relational databases. SQL is well-known in the art; accordingly, a detailed discussion is not provided herein.
Messaging server 230 provides a set of API calls that are routed through control server 220. The control server 220 or its API can request various messaging related activities. This close relationship between control server 220 and messaging server 230 ensures that messaging can be integrated through both the PSTN and IP network interfaces through the same API that clients will use to control telephony features.
Messaging server 230 may be coupled to a mail server 260, such as a voice mail (VM) server and an e-mail server, to enable a client's browser to access messages. A voice mail server enables users to check their messages by calling into VM server in a manner similar to that of using an answering machine. The email server enables users to use their existing e-mail client, such as Microsoft Outlook™, or a web based e-mail service to check their mail. Mail server 260 uses a delivery protocol to communicate with the client, for examples, Post Office Protocol (POP), Interactive Mail Access Protocol (IMAP), and Distributed Mail System Protocol (DSMP). These protocols are well known in the art; accordingly, a detailed discussion is not provided herein.
In one embodiment, control server 220 is coupled to database server 250. The database server 250 may be used to provide a secure and reliable way to store and organize all information regarding the embedded system and its clients. Information may be organized in a manner that enables multiple customers to share the setup, maintaining their account integrity and customer information.
The software of control server 220 includes an API 221 that is a programmers interface to the different services. In one embodiment, the software may be a standard based JAVA API. Control server 220 may be coupled to a web server that handles all requests by a remote web browser 291. As such, the telephony and messaging solution can either exist in house for total control or can be out-sourced for rapid deployment with existing telephony and messaging centers utilizing the embedded system. The embedded system may also be based on a distributed telephony model and use an industry standard database and network protocols. On top of the database and network protocols resides a versatile JAVA API that allows a user to access multiple features of the switch with greater ease.
In one embodiment, the non-call related activities are carried out outside the embedded system. Thus, the system may be optimized to handle calls to its capacity. Further, if the embedded system only knows about itself, then the embedded system only needs access to its own data. This may simplify the search and handling of calls. In one embodiment, the embedded system may not store any information on control switch 210 except for the necessary basic networking and system level information. Upon boot up, control switch 210 looks for control server 220 and retrieves its system information. This type of architecture takes the bottleneck out of the hardware and, thus, may make it easier to scale up or down using the embedded system as a building block.
Figure 3 illustrates one embodiment of a control switch of an embedded system. In one embodiment, control switch 310 may include processor 320, one or more digital signal processors (DSP) 330, DSP controller 340, non-volatile memory (e.g., ROM or flash memory) 350, and transmission switch 360 to switch between different transmission mediums. Transmission switch 360 may be coupled to one or more Analog RJ-11 POTS lines 370 and one or more Digital Lines (e.g., El, TI, Jl) 380. In one embodiment, for example, control switch 310 may be coupled to 16 analog lines and/or 30 digital lines.
The operation of transmission switch 360 may be based on a time-division multiplexing (TDM) scheme. TDM is a scheme in which numerous signals are
combined for transmission on a single communications line or channel. Each signal is segmented in short duration. The TDM accepts data input from each individual line, segments the data, and then assigns the segments to a composite signal in a rotating, repeating sequence. The composite signal, thus, contains data from all the users. The data is then de-multiplexed and routed to DSPs 330 coupled to transmission switch 360. TDM is well-known in the art; accordingly, a detailed discussion is not provided herein. A TDM switch is available from industry manufactures such as Mitel, of Kanata, Ontario and Siemens of Munich, Germany. In an alternative embodiment, other transmission mediums (e.g., wireless) and other switch schemes (e.g., frequency division multiplexing) may be used.
DSPs 330 perform dedicated processing functions to handle multiple voice data, or calls, that are received from transmission switch 360. The dedicated processing functions include voice data compression. The DSPs 330 may also utilize various industry standard COders/DECoders (CODECs) and dual-tone multi-frequency DTMF detection and generation. CODECs are hardware or software that converts analog sound, speech, and /or video to digital code (analog to digital) and vice versa (digital to analog). DTMF is a type of audio signal that is generated by pressing the buttons of a touch-tone telephone. In one embodiment, DSPs 330 are TMS320VC549 DSPs available from Texas Instruments of Texas. In an alternative embodiment, other DSPs from other industry manufactures (e.g., Siemens) may be used.
The output of DSPs 330 may be stored in a shared memory for transmission to processor 320 under the control of DSP controller 340. The shared memory 350 is coupled to processor 320 that operates on the data transmitted between a control server and DSPs. In one embodiment, processor 320 may be a Motorola 860 processor. In an alternative embodiment, other processors may be used. A mass storage device (e.g., a hard disk drive 390) may also be used to provide the ability to store prompts on control switch 310 for faster data access.
The processor 320 of control switch 310 may be coupled to one or more servers and may be configured to operate with a different transmission mediums and corresponding interfaces. Control switch 310 communicates with a control server using a transmission interface device, for example, Ethernet device 325. When used with Ethernet, the transmission medium is referred to as 10BASE-T. 10BASE-T supports Ethernet's 10 megabits per second (Mbps) transmission speed.
In addition to 10BASE-T, Ethernet may be implemented with other medium types, for examples, 10BASE-2 (thinwire coaxial cable with a maximum segment length of 185 meters), 10BASE-F (fiber optic cable), and 100BASE-T. These designations are Institute of Electrical and Electronics Engineers (IEEE) shorthand identifiers. The "10" or the "100" in the medium type refers to the transmission speed of the medium in Mbps. The "BASE" refers to baseband signaling, which means that only Ethernet signals are carried on the medium. The "T" refers to twisted pair lines and the "F" refers to fiber optic cable. The "2" refers to the coaxial cable segment length in hundreds of meters.
In an alternative embodiment, the embedded system may be coupled to other transmission mediums using other interfaces. For example, the embedded system may be coupled to a local loop using a Central Office (CO), or Public Exchange, interface to handle various combinations of calling and messaging applications. A local loop is a wired connection from a telephone company's central office in a locality to its customer's telephones. The transmission medium may be a twisted-pair line that carries voice data using analog transmission technology on a single voice channel. In another embodiment, the transmission medium may also carry digital signals, for examples, Integrated Services Digital Network (ISDN) or Digital Subscriber Line (DSL).
Figure 4 illustrates one embodiment of a network having an embedded system. The dark shade boxes 401 represent hardware components, the light shade boxes 403 represent software components, and the hatched boxes represent external components 402. The embedded system includes control server 420, control switch 430, one or more service servers 425, and external
clients having external components 402. Control server 420 is configured to run multiple service servers 425 coupled to the control server 420 in order to combine different services into one interface. In one embodiment, control switch 410 may run on an industry standard real-time operating system (RTOS) called pSOSystem™ by Integrated Systems Inc. (ISI) of Sunnyvale, CA. The pSOSystem™ may provide greater stability and efficiency that may be required from a Telco grade platform.
In one embodiment, control server 420 includes a software router 422 that handles ail the low level network, direct, and inter process communication used by local interface modules and remote and local servers and services. Control server 420 also includes an API 421 that is a programmers interface to the different services. API 421 may communicate through control server 420 either locally or remotely. In one embodiment, API 421 is JAVA based. In alternative embodiments, API 421 may support other languages, for examples, Perl, PHP, and C++. Control server 420 may be coupled to a web server 492 that handles all requests by a remote web browser. In one embodiment, web server 492 is an Apache web server.
Control switch 410 converts analog calls that are incoming from the user into IP network frames using compression techniques. In one embodiment, control switch 410 communicates with control server 420 using a Transmission Control Protocol /Internet Protocol (TCP/IP) interface 422 that is a basic communication language of an IP network. Control server 420 uses software modules 424 to communicate with various service servers 425, for example, a database server 431. In one embodiment, database server 431 is an Oracle Enterprise Server that run's on Sun's Solaris OS. The database server 431 may store general data used by the services of the embedded system such as account information, rate information, control switch hardware configuration, and logs.
The embedded system embodiments described in the foregoing figures may operate as a remote resource to users and, thus, allow a user to receive the benefits of having in-house customized hardware without actually having the hardware locally. For example, all features of the embedded system may be
accessible through API 421. This allows a user to integrate the embedded system API into their IP network applications without the need for additional hardware. Since no purchase of hardware is required, a simple API integration may provide a Telco standard telephony backbone to handle a high volume (e.g., hundreds) of calls. In addition, by outsourcing maintenance heavy applications such as telephony and messaging, a business user can focus on their own business models.
The embedded system embodiments described above may provide a more stable hardware for telecommunications, simple and intuitive high-level API, and the ability to completely outsource telecommunication applications.
In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.