KR20000069024A - A communication system architecture - Google Patents

Abstract

Calling, data and other multimedia information is routed through a hybrid network, including the transmission of information over the Internet. Media order entry capture completes user profile information for the user. This profile information throughout the media experience for routing, billing, monitoring, reporting, and other media control functions is used by the system. Users can manage more aspects of the network than previously possible and can control network operations from central sites.

Description

Communication system architecture {A COMMUNICATION SYSTEM ARCHITECTURE}

The present invention relates to a combination of the Internet and a telephone system, and more particularly to systems, methods and articles of manufacture for using the Internet as a communication backbone of a communications system architecture while maintaining a series of call processing functions. It is about.

The invention also relates to the interconnection of the communication network with the Internet, including telephone capability. The Internet is increasingly becoming the network of choice for commerce. Recently, software companies have begun investigating the transmission of telephone calls over the Internet. However, the functions of the system that the user requires to handle general calls are considered essential for the handling of calls on the Internet. Today, these features are not available on the Internet.

Summary of the Invention

According to a broad aspect of the preferred embodiment of the present invention, telephone calls, data and other multimedia information are routed through a switched network that includes the transmission of information over the Internet using telephone routing information and Internet protocol address information. do. The telephone order entry procedure captures the overall user profile information for a user. This profile information is used by the system for routing, charging, monitoring, reporting, and other phone control functions during the call. Users can manage more aspects of the network than previously possible and control network activity from the central, allowing operators of the telephone system to maintain quality and routing choices. The profile information provides routing across the hybrid network (switched network and the Internet) for facsimile information. The system includes support for object-oriented paging and object filtering with general-purpose mailboxes.

According to a broad aspect of another preferred embodiment of the present invention, telephone calls, data and other multimedia information are routed through a hybrid network that includes transmission of information over the Internet using telephone routing information and Internet protocol address information. Users can manage more aspects of the network than previously possible and control network activity from the central, allowing operators of the telephone system to maintain quality and routing choices. The system creates data suitable for media communication over a hybrid network and stores this data in a distributed database. The system also partitions data into physical subsets and places them in various locations throughout the distributed database. Hybrid networks include support for handling collect calls.

According to a broad aspect of another preferred embodiment of the present invention, telephone calls, data and other multimedia information are routed through a switching network that includes the transmission of information over the Internet. Hybrid communication systems include switched networks. A packet transmission network is coupled to the switched network. The calling router is coupled to the switched network and the packet transport network. The gateway server, which communicates with the calling router, provides file transfer services to users connected to the hybrid communication network. Confirmation of the user is optionally authenticated by the authentication server.

According to another aspect according to a preferred embodiment of the present invention, an outer packet filter is coupled to the calling router and gateway server. The outer packet filter is configured to accept communications originating from a predetermined series of addresses.

According to another aspect of the invention, the gateway server is configured to provide only read-only file transfer services.

According to another aspect of the invention, a production token ring network is in communication with a gateway server. This generating token ring network is coupled to an internal packet filter configured to only accept communications originating from a predetermined set of addresses.

According to an aspect of another preferred embodiment of the present invention, other multimedia information, including telephone calls, data and voice and video, is routed through the switching network, which includes the transmission of information over the Internet. Users can join a video conference call, and each participant can view the video of the other participant at the same time and hear the voice.

According to an aspect of another preferred embodiment of the present invention, other multimedia information, including telephone calls, data and voice and video, is routed through a switching network that includes the transmission of information over the Internet. Users may also send (receive) video mail messages containing video, audio and / or data information with other users who may also receive (send) messages. If desired, users can also view stored video, audio and / or data information from a selected directory. Users can manage more aspects of the network than previously possible and control the network's activity from the central, while operators of the telephone system can continue to make quality and routing choices.

According to a preferred embodiment of another aspect of the present invention, a hybrid communication system includes a switched communication network. The packet transport network is coupled to the switched network. The calling router is coupled to the switched network and the packet transport network. The memory is coupled to the calling router, where the database of call parameters is stored. The call router is configured to route telephone calls through the telecommunications network and the packet transport network based on at least one call parameter from the call parameter database. The call router is also configured to provide an Intelligent Service Platform (ISP). The intelligent service platform includes at least one data client. The data server is coupled between the data client and the memory.

According to a preferred embodiment of another aspect of the invention, the intelligent service platform has a plurality of service engines each configured to execute the required service logic. The service selection element is coupled to the service engines so as to select a service instance running one of the service engines for processing transactions provided by the network having a hybrid communication system.

According to a preferred embodiment of another aspect of the present invention, the intelligent service platform has a central domain including a master database server configured to protect the control and integrity of the database. At least one satellite domain has a database client configured to provide user access and update capabilities and is coupled to a master database server.

According to a preferred embodiment of another aspect of the present invention, an intelligent service platform has a database client coupled to at least one service engine and between at least one service engine and a call parameter database, wherein the at least one service engine Get configuration data for customers supported by

According to an embodiment of another aspect of the present invention, an intelligent service platform includes an answering unit having various functions that can be utilized in a single connection.

According to an embodiment of another aspect of the invention, at least one service engine is coupled to the calling router. The service engine is configured to execute the logic defined by the profile information to provide a service function personalized for subscribers belonging to the profile information.

According to a preferred embodiment of another aspect of the invention, a hybrid switch for a communication system comprises at least one switching network interface and at least one internet interface. The bus combines at least one switching network interface and at least one internet interface. A host processor is coupled to the bus. The hybrid switch is coupled to at least one switching network and at least one internet to form a hybrid communication system. According to one embodiment of another aspect of the present invention, a method of processing communication in a hybrid switch includes receiving call processing instructions associated with a particular port of the hybrid switch. One communication is received at a port of the hybrid switch associated with the call processing instruction. An appropriate plug and play module specified in the call processing instruction is coupled to a specific port of the hybrid to handle the communication.

According to an embodiment of another aspect of the present invention, a call parameter database is stored in a memory in a method for establishing a call in a hybrid communication system comprising a switched communication network and a packet communication network. One call is received by the system. The call parameter database is accessed to determine at least one call parameter. Calls are routed through the switching network and packet transmission network based on at least one call parameter. The call parameter database is used to provide data about services provided during the call.

According to a preferred embodiment of another aspect of the invention, a plurality of service engines, each configured to execute the required service logic, is provided. A service instance running one of the service engines is selected to process a transaction provided by the networks having a hybrid communication system.

According to a preferred embodiment of another aspect of the present invention, at least one service engine is provided. Configuration data for the customer supported by the at least one service engine is obtained from the call parameter database.

According to a preferred embodiment of another aspect of the present invention, logic defined with profile information is executed to provide service functions personalized for the subscriber belonging to the profile information.

According to an embodiment of another aspect of the present invention, multiple functions are available from a single connection to an answering unit.

According to another aspect of the present invention, a computer program recorded on a computer-readable medium for establishing a call in a hybrid communication system including a switched communication network and a packet transmission network has first software for storing call parameters in a memory. The second software accesses the call parameter database when the system receives the call and receives at least one call parameter. The third software routes the call through the switched network and the packet transport network based on the at least one call parameter. The fourth software provides at least one service engine. The fifth software obtains configuration data for the customer supported by the at least one service engine from the call parameter database.

According to another aspect of the present invention, a fourth software provides a plurality of service engines each configured to execute required service logic. The fifth software selects a service instance running one of the service engines to process a transaction provided by a network having a hybrid communication system.

According to another aspect of the invention, the fourth software utilizes a call parameter database to provide data for the service provided upon the call. The fifth software couples the media server between the media client and the memory, and the media server uses logic to join one or more media clients into a collaborative session in which media is exchanged. The media server includes logic that dynamically adjusts the content sent to the media client based on factors such as bandwidth of the network and hardware supporting image, audio or voice. For example, parties participating in media conferencing at home may not have the necessary hardware to support video conferencing calls, but may have much bandwidth to support audio and may have computers to view collaborative data.

According to another aspect of the invention, the fourth software provides a central domain comprising a master database server configured to control and protect the integrity of the database. The fifth software includes a database client configured to provide user access and update capabilities and provides at least one satellite domain coupled to the master database.

According to another aspect of the present invention, the fourth software executes logic defined by the profile information to provide service functions personalized for the subscriber belonging to the profile information.

According to another aspect of the invention, the fourth software provides an answering unit. The fifth software makes multiple functions available from the single connection to the answering unit.

According to another aspect of the present invention, a computer program recorded on a computer-readable medium for processing communication in a hybrid switch includes first software for receiving call processing instructions associated with a special port of the hybrid switch, and associated with the call processing instructions. Second software for receiving communications at a port of the hybrid switch and third software for coupling the appropriate plug and play module specified in the call processing instruction to a special port of the hybrid switch for processing the communication.

These and other objects, aspects, and advantages will be better understood from the following detailed description of preferred embodiments of the invention with reference to the drawings.

1A is a block diagram of an exemplary hardware environment in accordance with a preferred embodiment.

1B is a block diagram illustrating the architecture of a typical Common Channel Signal System # 7 (SS7) network in accordance with the preferred embodiment.

Fig. 1C is a block diagram of an internet telephone system according to a preferred embodiment.

1D is a block diagram of a hybrid switch according to a preferred embodiment.

1E is a block diagram of the connection of a hybrid switch according to a preferred embodiment. .

Fig. 1F is a block diagram of a hybrid (Internet-telephone) switch according to the preferred embodiment.

Fig. 1G is a block diagram showing software processing relating to a hybrid internet telephony switch according to a preferred embodiment.

2 is a block diagram showing the use of PMUs in a typical SS7 network according to a preferred embodiment.

3 is a block diagram illustrating the system architecture of the preferred embodiment.

4 is a high level process flow diagram illustrating a logic system configuration in accordance with a preferred embodiment.

5-9 are process flow diagrams illustrating the detailed operation of the components illustrated in FIG. 4 according to a preferred embodiment.

10A is a diagram illustrating a public switched telephone network (PSTN) 1000 in accordance with a preferred embodiment, which includes a local switched carrier (LEC) 1020, through which the calling party has a telephone 1021 or computer 1030. To connect to the switching network.

Fig. 10B is a diagram illustrating an internet routing network according to a preferred embodiment.

11 illustrates a flow of information calls from a VNET PC to a PC according to a preferred embodiment.

12 illustrates an information call flow from a VNET PC to an out-of-network PC in accordance with the preferred embodiment.

Figure 13 illustrates an information call flow from an VNET PC to an out-of-network phone in accordance with the preferred embodiment.

14 illustrates an information call flow from an VNET PC to an in-network phone in accordance with the preferred embodiment.

Figure 15 illustrates an Internet telephone call from PC to PC in accordance with the preferred embodiment.

Figure 16 illustrates a telephone call routed from a PC to a telephone via the Internet in accordance with the preferred embodiment.

Figure 17 illustrates a call from a telephone to a PC consistent with the preferred embodiment.

Fig. 18 illustrates a call from telephone to telephone on the internet in accordance with the preferred embodiment.

19A and 19B illustrate an intelligent network consistent with the preferred embodiment.

19C illustrates a video conferencing architecture consistent with the preferred embodiment.

19D illustrates an image accumulation transfer architecture consistent with the preferred embodiment.

Fig. 19E illustrates an architecture for transmitting video telephony over the Internet, in accordance with the preferred embodiment.

Fig. 19F is a schematic diagram of an internet telephone system in accordance with the preferred embodiment.

Fig. 19G is a schematic diagram of a preferred connection / router according to the preferred embodiment.

20 is a high level configuration diagram of a network configuration system consistent with the preferred embodiment.

FIG. 21 is an operational configuration diagram of a portion of the system shown in FIG. 20 in accordance with the preferred embodiment.

FIG. 22 is another high level schematic diagram consistent with the preferred embodiment of FIG.

Figure 23 is a schematic diagram of a switchless network system in accordance with the preferred embodiment.

24 is a hierarchical structure diagram illustrating a portion of the system shown in FIGS. 20 and 23 in accordance with the preferred embodiment.

FIG. 25 is a schematic diagram illustrating a portion of a portion of the system shown in FIG. 24 in accordance with the preferred embodiment.

Fig. 26 is a structural diagram for explaining a part of the method according to the preferred embodiment.

27-39 are schematic diagrams illustrating another issue of the system of FIGS. 20 and 23 in accordance with the preferred embodiment.

40 is a schematic diagram of web server logon, consistent with the preferred embodiment.

Fig. 41 is a schematic diagram of a server directory used with the logon of Fig. 40 in accordance with the preferred embodiment.

42 is a more detailed schematic diagram of the logon of FIG. 40 in accordance with the preferred embodiment.

43-50 are schematic diagrams illustrating portions of a hybrid network in accordance with a preferred embodiment.

51 is a configuration of a data management section (DMZ) 5105 consistent with the preferred embodiment.

52A-52C are diagrams of network connections in connection with a dial-in environment consistent with the preferred embodiment.

Figure 53 depicts a flow chart illustrating fax tone detection in accordance with the preferred embodiment.

54A-54E depict flow charts for explaining VFP completion processing for fax and voice mail boxes consistent with the preferred embodiment.

55A and 55B depict operation of a pager finisher consistent with the preferred embodiment.

Figure 56 depicts a GetCallBack routine called from pager termination consistent with the preferred embodiment.

Fig. 57 shows a log in screen for access to online profile management to a user consistent with the preferred embodiment.

58 shows a call routing screen used to set or change a call instruction of a user consistent with the preferred embodiment.

Figure 59 shows a guest menu configuration screen used to set the guest menu presented to the caller other than the accounting owner in accordance with the preferred embodiment.

Figure 60 shows an override routing screen that allows routing all calls for a selected destination to a user consistent with the preferred embodiment.

Fig. 61 shows a speed dial number screen used for setting up a speed dial according to the preferred embodiment.

Fig. 62 shows a voice mail screen used for setting up a voice mail according to the preferred embodiment.

Figure 63 shows a faxmail screen used for setting up a faxmail in accordance with the preferred embodiment.

64 shows a call screening screen used to set up call screening consistent with the preferred embodiment.

65-67 show secondary screens used with user profile management consistent with the preferred embodiment.

Fig. 68 is a flowchart showing how a validity check on a speed dial number input by a user in accordance with the preferred embodiment is performed.

69A-69AI are flowcharts of an answering machine (ARU) call showing a software implementation consistent with the preferred embodiment.

70A-R are console call flow diagrams showing yet another software implementation consistent with the preferred embodiment.

Figure 71 illustrates a typical customer configuration for a system from VNET to VNET in accordance with the preferred embodiment.

72 illustrates the operation of a DAP consistent with the preferred embodiment.

Figure 73 illustrates a process consistent with the preferred embodiment in which the phone is connected to a Release Link Trunk for the processing of 1-800 calls.

74 illustrates the DAP procedure request from the customer side in accordance with the preferred embodiment.

75 illustrates the operation of switch 10530 to select a special number or hotline for a caller consistent with the preferred embodiment.

Fig. 76 illustrates the operation of the voice gateway based on the D computer for selectively routing telephone calls over the Internet, in accordance with the preferred embodiment.

FIG. 77 illustrates the operation of the VRU of FIG. 76 disposed in a centralized architecture consistent with the preferred embodiment.

78 illustrates the operation of the VRU of FIG. 76 deployed in a distributed architecture consistent with the preferred embodiment.

79A and 79B illustrate the operation of a sample application for an Internet call router consistent with the preferred embodiment.

79B illustrates a number of applications for customer transactions initiated by a caller consistent with the preferred embodiment.

Fig. 80 illustrates the configuration of a switching network providing voicemail and voice response device services in accordance with the preferred embodiment.

Figure 81 illustrates an Inbound Shared Automatic Call Distributor (ACD) call with data sharing through a database consistent with the preferred embodiment.

82 is a schematic diagram of an exemplary communication system consistent with the preferred embodiment.

83 is a schematic diagram of an exemplary computer system consistent with the preferred embodiment.

84 illustrates a CDR and PNR call recording format consistent with the preferred embodiment.

85A and 85B collectively describe the ECDR and EPNR call recording formats consistent with the preferred embodiment.

86 illustrates an OSR and POSR call recording format consistent with the preferred embodiment.

87A and 87B collectively describe the EOSR and EPOSR call recording formats consistent with the preferred embodiment.

Figure 88 comprehensively describes an SER call recording format consistent with the preferred embodiment.

89A and 89B are control flowcharts illustrating conditions under which a switch according to the preferred embodiment uses an extended recording format.

90 is a control flowchart for explaining a conversion time command consistent with the preferred embodiment.

91 is a control flowchart for explaining conversion daylight saving time control, which is consistent with the preferred embodiment.

92 is a control flowchart for explaining a network call identifier (NCID) switch call processing time control in accordance with a preferred embodiment.

93 is a control flowchart for explaining the processing of the received NCID in accordance with the preferred embodiment.

94A is a control flowchart for explaining generation of an NCID consistent with the preferred embodiment.

94B is a control flowchart for explaining the addition of the NCID to the call record, which is consistent with the preferred embodiment.

95 is a control flowchart for explaining the transfer of calls consistent with the preferred embodiment.

Figure 96 illustrates that a video operator consistent with the preferred embodiment is allowed to attend a video conferencing platform, providing services not limited to monitoring, viewing and recording video conferences, assisting video conference callers, and the like. A hardware configuration embodiment is shown.

97 shows a system for allowing a video operator to manage video conferencing, including a video operator console system consistent with the preferred embodiment.

98 shows a system for allowing a video operator to manage video conferencing, including a video operator console system consistent with the preferred embodiment.

99 shows how video conferencing is initiated by a video operator consistent with the preferred embodiment.

100 shows a class hierarchy for an image operator software system class consistent with the preferred embodiment.

FIG. 101 shows a state transition diagram illustrating a state change that may occur in a VOCall object's m_state variable, consistent with a preferred embodiment.

FIG. 102 shows a state transition diagram illustrating a state change that may occur in a VOConnection object's m_state variable, consistent with a preferred embodiment.

FIG. 103 shows a state transition diagram illustrating a state change that may occur in a VOConference object's m_state variable in accordance with a preferred embodiment.

FIG. 104 shows a state transition diagram illustrating a state change that may occur in a VORecoder object's m_state variable, consistent with a preferred embodiment.

105 illustrates a state transition diagram illustrating a state change that may occur in a VORecoder object's m_state variable, consistent with a preferred embodiment.

106 shows a class hierarchy for an image operator graphical user interface consistent with the preferred embodiment.

107 shows a database diagram for a video operator sharing database consistent with the preferred embodiment.

108 shows an embodiment of a main cone window consistent with the preferred embodiment.

109 shows an embodiment of a schedule window consistent with the preferred embodiment.

110 shows an embodiment of the conference window 41203 displayed when an operator consistent with the preferred embodiment selects a conference or playback session.

111 shows an embodiment of a video watch window 41204 displaying the H.320 input from a selected call or individual incoming or originating of a conference connection consistent with the preferred embodiment.

112 shows an embodiment of the console output window 41205 displaying all errors or warnings consistent with the preferred embodiment.

113 shows a properties dialog box consistent with the preferred embodiment.

Introduction to the Internet

I. Components of the Internet

The Internet is a way of interconnecting a physical network and a set of agreements to use a network that allows computers to interact with each other. Physically, the Internet is spread across 92 countries and consists of 59,000 academic, commercial, governmental and military networks, and the huge and global figure is expected to more than double annually according to statistics from the Government Accounting Office (GAO). Network.

In addition, 10 million host computers, 50 million users and 76,000 World Wide Web servers are connected to the Internet. The backbone of the Internet consists of a series of high-speed communication links between major supercomputer sites and educational and research institutions in the United States and around the world.

General misconceptions about the use of the word "internet" should be cleared. The word was originally used only as the name of a network based on the Internet protocol. Today, however, the Internet is used as a generic name for the entire class of networks. "Internet (lowercase I)" refers to the aggregate of individual physical networks interconnected by common protocols to form a single logical network. "Internet (uppercase I)" refers to many physical networks as a single logical network. Global aggregate of interconnected networks using the Internet protocol to connect to the network.

Ⅱ. Protocol standards

A. Internet Protocol

The protocol controls behavior according to the Internet backbone and thus provides important rules for data communication. Transmission Control Protocol / Internet Protocol (TCP / IP) is an open nature, useful for everyone, and refers to attempts to create network protocol systems that are independent of computer or network operating system and architecture differences.

B. International Telecommunication Union-Telecommunication Standardization Subdivision (ITU-T) Standard

ITU-T has established a number of standards governing protocols and line coding for telecommunication devices. Since many of the standards have been cited throughout this document, a summary of the relevant standards follows.

ITU G.711: Recommendation for pulse code modulation of 3 kHz voice channels.

ITU G.722: Recommendations for 7 kHz speech coding within 64 kbit / s channels.

ITU G.723: Recommendation for dual rate speech coder for transmission of multimedia communications at 5.3 and 6.3 kbit.

ITU G.728: Recommendations for speech coding at 16 kbit / s using low latency code activated linear prediction (LD-CELP).

ITU H.221: Frame structure for channels 64 to 1920 kbit / s in audiovisual services.

ITU H.223: Multiple Protocols for Low Bit Rate Multimedia Terminals.

ITU H.225: ITU Recommendation on Media Stream Packetization and Synchronization in Non-Guaranteed Query Services LANs.

ITU H.230: Frame synchronization control and indication signals for audiovisual systems.

ITU H.231: Multipoint Control Unit Recommendation for Audiovisual Systems Using Digital Channel Up to 2 Mbit / s.

ITU H.242: System for establishing communication between audiovisual terminals using digital channel up to 2 Mbit / s.

ITU H.243: A system for establishing communications between two or more audiovisual terminals using digital channel up to 2 Mbit / s.

ITU H.245 Recommendation on Control Protocols for Multimedia Communications.

ITU H.261: Recommendation for video coder-decoder for audiovisual services supporting video resolutions of 355 x 288 pixels and 176 x 144 pixels.

ITU H.263: Recommendation for video coder-decoder for audiovisual services supporting video resolutions of 128 × 96 pixels, 176 × 144 pixels, 352 × 288 pixels, and 704 × 576 pixels.

ITU H.320: Recommendations for Narrow Band ISDN Visual Telephone Systems.

ITU H.321: Visual telephone terminal on ATM.

ITU H.322: visual telephone terminal on the Guaranteed Query Service LAN.

ITU H.323: ITU Recommendation on visual telephony services and equipment for LANs providing non-guaranteed quality of service.

ITU H.324: ITU Recommendation on Terminals and Services for Low Bit Rate (28.8 Kbit) Multimedia Communications in Dial-Up Phone Services.

ITU T.120: Transmission protocol for multimedia communication.

Some other relevant standards have also been cited.

ISDN: A comprehensive telecommunications network, a digital communication standard for voice, video and data over a single communication link.

RTP: Real Time Transport Protocol, an Internet standard protocol for transmitting real-time data such as voice and video over single or multiple networks.

IP: Internet protocol, an Internet standard protocol for the transmission or delivery of data packets in packet-switched networks of interconnected computer systems.

PPP: Point-to-Point Protocol

MPEC: Video Standardization Group, a substandardization body of the International Organization for Standardization (ISO). Recommendations for the compression of digital video and audio, including bit streams, with the exception of the compression algorithm.

SLIP: Serial Line Internet Protocol.

RSVP: Resource Reservation Setting Protocol.

UDP: User datagram protocol.

III. TCP / IP function

The popularity of the TCP / IP protocol on the Internet has rapidly increased because it has the important function of satisfying and satisfying the important requests for global data communication. These features are still in use today:

1) configuring a common address setting in which a device running TCP / IP on the Internet sets the address of another device; and

2) It includes open protocol standards that can be useful and developed freely regardless of what hardware or operating system they are.

Thus TCP / IP can be used for Ethernet, token ring, dial-up line or virtually any other type of physical transport media.

Ⅳ. Information Transfer in Communication Networks

A. Exchange Technique

Understanding how information is communicated in communication systems requires understanding the recent footprint of those who play a very important role in today's Internet backbone affairs. US telephone systems use circuit switching techniques. When a person or computer makes a phone call, the switching equipment in the telephone system finds the physical path from the outgoing call to the called party. The circuit-switched network attempts to establish a dedicated connection or dedicated line between the two points by outgoing call from the local telephone station, the switching center across the trunk line, and eventually the line connection to the destination telephone. This private connection continues until the call ends.

The establishment of a complete path is a prerequisite for the transmission of data in circuit-switched networks. After the line is established, the microphone captures the analog signal, which is transmitted in analog form to a local exchange carrier (LEC) central station (CO) on an analog loop. The analog signal is converted to digital form after arriving at the LEC CO, even in modern cases where the equipment can support digital information. In an ISDN embodiment, however, the analog signal is converted to digital at the device and then transmitted to the LEC as digital information.

By maintaining a data path of 64 Kbit (thousand bits per second), the circuit ensures that samples can be delivered and can be reproduced. This rate is not the rate required to transmit the "digitized voice" itself, but the rate required to transmit the digitized "voice" by the pulse code modulation (PCM) technique. There are many ways to digitize voice, including ACPDM (32 Kbps), GSM (13 Kbps), TrueSpeech 8.5 (8.5 Kbps), and Voxware RT29HQ (2.9 Kbps). The 64 Kbps path is also maintained from the LEC CO switch to the LEC CO, but not end to end. The analog local loop carries analog signals rather than 64 Kbps digitized voice. One of these analog local loops is usually in the form of a "last mile" of each of the telephone network lines for contacting the caller's local telephone.

Ensuring this capability is the strength of circuit-switched networks. However, circuit switching has two drawbacks. First, the setup time is significant because the call is not called if the line is busy by another call: it will not be connected until another connection is terminated. Secondly, while it is expensive, its usefulness may be diminished. That is, the caller bears the cost of all the time during the call even though no data transfer is made. The usefulness may be low because the time between transmissions of the signals is a dedicated line and cannot be used for other calls. Once connected, unused time is wasted.

In addition, the entire circuit-switched subsystem is located around a 64 Kbps circuit. The underlying network uses PCM encoding techniques for speech. However, a high quality codec can code speech using less than one tenth of the PCM bandwidth. However, although one-tenth of the bandwidth is used, the circuit-switched network allocates 64 Kbps of bandwidth to a single call. Also, each line typically connects only two subscribers. Without the assistance of the conference bridging equipment, all lines to the telephone are taken over by connecting one subscriber to another. Except when used in combination with conference bridging equipment, circuit switching does not have multicast or multi-branch communication capability.

Other reasons for long call setup times include long distances that cause different signaling networks and propagation delays associated with call setup. The transfer of analog signals from the end to the CO based on low bandwidth links can also delay call setup.

In addition, call signal data travels long distances over a signal network rather than always transmitting data at the speed of light. If the call is international, the diversity of the signal network increases and the setup time increases because the equipment handling the call setup is usually not faster than the modem setup, and the call setup time increases further as the distance increases. Furthermore, connection-oriented virtual or physical circuit setup, such as circuit switching, generally requires more time to establish a connection because of the end-to-end connection required between the communicating subscribers than an unconnected technology.

Message exchange is an example of another exchange. This switching scheme does not pre-establish a physical path between the receiver and the sender. On the other hand, when the sender has a block of data to transmit, it is stored at the switching center first, and then retransmitted to the next switching unit after checking for errors. Message exchange is not limited in block size, and therefore the exchange must have a disk that will alleviate long data blocks. Also, if a block uses a line for a long time, message exchange is useless for the volume of the interaction.

Packet-switched networks, which make up the vast majority of the computer network industry, divide data into small pieces called packets that are multiplexed over high-capacity machine-to-machine connections. A packet is a block of data with a strict upper bound on the block size, with enough identification to be delivered to the destination. These packets contain hundreds of bytes of data and occupy transmission lines of tens of thousands of seconds. The delivery of large files by packet exchange breaks up many packets and sends each of them from one machine to another at a time. Network hardware forwards these packets to a specific destination, where software reassembles them into a file. Packet switching is used for virtually all computer interconnections due to the efficiency of data transmission. Packet-switched networks use only the bandwidth on the line as needed, and other transmissions between packet transmissions can be made over the line. In addition, throughput increases because routers or exchanges can send a portion of a packet or large file received to the next exchange quickly before other packets arrive. In message exchange, the intermediate router has to wait for the entire block to be delivered. Due to the superiority of packet transmission, message exchange is no longer used in computer networks today.

To better understand the Internet, a comparison with the telephone system is helpful. Public switched telephone networks are designed to transmit human voices in a recognizable form. Their suitability for computer communication has improved but is far from optimal. The cable between the two computers transfers data at hundreds of megabits and even gigabit. The error rate at this speed is only about once a day. On the other hand, dial-up using a standard telephone line has a maximum speed of a thousand bits per second and a higher error rate. The product of the error rate and the bit rate is about 10 ¹¹ of the local cable line. However, new technologies are improving the efficiency of telephone lines.

B. Gateways and Routers

The Internet consists of a large number of networks that form the overall connection of thousands of computer systems. After understanding that the machines are connected to individual networks, we can look at how to interconnect the networks that form the internetwork or the internet, where the internet gateway and the internet router Works.

In terms of architecture, two given networks are connected by one computer connecting them. Internet gateways and routers provide the necessary links to send packets between networks, thus making the connection possible. Without this connection, data communication over the Internet is not possible and the information does not reach its destination and cannot be understood even when it arrives. Gateways can be thought of as gateways to communication networks that perform code and protocol transitions between inconsistent networks. For example, gateways transfer electrical mail and data files between networks on the Internet.

IP routers are also computers that connect to the network and are a new word that vendors prefer. The router must determine how to send the received data packet to the destination by comparing it with the updated routing table. By analyzing the destination network address of the packet, the router makes this decision. Routers typically do not need to determine which host or user receives the packet. Routers, on the other hand, simply look for the destination network and do not necessarily need to be the proper end user, but remember the information that is appropriate to arrive at the right network. Thus, routers do not have to be huge supercomputer systems, they are often machines that are small and have little disk storage. The differences between gateways and routers are small and often blurred enough to be used interchangeably. In modern terminology, gateways transfer data between different protocols, and routers transfer data between different networks. Thus, the system that delivers mail between TCP / IP and OSI is a gateway, while traditional IP gateways (connecting different networks) are routers.

It is useful to look at routing simply in traditional telephone systems. The telephone system is redundant and networked in multiple hierarchies. Each telephone has two copper wires, which connect the telephone and the telephone company's nearest final office, the local central office. The distance is usually less than 10 km: there are nearly 20,000 final offices in the United States alone. The first three digits of the phone number, combined with the area code, represent a specific end office and refer to the speed and billing structure.

The two-line connection between each subscriber's phone and the final office is called a local loop. If the subscriber calls a subscriber connected to the same end office, the switching mechanism in the office establishes a direct electrical connection between the two local loops. This connection is continued for the duration of the call by the circuit-switched network. If the subscriber calls subscribers connected to different end offices, more work has to be done to route the call. First, each final office has one or more outgoing lines that connect to neighboring exchanges, called toll offices. This line is called a long distance trunk. If the caller and the receiver are connected to the same long distance trunk, the connection can be established within the long distance office. If the caller and receiver are not connected to the same long distance trunk, this connection can be made higher in the hierarchy. Regional offices and sectional offices form a network, which is connected to suburban offices. In the suburbs, local exchanges communicate with each other over high bandwidth inter-toll trunks. The types of exchanges and their distinctive forms vary from country to country depending on the telephone density.

C. How to use network level communication for smooth user connection

In addition to the Internet's data transfer capabilities, TCP / IP convinces users that the Internet is the only virtual network. TCP / IP accomplishes this by connecting machines globally, regardless of the specific network the host or user is connected to. In addition to the router interconnection of the physical network, there is a need for an application that allows each host to use the software, the Internet, as the only real physical network.

D. Datagram and Routing

The basis of the Internet service is a basic, connectionless packet transmission system operated by a router, using packets as the basis of transmission. In the Internet operating TCP / IP, such as the Internet backbone, this packet is called a datagram.

This section describes how this datagram is routed through the Internet.

In a packet-switched network, routing is the process of determining which path to send a packet through. As mentioned above. A router is a computer that makes such a choice. In order to route information from one host to another on the same network, the transmitted datagram does not need to reach the Internet backbone. This is an example of internal routing. Machines outside of the network are not involved in this internal routing decision.

The distinction between direct transmission and indirect transmission is as follows. Direct transmission refers to the transmission of datagrams between different machines on a network. Such a transmission is not associated with a router. The sender, on the other hand, summarizes the datagram in the form of a physical frame, writes an address, and sends the frame directly to the destination machine.

Indirect transmission is necessary when more than one physical network is involved. That is, used to transmit information on different networks. This type of communication can be thought of as routing information through the Internet backbone. Routers are essential for indirect transmission. To send a datagram, the sender identifies the router to which to send the datagram, which then sends the datagram to the destination network. Routers do not remember individual host addresses that are millions of times, and have remembered thousands of physical networks. In essence, in the Internet, routers are cooperative and form an interconnected structure, where datagrams cross one back-to-back router across the backbone until the router reaches a router that can directly transfer datagrams. Is sent to.

V. Technical Overview

The constant influx of new technologies and systems is changing the Internet world. The three developments below, which are likely to become more prevalent in the near future, provide an overview of the technology world.

A. ATM

Asynchronous Transfer Mode (ATM) is an excellent technology that uses a high-speed, connection-oriented system for local and wide area networks. ATM networks are:

High speed switches operating at gigabits per second (trillion bits) to handle traffic from many computers

An optical fiber (versus copper) that has a switch that connects the host and the ATM and operates at a speed of 100 or 155 Mbps, providing high-speed data transmission; and

Requires modern hardware containing cells of fixed size of 53 bytes each.

ATM is designed to transmit not only data but also voice, video and television signals, thus integrating the functions of packet switching and circuit switching. Pure packet-switched techniques are not satisfactory for performing voice transmissions that require more stable bandwidth.

B. Frame relay

Frame relay systems use packet-switched technology, but are more efficient than traditional systems. This efficiency is due in part to performing fewer error checks than traditional X.25 packet-switched services. Many intermediate nodes perform little or no error checking, only routing, and error checking at the higher levels of the system. The high reliability of today's transmissions eliminates many of the error checks that were previously made. Thus, frame relay offers higher achievement than traditional systems.

C. ISDN

Integrated Service Digital Networks (ISDN) are "international telecommunications standards for the transmission of voice, video and data over digital lines," which typically operate at 64 Kbit / s. Traditional telephone networks operate at 4 Kbit / s voice. To adopt ISDN, end users or companies must upgrade to ISDN terminal equipment, central station hardware, and central station software. The purpose of ISDN is to:

Providing internationally accepted standards for voice, data and signals,

Digitizing all transmission lines between ends,

Employing a standard out-of-band signal system, and

Include providing more bandwidth to the desktop.

Ⅵ. MCI Intelligent Network

The MCI intelligent network is a call processing architecture for handling voice, fax and related services. The intelligent network consists of a multipurpose computer and a specific purpose bridging switch with a specific capacity along an automatic call spreader (ACD). Call processing, including number conversion services, automatic or manual operator services, validation services, database services, and the like, is performed by a series of dedicated multipurpose computers with specialized software. New value-added services can be easily integrated into the system in a simple and cost-effective way by extending the software.

Definitions may help for the words below.

ISP: Intelligent Service Platform

NCS: Network Control System

DAP: data connection point

ACD: Auto Call Disperser

ISN: Intelligent Service Network

ISNAP: Intelligent Switch Subprocessor

MTOC: Manual Telecommunication Operation Console

ARU: Voice Answering Device

ACP: Auto Call Handler

NAS: Network Voice Server

EVS: Extended Voice Service

POTS: Traditional Old Telephone System

ATM: Asynchronous Transmission Method

The intelligent network architecture has a rich set of features and is very flexible. The addition of new features and services is simple and fast. Functions and services may be extended using special purpose software running on a multipurpose computer. The addition of new features and services is made by upgrading specific purpose software, which is economical.

Intelligent network features and services include:

· Call type identification,

Call routing and selective termination

Select operator and call hold

Voice recognition and automatic, interactive response

Customer and customer profile verification and validity check

Voice mail

Call validity check and database

Voice meeting reservation

Fax transmission and press

Customer charge

Fraud Monitoring

· Operational measurement and usage statistics reporting; and

Includes switch interface and control

A. Components of MCI Intelligent Network

19A illustrates an intelligent network consistent with the preferred embodiment. The MCI intelligent network consists of a number of components. The main components of the MCI intelligent network

MCI switching network 2,

Network control system (NCS) / data connection point (DAP) 3,

ISN-intelligent service network 4, and

EVS-includes extended voice service 9

1. MCI Switching Network

The MCI switching network consists of a special purpose bridging switch 2. This bridging switch 2 routes and connects the caller and the called party after the call is verified by intelligent service network 4. The bridging switch has a limited programming capacity and provides basic exchange services under the control of the Intelligent Service Network (ISN) 4.

2. Network control system / data connection point (NCS / DAP)

NCS / DAP 3 is an essential component of the MCI intelligent network. DAP provides a variety of database services, such as conversion. It also provides services to identify the switch ID and trunk ID of the number of incoming calls.

The services provided by NCS / DAP 3 are:

Number conversion for 800, 900 VNET numbers,

Enhanced parameter routing, including range limits and time, date, source and percent assignments to limit long distance options,

An information database including the switch ID and the trunk ID among the called numbers for the call;

Remote queries to customer databases,

· VNET / 950 card validation test, and

Includes VNET ANI / DAL Validation Services

3. Intelligent Service Network (ISN) 4

ISN 4 includes an automatic call spreader (ACD) for routing calls. The ACD communicates with Intelligent Switching Network Attachment Processor (ISNAP) 5 and sends the call to another manual or automatic agent. ISN includes ISNAP 5 and Operator Network Center (ONC).

ISNAP 5 is responsible for group selection and operator selection for call routing. ISNAP communicates with the ACD to send a call to another agent. ISNAP is also responsible for coordinating data and voice for calls assisted by the operator. ONC consists of agents, servers, and databases, including live operators or auto responders (ACPs), MTOCs, and answering machines (ARUs), including NAS 7. The system communicates with each other on an Ethernet LAN and provides various services for call processing.

The services provided by ONC are:

Validity checking services, including call type identification, call validity checking and call restriction;

Manual or automatic operator service for customer support

Database service for various database lookups,

· Call expansion capability,

· Call bridging ability,

Prompts for user input, and

Include play voice messages.

4. Enhanced Voice Service (EVS)

The extended voice service offers menu-based routing services in addition to several added features. The EVS system facilitates user input and provides special services for routing calls or voicemail or fax routing based on customer input. The services provided by EVS, a component of the MCI intelligent network, are:

Play customer specific voice services,

Prompt for user input,

User input based on information access;

· Call expansion capability,

· Call bridging ability,

Voice conferencing ability,

Call transfer capability

User voice message recording,

Remote update of recorded voice messages, and

Includes sending and receiving faxes.

5. Additional Factors

In addition to the components mentioned above, a series of additional elements is included in the MCI intelligent network. These components are:

Intelligent Call Routing (ICR) services are provided for special call routing based on information obtained from the caller during or prior to the call. Routing is also obtained based on knowledge of physical or logical network deployment. Additional intelligent routing based on time and replaceable routing services based on busy routers are also provided.

Charging is one of the major components of the MCI intelligent network. The billing component provides a service for billing customers based on the call type and call time. Special billing services are additionally provided for value added services such as 800 collect calls.

• The functional monitoring component is one of the major components of the MCI intelligent network that provides services to prevent revenue reductions due to deceptive or illegal use of the network.

Operational measurements contain information gathered for analysis of production performance. The analysis of the response to the advertising campaign, the type of call that leads to the specialized report, derives from the operational measurement. The gathered information is used to predict future production plans or infrastructure needs.

Usage statistics reporting involves gathering information from an operational database and billing information for generating reports on usage. Accounting reports are used to study call types, load types and demographic information. These reports are used for future production planning and marketing inputs.

B. Intelligent Network System Summary

The MCI call handling architecture was built by several major components, including the MCI switch network, network control system, extended voice service and intelligent service network. Call processing is done by a series of general purpose computers and some specialized processors, which form the basis of the MCI intelligent network. The switch is a special purpose bridging switch with limited programming capacity and complex interface.

Adding new functions to the switch is very difficult and sometimes impossible. Calls on the MCI switch are first validated if number translation is required, as with 800 numbers. If number translation is required, it is made at the switch based on an internal table, or such request is sent to DAP, a multipurpose computer with software that determines trunk ID and switch ID among the number translation and called numbers. Calls are routed to the ACD where they are sent to various call processing agents, such as live operators or ARUs. The ACD communicates with ISNAP to determine which group of agents are responsible for the call and which agents can handle the call.

The agent handles calls received by communicating with a network information distribution service (NIDS) server, which is a verification or database server with the necessary databases for the various services provided by the ISN. When the call is verified by processing the call by the server, it communicates that status back to the ACD. The ACD dials the called number, bridges the incoming call with the called number, and executes the Release Link Trunk (RLT) to release the call back to the switch. The agent also generates billing details (BDR) for billing. When the call is terminated, the switch generates an operation service record that later matches the corresponding BDR information to generate full billing information. The addition of the newly added service is straightforward, and the new functionality can be added by the addition of software and other computing system configurations at the ISP. A typical call flow scenario is described below.

C. Embodiment of Call Flow

An embodiment of the call flow describes the processing of a 800 number collect call from phone 1 to 10 as shown in FIG. 19A. This call is initiated by the caller dialing 1-800 COLLECT to collect call to callee 10. The call is routed to the nearest MCI switching facility by the Calling Party's Regional Bell Operating Company (RBOC) knowing that this number is owned by MCI and connected to MCI switch 2.

The switch 2 confirms that it is an 800 number service, performs 800 number translation from a reference table in the switch, or provides a number translation service using a database lookup and requires a data access point (DAP) 3.

Call processing is passed to a series of intelligent computing systems via an automatic call spreader 4. In this embodiment, because the call is a collect call call, the caller must reach a manual or automatic operator before the call can proceed further. Calls from the switch are sent to ACD 4, optionally present along ISNAP 5. ISNAP 5 determines which group of agents will handle the call according to the type of call. This task is called group select. Agents capable of handling calls include Automatic Telecommunications Operator Console (MTOC) 6 or Automatic Call Processor (ACP) 7 associated with Network Voice Server (NAS) 7a. ISNAP 5 determines which agent is free to handle the call and routes the voice call to a specific agent. The agent consists of very sophisticated call processing software. The agent collects all relevant information from the caller, including the telephone number of the called party. The agent communicates with the database server making a series of database lookup requests. The database lookup request includes call constraints, including questions about the type of call, call validation based on caller and callee's phone numbers, and call blocking restrictions based on caller and callee's phone numbers, if any. The agent then signals the ISNA-ACD combination to wait for the caller to dial and dial to connect to the called party. The agent informs the caller of the information about the caller and the fact of the request for the collect call. The agent collects the response from the callee and continues processing the call.

If the callee agrees to receive the call, the agent signals the ISNAP-ACD combination to bridge the caller and the callee. The agent then blocks the BDRs that match the individual OSRs generated by the switch to produce complete billing information. The ISNAP-ACD combination then bridges the caller and the called party and executes RLT to release the line back to the switch. The caller and the callee communicate with each other through the switch. At the end of the call by either side, the switch generates an OSR that matches the BDR previously generated to produce complete call information.

If the callee rejects the collect call, the agent signals the ACD-ISNAP combination to reconnect the caller who is held back on the agent. Finally, the agent notifies the caller of the caller's response, generates a BDR, and terminates the call.

The MCI intelligent network is a structured and efficient network architecture for call handling and is based on a series of intelligent processors with specialized software, specialized bridging switches and ACDs. An intelligent network is an overlay network that coexists with an MCI exchange network and consists of several specialized processors that interact with the exchange network to handle calls. One embodiment of an intelligent network is wholly voice oriented. Data and faxes are treated as voice calls using some professional and dedicated features and value-added services.

In another embodiment, intelligent networks have been employed for emerging technologies, including POTS based videophones and Internet telephony for video and voice. The following paragraphs detail the architecture, functions, and services based on emerging new technologies.

ISN compatibility with emerging technologies

The following paragraphs detail architectures, functions and services based on emerging new technologies, all of which are integrated into an intelligent network.

Iii. ISP framework

A. Background

An ISP consists of several heterogeneous systems. As ISP integration progresses, previously independent systems are becoming part of larger integrations, with a concomitant increase in the level of analysis, testing, scheduling, and training in all areas of ISP.

1. Broadband access

The range of high bandwidth services is supported by the preferred embodiment. This includes the imaging, meetings, distance learning and telemedicine required.

Asynchronous transmission (ATM) pushes network control to the periphery of the network to circumvent the switching model of telephones based on trunks and traditional circuits. This approach is expected to be widely deployed to promote high bandwidth services.

2. Internet Telephone System

The Internet and the World Wide Web provide easy customer access, a wide range of commercial opportunities, and foster the role of successful telecommunications companies. The ISP platform offers a variety of features that can be applied from the telephone to the Internet. Such functions include access, customer equipment, personal accounting, billing, marketing (and advertising) data or applications, and basic telephone services.

The telecommunications industry is a major transport provider of the Internet. Preferred embodiments that provide various functions in a telephone environment for Internet customers are optimized.

Fig. 19F is a configuration diagram of a telephone system consistent with the Internet preferred embodiment. Several computers 1900, 1901, 1902, 1903 are connected to the Internet 1910 by Ethernet or other network connection behind the FireWall 1905. Domain name system 1906 maps names to IP addresses on the Internet. Individual systems for charge 1920, preparation 1920, directory service 1934, message service 1930, and voice message 1932 are connected to the Internet 1910 by a communication link. Another communication link may be used to facilitate communication with a peripheral device 1940 that is used to communicate information to a series of devices 1941-1943. Web server 1944 provides access to the Internet 1910 for order entry system 1945.

In an embodiment, the order entry system 1945 generates complete profile information including name, address, fax number, secretary's number, disclaimer's telephone number, email number, IP address, and phonemail address from a given telephone number. This information is maintained in a database that is accessed by anyone who is authorized to access it on the network. In another embodiment, the order entry system uses a web interface to access an existing directory service database 1934 that provides information about the profile to supplement the information entered by the user. The Internet 1910 is coupled to the Public Switched Network (PSTN) 1960 through Gateway 1950. In the preferred embodiment, the gateway 1950 provides virtual connections from circuit switched calls in the PSTN 1960 and several entities in the Internet 1910.

The PSTN 1960 has a variety of systems, including direct dialing 1970, data access point (DAP) 1972 to facilitate 800 number processing, and VNET processing, for example to facilitate company connection lines. The Public Branch Exchange (PBX) 1980 is connected between the PSTN and various computer equipment such as fax 1981, telephone 1982, and modem 1983 via a communication link to facilitate communications. Operator 1973 may optionally be connected to a call to help locate a call or conference call that is input (or output) to (or at) PSTN 1960 or Internet 1910.

A variety of services provide individual communication links, including access to Intelligent Service Network (ISN) 1990, Direct Dial Plan 1991, Preparation 1974, Order Entry 1975, Charge 1976, Directory Service 1977, Conference Service 1978, and Authorization / Authentication Service 1979. Can be connected to the PSTN. All these services can communicate with each other by themselves using the PSTN 1960 and the Internet 1910 through the Gateway 1950. The functionality of the ISN and DAP 1972 can be utilized by devices connected to the Internet 1910.

Fig. 19G is a schematic diagram of a preferred connection / router according to the preferred embodiment. The PAR-Prioritizing Access Router is designed to combine the functions of an Internet access device and an Internet Protocol (IP) router. The PAR allows the dial-up modem to access the Internet by converting the necessary modem and PPP / SLIP to IP and back to IP to PPP / SLIP. The PAR also analyzes IP packet source / destination addresses and UPD or TCP ports and selects the appropriate output network interface for each packet. Recently, PARs use preferential routing techniques to prioritize packets destined for a particular network interface over other network interfaces.

The purpose of the first connection / router is to separate the real-time call volume from the rest of the best effort data call volume on the internet network. The volume of real-time and interactive multimedia calls at the Internet access point is best isolated from the call volume without real-time enforcement, thus ensuring high quality service control. The process of using the first connection / router is described below with reference to FIG. 19G.

First, in 2010, the computer dials up to the PAR via a modem. The computer modem negotiates data rate and modem protocol parameters with the PAR modem. The computer establishes a two Point-to-Point Protocol (PPP) section with a PAR that uses a modem-to-modem connection over a public switched telephone network (PSTN) connection. The computer sends a PPP packet to the PAR via a modem connection. The PAR modem 2010 sends the PPP packet from the modem to the processor 2020, which converts the PPP packet from PPP to IP through the host processor interface 2080. The host processor interface in the modem may be used now or any physical interface previously invented. Some examples include ISA, EISA, VME, SC bus, MVIP booth, memory channel and TDM booth. The use of multiple booths, such as time division multiple device (TDM) booths, has several advantages because it dedicates capacity to specific data flows and preserves deterministic behavior.

The PPP-to-IP conversion processor 2020 converts the PPP packet into an IP packet, and transmits the IP packet back to the packet classification 2050 through the process to process interface 2085. The interprocess interface may be a physical interface or a software interface between dedicated processor hardware. Examples of software interfaces between processes include function or subroutine calls, message queues, and shared memory. Direct memory access (DIA), mailboxes and the like.

Packet classification 2085 determines whether a packet belongs to a particular priority group. The packet classifier has a flow specification table, which includes: destination IP address, source IP address, combined source / destination IP address, combined destination IP address / UDP port, combined destination IP address / TCP port, combined source IP address / UDP port, combined source IP address / TCP port, source IP address combined with destination IP address and TCP or UDP port, destination IP address combined with source IP address, and It is defined by a TCP or UDP port, a destination IP address and a signal source IP address combined with a TCP / UDP port, and a TCP or UDP port.

The packet classifier checks the flow statement table against the IP address and UDP or TCP port used for the packet. If any match is found, this packet is classified as a priority flow and tagged with a priority. The resource reservation setup protocol technique may be used at the packet classifier level.

The packet classifier 2050 takes over the packet scheduler 2060 with and without the priority tag attached through the interprocess interface. The interprocess interface 2090 need not match the interprocess interface 2085, but the same is useful. Packet scheduler 2060 prefers to prioritize packets first, and uses priority queue technology such as Weighted Fair Queuing to be placed on the external network interface in front of competing best effort calls.

The packet classifier 2060 hands over the packet to the external network interface 2010, 2070, 2071, or 2072 in the host processor via a peripheral bus 2095 in order of priority. Any number of external network interfaces can be used.

The IP packet may reach the PAR via the non-modem interfaces 2070, 2071, and 2072. Examples of such interfaces are Ethernet, high speed Ethernet, FDDI, ATM, and frame relay. These packets go on the same path as the IP packets arriving through the modem PPP interface.

First, the flow specification is managed through the control processor 2030. The control processor may accept an externally installed priority reservation through the external control application program interface 2040. The controller verifies priority reservations for special flows against admission control procedures and policy procedures. And if the reservation is granted, the flow statement through the interprocess interface 2050 is entered into the flow statement table in the packet classifier. The interprocess interface 2065 need not be the same as the interprocess interface 2085, but the same is useful.

Figure 20 illustrates the architectural framework used in the present invention for intelligent service platform (ISP) 2100. The intention of the ISP 2100 architecture is to define an integrated approach to the provisioning and delivery of intelligent services across MCI networks across all components of the ISP.

Each existing communication network system has its own way of providing service management, resource management, security, distributed processing, network control, or operational support. The architecture of ISP 2100 defines a single cohesive architectural framework that provides the above functionality. This architecture aims to achieve the following goals:

Global capacity generation,

Delivery of extended future services,

Efficient use of resources;

· Saving marketing time,

Reduce maintenance and operation costs;

Rise in average production quality, and

Introduction to expanding capacity up or down.

The purpose capacity of an ISP is to provide installation of a basic configuration for a variety of basic services. These services are characterized by high bandwidth, large customer control or personal flexibility, and reduced, sometimes instant, preparation cycles.

3. Capacity

ISP 2100 is global and everywhere. Globally, the ISP reaches all countries through a network of alliance partners. By sector, it is spread throughout all offices and residences by wire or wired connection.

4. Future service

This function can be used to convey the following:

Telephone and messaging services that exceed what we have today,

Providing rising video and multimedia

Powerful data services, including extended private networks, and

Software and equipment that enable the user to have full control over the service.

Services provided by ISP 2100 may be extended to advertising, agriculture, education, entertainment, finance, politics, law, production, medicine, network transmission, real estate, research, retail, shipment, telecommunications, travel, resale, and other purposes. Can be.

Service is:

Orderable: Customers can tailor the provision of services to their needs,

Understand and operate with the customer: The customer has direct access to manage and control the service,

Loosely coupled: the service acquires and acquires network resources only when needed, the customer pays only for what is used, and the bandwidth is available if required without pre-allocating,

Safe and private: Your privacy and secrecy are key in the network world. Commercial transactions are safe and confidential. Users and customers are timed and authenticated, and the network is protected from corruption.

B. ISP Architecture Framework

The following paragraphs describe the role of ISP platform 2100 in providing services to customers.

ISP 2100 provides services to customers through an intelligent service infrastructure including provider network facility 2102, public network facility 2104, and customer equipment 2106. The service infrastructure ensures end-to-end quality of service and usability.

The following paragraphs describe the relationship between ISP platform 2100 and various external systems, either inside or outside the provider.

The provider component 2108 of FIG. 20 is:

Intelligent Services 2110-includes internal data communications network 2102, responsible for service preparation, service delivery, and service assurance. This represents the role of the ISP.

Import management 2112-responsible for the accounting of customer service.

Network Management 2114-Responsible for the operation and development of the physical network 2102.

Production management 2116-responsible for the production and marketing of customer service.

The external entity of 2100 depicted in FIG. 20 is:

Network 2104-This represents the connection method used by the customer for the entire network connection and service. This includes the provider's circuit-switched network, packet-switched network, internally extended wide area network, the Internet, the provider's wireless partner's network, the provider's global alliance and regional partner network, broadband network, as well as customer premises equipment coupled to this network. do.

Third Service Provider 2120-This represents an external network that delivers services to customers via ISP 2100.

Service reseller 2122-This represents a network with customers using facility 2100.

Global Alliance Partner 2124-A network with shared facilities and exchange capabilities across networks and service infrastructures.

C. Functional Framework of ISP

21 illustrates the components of ISP 2100 in more detail. A set of logical components is shown that make up the architecture of ISP 2100. None of these are single physical entities, each of which typically exists in plural places. The components work together to provide a continuous intelligent service 2100 environment. This environment is not fixed. It is planned to be a flexible and evolving platform that can add useful new services and integrate with new technologies. The platform components are linked by one or more network connections that include an internal distributed processing infrastructure.

The functional components of the ISP 2100 are:

Inbound and outbound gateways 2126-enable access to services provided by other providers, and allow other providers to access the services of providers;

• A commercially available service gateway 2128 that allows you to interface to a third-party service creation environment for sale. The service is deployed and updated through a salable service gateway. This is no different from managed service gateway 2130 except that deployed and created services are for external customers.

Management service gateway 2130-Describes the concept of service creation applied to the management and service logic of the platform. The management service is deployed and managed through the management service gateway 2130. In addition, an interface with a management system external to the ISP 2100 is realized by the management services gateway 2130. Some examples of management services include collection, temporary storage, and transmission of network results. Other services include the collection and filtering of alert information from ISP 2100 prior to transmission to network management 2132.

Service Engine 2132-Service logic execution environment for salable or managed services. Service engine 2132 executes the logic contained in a particular customer profile to provide unique and commercialized service functionality.

Service creation environment 2136-Create and deploy services for sale, as well as potential services and capabilities.

Data management 2138-where all customer and service profile data is placed. The data is cached in service engine 2134, statistics server 2140, call context server 2142, analytics server 2144, and other specialized applications or server 2146 that require ISP 2100 data.

Service selection 2148-Whether the service is connected via a small-band or broadband network, circuit switched, or cell switched, the service is connected via the service selection function 2148. Service selection 2148 is a specialized version of service engine 2134 specifically designed for selecting one or more services to run.

Resource management 2150-Manages all resources, including specialized resources 2152, examples of services operating on service engine 2134, and other types of resources that exist in ISP 2100 that require management and allocation.

Specialized resource 2152-A capability based on a particular network (speech the Internet, DTMF-detection, fax, voice recognition, etc.) appears as a specialized resource 2152.

• Calling context server 2142-accepts real-time network results records and service results records and permits questions about the data. Once all the results for the call have been generated, the combined result information is sent to the import management function 2154 in its entirety. Data is stored for a short time.

Statistics server 2140-allows you to receive statistical results from service engines, perform lookups, and ask questions about data. Data is stored for a short time.

Customer-Based Capacity 2156-Customer-based software and specialized hardware that enables customer-based abilities, such as ANI screening, Internet access, compression, interactive games, video conferencing, retail access, and more.

Analysis Services 2144-A special kind of service engine that is not based on network connections, but based on value added based on real time or near real time network statistics or call context information. Examples include deception detection and customer call volume statistics.

Other Special Services 2146-involves specialized types of applications or servers based on or without a service engine. This component provides a low level of functional capacity and other computing resources that can be used for service delivery, monitoring or management.

D. ISP Integrated Network Services

22 shows how ISP architecture 2100 provides a service over another network. This network includes the Internet 2160, the Public Switched Telephone Network (PSTN) 2162, the Metro Access Ring 2164, the Wireless 2166, and the like. In addition, new switchless broadband architectures 2168 and 2170, such as ATM or ISO Ethernet, may be substituted for the current PSTN network 2162.

The architecture employs several networks in addition to the basic PSTN 2162, since this interchangeable network can often support services that cannot be provided by the PSTN at a low cost. Such a network is depicted in FIG.

Each of these new networks is planned to interact with ISP 2100. Calls (or transactions) originate within the network from customer service requests, and the ISP provides the service by receiving the transaction, first identifying the customer, and sending the transaction to the general purpose service engine 2174. The service engine determines which service functions are needed and applies the necessary logic, or uses specialized network resources for the required functions.

ISP 2100 itself is under the control of a set of resource managers and management and monitoring mechanisms. A single system can be achieved by using a common information base at the same time. The information base holds all customer, service, network and resource information created or used by the ISP. Other external applications are allowed to access through gateways, intermediate steps, and sometimes directly to the same information base.

In Figure 22, each entity depicts one logical element of the ISP. Each of these entities is typically arranged in plural in a plurality of places.

E. ISP Components

Ext App 2176-External Applications:

App 2178-Internal ISP Applications (such as Deception Analysis):

Dc 2180-Data Client. Client to ISP information base providing local data copy:

DS 2182-Data Server. One of the master copies of ISP information:

Admin 2184-ISP Management Functions (for configuration and maintenance):

Mon 2186-ISP monitoring features (for mistakes, achievements, and accounting):

GRM 2188-Global Resource Management Overview for Selected Resources:

LRM 2190-Overview of local resource management for selected resources:

SR 2192-pool of specialized resources (such as video server, port, voice recognition):

SE 2134-Universal service engine that executes the required service logic: and

Service Selection 2194-The ability to select a service (operated by service engine 2134) that handles transactions provided by the network.

F. Switchless Communication Service

Switchless network 2168 is a word used to apply cell-switched or packet-switched technology to both data and multimedia communications services. In the past, circuit switching was the only existing technology for the transport of time-sensitive isochronous voice. Now, thanks to the development of asynchronous transport cell switched networks that provide quality of service guarantees, a single network infrastructure can be achieved that provides isochronous and fast data services. Switchless networks are expected to provide a lower cost model than circuit-switched architectures. The reason is that:

Flexibility to provide exactly the bandwidth required for each application and to save bandwidth when no data is transmitted. At least 56 Kbps circuits are not automatically assigned to all calls.

Adaptability to compression techniques to further reduce bandwidth requirements for each network section.

Low cost for specialized resource equipment that arises because there is no need to provide an analog port for access to special DSP capacity such as voice recognition or conferencing.

• Applicability and ease of adaptability to advanced high bandwidth services such as video conferencing, training on demand, remote specialization, integrated video / voice / email, and information services.

Figure 23 illustrates a sample of a switchless network 2168 consistent with the preferred embodiment.

G. Control Principles

1. Architectural Principles

This paragraph lists the architectural principles that provide the foundation for the architecture.

The service principle is:

1. The service model shall support the continuous integration of new and existing services.

2. Services are created from a common Service Creation Environment (SCE) that provides a continuous overview of services.

3. All services run within a common service creation environment.

4. Every service is created from one or more service functions.

5. The data stored in one computer profile on the ISP data server can be used to derive multiple services.

6. The service model shall support enumeration and execution of service parameters for each service. These service parameters, when combined, provide the appropriate service for each customer. Service placement shall take into account the listed service parameters.

2. Service Function Principle

1. All service functions are described by a combination of one or more capacities.

2. All service functions can be defined by a fixed number of capacities.

3. Individual service functions should be able to be defined using standard methods that allow service creators to have a common understanding of capacity. Each service function shall detail the entry, error count, display type and potential service application.

4. The interaction of physical entities throughout the network should not be visible to the user of the service function through the service function interface.

5. Each service function shall have a single, stable external interface. The interface is depicted as a series of operations, and as the data required and provided by each operation.

6. Service functions are not themselves deployed in the network. The service function is arranged only as part of the service logic function program that stimulates the service function (Fig. 21). Therefore, the service function is statically linked to the service logic program, and the capacity is dynamically linked to the service logic program. This is where the combination of resources for services takes place.

3. Capacity principle

1. Capacity is defined completely independently from consideration of any physical or logical implementation.

2. Each capacity should have a single and stable interface. The interface is depicted as a series of operations, and as the data required and provided by each operation.

3. Individual capacity should be defined using standard methods that allow service designers to have a common understanding of capacity. Each service function shall detail the entry, error count, display type and potential service application.

4. The interaction of physical entities throughout the network should not be visible to capacity users through the capacity interface.

5. Doses may be combined to form high levels of dose.

6. Operations on capacity define one complete activity. Operations on capacity have one logical starting point and one or more logical end points.

7. Capacity can be realized in one or more physical hardware or software throughout the network.

8. The data required by each capacity operation is defined by the capacity operation support data and user request data parameters.

9. Capacity is deployed in the network regardless of any service.

10. Capacity is global in its nature, and in the service designer's point of view, its location does not need to be considered by the service designer because the entire network is considered as a single entity.

11. The dose is renewable. They can be used without supplementing other services.

4. Service creation, deployment, and execution principles

1. Each service engine 2134 supports part of the customer base. The list of customers supported by the service engine is derived from the configuration data and stored in ISP data server 2182.

2. Each service engine 2134 obtains its configuration data from the ISP data server 2152 in active time.

3. Service engine 2134 is configured for ISP service engine 2134, if necessary, and uses database client 2180 (see data management section) to temporarily store data needed to support customers. Temporary storage may be controlled by ISP data server 2182 or by a database of ISP data server 2182. If there is too much to load data from data server 2182, the data can be stored semi-permanently on service engine 2134 (disk or memory).

4. Service engine 2134 is expected to run all or some customer service. However, in the case of service interactions, one service engine 2134 must always control the execution of the service. The service engine can take over control to other service engines during service execution.

5. The service engine does not own any data or even configuration data.

6. The service engine does not aim at the placement of data. Data server 2182 is intended for the placement of data.

5. Resource Management Model 2150 Principles

1. Resource 2152 must be accessible from anywhere on the network.

2. Resources are not service specific and can be shared by all desired services.

3. Services of the same type are managed in a group.

4. Resource management model 2152 must be flexible enough to adopt management policies that include minimum cost, round robin, minimum use, maximum efficiency, modern environment, continuous use until failure, and exclusive use. .

5. Resource management model 2150 should optimize resource allocation, if possible, to respect selected policies.

6. The RM 2150, on the basis of a transaction, shall provide a view of resource allocation techniques, from the static configuration of transactions to the allocation of fully dynamic resources.

7. RM 2150 shall take account of resource use policies such as resource depletion and preemptive preallocation.

8. Resource management model 2150 should be able to check and access the status, use and health of resources in the resource pool.

9. All resources 2152 shall be treated as managed objects.

10. All resources must be registerable to enter the pool using RM 2150 and unregisterable to exit the pool.

11. The only way to request, acquire and release resources is through RM 2150.

12. Relationships between resources should not be classical, and individual needs of a given resource should be allocated from the registered pool in response to needs and requests.

13. All specialized resources 2152 must be manageable from an overview of the persistent platform.

14. All specialized resources 2152 shall provide SNMP or CMIF agent functionality, either directly or via a proxy.

15. All specialized resources 2152 should be able to be expressed as a common management information base.

16. All specialized resources 2152 shall support a set of standard operations for questioning, exploration, positioning outside or inside the service, and testing items.

17. All specialized resources 2152 shall provide a set of basic self-checking capacities controlled through standard SNMP or CMIF management interfaces.

6. Data Management 2138 Principles

1. Multiple copies of any data specification are allowed.

2. Multiple versions of the value of the data specification are possible, but one view is considered a master.

3. The master version of a given specification is under a single rule.

4. Multiple users are allowed to simultaneously access the same data.

5. Office rules should be applied uniformly to ISP 2100 to ensure the validity of all data changes.

6. Users work on local copies of data, and data connections are in independent and transparent locations.

7. From the point of view of data management, a user is a component of an application or other software.

8. The data connection shall conform to a single series of methods standardized through ISP 2100.

9. Personal data is located in the local database but cannot be shared or distributed.

10. Only master data can be shared or distributed.

11. Private formats for shared data specifications are allowed in local databases.

12. The transactional capacity may be loosened at the discretion of the user if allowed within the office rules.

13. Rule-based logic and other metadata controls provide a flexible means of applying policies.

14. Data replication provides reliability by replicating data sources.

15. Distribution of the database may provide scalability by reducing the size of any particular data store, or by reducing the transaction rate for any particular data store.

16. Data management 2138 shall allow both static and dynamic configuration of data resources.

17. Common data models and common schemas should be adopted.

18. The logical application of data is disconnected from physical data operations such as file relocation, database reloading, and data reformatting.

19. Audit trails and case histories are required to address appropriate issues.

20. Online data audits and coordination are required for data integrity.

21. Data recovery of a failed database is necessary in real time.

22. Data matrices are required for monitoring, trending and control purposes.

23. A 7 by 24 operation with a 99.9999 utilization rate is required.

24. The data management 2138 mechanism must be scalable for high levels of growth.

25. The data management 2138 mechanism should provide a cost-effective solution for both large and small scales.

26. The data management 2138 mechanism should mercifully deal with multiple provisioning situations.

27. Data handling and data concurrency must occur to meet our office needs.

28. Reliable order entry and service creation should occur whenever possible, via the ISP database, not the intermediate application.

29. All data must be protected and additionally customer data must be kept confidential and reliable.

30. Configuration, Operational Settings and Uptime Parameters are mastered in the ISP Management Information Base (MIB).

31. Wherever possible, standardized data solutions should be used to meet data management needs.

The following principles are described in the object-oriented issues.

32. A data item is the lowest series of persistent objects. This object wraps a single data value.

33. A data item can have a user-defined form.

34. Data items can be created or deleted.

35. A data item has only one read and set method.

36. Internal values of data specifications are enforced by range restrictions and rules.

37. Data items that are in a valueless state shall not be accessed by the user.

7. Operational Support Principles

1. Common View-All ISP 2100 Operational Support User Interfaces must have the same look and feel.

2. Functional Commonality-Management of objects is expressed in the same way throughout the ISP operational support environment.

3. One view-one distributed managed object is represented as one in the ISP operational support user interface, and distribution is automatic.

4. OS / DM Domain-Data within the Operational Support Domain shall be managed by the ISP Data Management 2138 mechanism.

5. Global MIB-There is a logical global MIB that represents the resource at the entire ISP.

6. External MIBs-Embedded MIBs that are part of the managed components are outside of operational support and data management.

7. System structure-System structure for ISP OS standard can be secured through intermediary layer.

8. Operational Functions-The operational sector handles network layer and element management for physical and logical resources.

9. Management Functions-The management department handles planning and service management.

10. Profile domain-The service and customer profile database is managed by the management sector under the domain of the data management system.

11. Telecommunication Management Network (TMN) Compliance-TMN Compliance can be realized in TMN systems through gateways.

12. Concurrency-Multiple operators and administrators should be able to perform operations simultaneously from the ISP OS interface.

8. Physical Model Principles

1. Compatibility-The physical network model provides backward compatibility with existing communications hardware and software.

2. Scalability-The physical network model is scalable to meet a wide range of customer populations and service needs.

3. Redundancy-The physical network model provides multiple information paths for information flow through two network elements. Failure at one point can be ignored.

4. Permeability-Network elements are permeable under network redundancy. In the event of a failure, replacement with a redundant link is automatic.

5. Idiomatic Degradation-The physical network model can provide useful information by gradual reduction of capacity in case of multiple network failures.

6. Interoperability-The physical network model allows networks with different characteristics to interoperate with other network elements.

7. Security-The physical network model requires and transmits secure transmission of information. It has the ability to guarantee secure access to network elements.

8. Monitoring-The physical network model provides well-defined interfaces and connection methods for monitoring call volume on the network. The security mentioned above is perfected by defending unauthorized access to sensitive data.

9. Distribution Possibilities-The physical network model is splittable to form an isolated management domain.

10. Quality of service-The physical network model is a universal service. It provides quality of service such as appropriate service and user selective service.

11. Global access-The physical network model does not prevent access to network elements because of its location on the network.

12. Coordination Awareness-The physical network model can adapt to sudden changes in the coordination environment.

13. Cost-effectiveness-The physical network model enables cost-effective devices by not relying on the capabilities of one vendor platform or specific standard.

H. ISP Service Model

This paragraph describes the service model of the ISP architecture framework.

1. Purpose

The ISP service model establishes a framework to support the following services.

Fast service creation and deployment.

Efficient service execution.

Full commercial control of services for our customers.

· Full service integration with continuous service overview for customers.

Improved reuse of ISP capacity through capacity combining.

Reduced cost of service devices.

Vendor independence.

2. Range of action

The ISP service model supports all activities related to the service, including the following:

·Ready

·produce

·arrangement

·Command

· Update

·monitoring

·Execution

Testing or simulation

Customer support and obstacle tracking

Charge

・ Disability ticket handling

Operational Support

This model includes sellable services and management services.

· Sale is available Service It is a service that is purchased by our customers.

Management services are part of the operation of the MCI network and are not sold to customers.

The service model also defines interactions with other parts of the ISP architecture, including data management, resource management, and operational support.

3. Service Model Overview

Delivery of service 2200 is located in the center of the ISP (Figure 24). Service is the most important issue in the ability of a telecommunications service provider to make money. The following service definitions are used throughout this service model. A service is a set of capacities that combine well-defined logical structures and business processes that, when connected through a published interface, produce desirable and expected results for the user.

The main difference between service 2200 and application 2176 or 2178 is that service 2200 includes office processes that support sales, operations and maintenance of services. The key challenge in developing services is to define what can be automated and to clarify how humans interact with services.

4. Service structure

The vocabulary used to describe a service includes the service itself, service functions and capacities. This structure has a three-layer structure as shown in FIG.

The service 2200 is an object in terms of object-oriented objects as described above. The service 2200 contains another object called service function 2202. Service function 2202 provides a well-defined interface for eliciting one or more controlled interactions of capacity 2204 in the ISP framework for service.

The service function 2202 in turn uses various capacity 2204 objects. Capacity 2204 is a standard, reusable optical network building block used to create service function 2202. The main condition for service creation is that the engineer creating the basic capacity object ensures that each of them is reusable for many other necessary services.

a) service 2200

Service 2200 is basically described in service logic, a program written in a very high level programming language. Or using a graphical user interface. This service logic program is:

Whether any service function 2202 is used,

The order in which service functions are invoked,

The source of the input service data,

The destination of the output service data,

Error value and error handling

Invocation of other services 2200,

Interaction with other services, and

Identify interactions with other services.

The service logic itself is typically not sufficient to run service 2200 in the network. In general, customer data will need to define numbers for flexibility issues, or commercialize services for customer specific needs. Management and sales services are part of the same service model. Similarity of management and sales data allows sharing of capacity. Management and sales data represent two issues of the same network. In other words, management services represent the operational issues of the network, while sales services represent the external customer or user issues of the network. Both services rely on commonly preserved network data. All sales services have a means for customers to order services, charge mechanisms, other operational support capacity, and service monitoring capacity. Management services provide the processing and support capacity for maintenance of the platform.

b) service functions 2202

Service function 2202 provides a well-defined interface of function calls. Just as capacity 2204 can be reused in many other service functions 2202, service functions can be reused in many other services 2200. The service function 2202 has a specific data entry condition which is derived from the data entry condition of the lower layer capacity. The data output method of the service function is defined by the creator of the service function based on the data running from the capacity of the lower layer. The service function 2202 does not depend on the presence or absence of physical resources, but depends on the capacity 2204, as shown in FIG. Examples of service features include:

Time-based routing-Based on capacities such as calendar, date / time, and call objects, this function enables routing to different locations based on time.

Authentication-Based on capacity such as comparison and data lookup, this function can be used to check the validity of the calling card usage by facilitating entry of the card number and / or access number. This feature can also be used to check connectivity to a virtual premises network.

Automatic user interaction-voice objects (for recording and playing back voices), calling objects (for sending and bridging calls to special resources), DTMP objects (for collecting and outpulsing DTMP digits) Based on capacity, such as lexical objects (for use with speech recognition), this function may allow automatic interaction with the user of the service. This service function object may be extended to include capacity for visual interaction with the user.

c) capacity 2204

Capacity 2204 is an object that means capacity has a well-defined interface for dot product, dedicated state data and examples of creation, deletion, and use of capacity. Promotion of capacity 2204 is done by promoting one of its interface operations. Capacity 2204 was installed for reuse. Thus, capacity has well-defined data requirements for input and output structures. The capacity also has a clearly defined error handling routine. Capacities can be defined within an object-oriented hierarchy, with the result that universal capacities can be inherited by several other capacities.

Some examples of capacity objects based on the network are:

Voice (for recording and playback),

Calling (for bridging, forwarding, forwarding, dial-out, etc.),

DTMF (for calling and outpulsing), and

Fax (for receiving, transmitting, or broadcasting).

Some capacity is network based, and some are entirely dependent on the data deployed on our platform. Examples of such doses are:

Calendar (to determine when the date is),

· Contrast (for contrasting digits or characters),

• Conversion (to convert data types into interchangeable formats). And

Variance (to select results based on percent variance);

d) service data;

There are three sources of data while the service is running:

Static data defined in a service template containing default values for a given service promotion,

Interactive data derived from explicit user input or built-in network connections, and

• Customer data defined in the user profile defined by the customer or its representative when the service is required (eg creation time).

5. Run service 2200

The service 2200 is executed in a service logic execution environment (SLEE). SLEE is executable software that can run any service deployed in ISP 2100. Service engine 2134 provides this execution environment. The service engine 2134 simply executes a service arranged in the service engine.

The service template and support profile are deployed on database server 2182 (Figure 22). When SLEE runs on service engine 2134, SLEE retrieves its configuration from database server 2182. The configuration instructs SLEE to execute the list of services 2200. The software for this service is part of the service template deployed on the database server 2182. If the software is not ready on service engine 2134, the software is retrieved from database server 2192. The software is executed and service 2200 starts to operate.

In most cases, service 2200 first stimulates service function 2202 (Figure 24). This allows the service to register itself with resource manager 2188 or 2190. Once registered, the service will begin accepting transactions. The service 2200 then stimulates the service function 2202 waiting for the initiation. This action can be anything from Internet logon to 800 calls or sales card check data transactions. If an initiation occurs in the network, the service selection function 2148 detects the case of a service running using the resource manager function 2150. The initiation action is delivered in the service 2200 case, and the service logic (from the service template) determines the successive action by stimulating the additional service function 2202.

While service 2200 is running, profile data is used to determine the behavior of service function 2202. Depending on the requirements of the service performance, some or all of the profile data required for service may be temporarily stored in the service engine 2134 from the ISP 2100 database server 2182 to prevent expensive remote database lookups. As the service executes, the information can be generated by the service function 2202 and stored in a context database. This information is uniquely identified by the network transaction identifier. For circuit switched calls, a predefined network call identifier can be used as a transaction identifier. Additional information may be generated by the network equipment, stored in a context database, and also indexed by the same transaction identifier. The last network element associated with a transaction stores the end of the transaction information in a context database. The linked list strategy is used to determine when all the information for a particular transaction is stored in the context database. When all the information arrives, an idea is created for the service that agrees with that kind of idea, and the service runs on the data in the context database. Such operations include extracting data from a contextual database and passing it to a billing system or deception analysis system.

6. Service Interaction

In a network transaction, one or more services may be stimulated by the network. Sometimes the indication of one service can compete with the indication of another service. An example of such a competition is for a VNET caller to request a service that makes international calls that are not allowed to the caller. The VNET caller dials the number of another VNET user that is allowed to make international calls, and the called VNET user bridges the call if it accepts the international call. The first caller may make an international call to a third party and is not limited to his company not allowing international calls. In this situation, it is necessary to allow the two services to interact to determine whether to bridge international calls.

The ISP service model should allow service 2200 to interact with other services. There are several ways the service 2200 interacts with other services:

Transfer of control 2210, where the service terminates its execution path and transfers control to another service,

Concurrent Interaction 2212: Here a service stimulates another service and waits for a response,

Asynchronous interaction: where a service stimulates another service, performs another action, and then waits for another service to complete and respond, and

One-way interaction 2216: Here the service stimulates another service but does not wait for a response.

In the example of the interactive VNET service, the incoming VNET service may query the originating VNET service using the concurrent service interaction capacity. This interesting twist is because service logic can be deployed together on network-based platforms and customer premises equipment. This means that service interactions must occur between network-based services and customer-based services.

7. Service monitoring

Service 2200 must be monitored by both the customer and the network. Monitoring occurs by one of two things:

The service 2200 may generate detailed mapping information for delivery to the transaction context database.

The service 2200 may generate statistical information for periodic delivery to a statistical database or for immediate retrieval as required by the statistical database.

The analysis service may use a statistical database or a contextual database to perform a real time or near real time data analysis service.

The contextual data service collects all mapping information related to network transactions. This information constitutes all the information needed for network troubleshooting, billing, or network monitoring.

I. ISP Data Management Model

This paragraph describes data management 2138 in the context of the ISP 2100 target architecture.

1. Scope

ISP Data Management The 2138 architecture involves the transfer of information across ISP boundaries and is intended to establish a model that addresses the creation, maintenance, and use of data within an ISP-generated environment.

The data management 2138 architecture handles all persistent data, the copying and flow of data within the ISP, and the flow of information across ISP boundaries. The model defines a list of data access, data partitioning, data safety, data integration, data manipulation, and database management. It also outlines the management policy if necessary.

2. Purpose

The purpose of this architecture is to:

Creating a common ISP functional model for data management;

· Isolation of data at the application,

Establishing a partner for the design of the data system,

Providing rules for system deployment,

Guiding future technology and choices, and

· Reduce redundant development and redundant data storage;

Additional objectives of the target architecture are:

To ensure data flexibility;

Promote data sharing;

To perform ISP data control and integration;

Establishing data safety and protection;

Enabling data access and use;

Providing high data performance and reliability,

Satisfying data partitioning, and

· To achieve operational simplicity.

3. Data Management Overview

In one embodiment, the data management architecture is a framework that describes various system components, how the systems interact, and the expected behavior of each component. In this embodiment the data is stored simultaneously in multiple locations, but the data and its duplicated copy appear logically as one specification. The main difference in this embodiment is that the user instructs what data will be downloaded and stored.

a) domain

Data and data connections are characterized by two domains 2220 and 2222 as shown in FIG. Each domain may have a plurality of data copies therein. In addition, domains create one logical and global database that can be extended to international boundaries. The main point about domain definition is that all data connections are the same. There is no difference in order entry supplied from call processing lookup or network side data update.

The central domain 2220 controls and protects the integration of the system. This is only a logical description, not a physical entity. Peripheral domain 2222 provides user access and updates capacity. This is only a logical description, not a physical entity.

b) division

Normally data is stored simultaneously in multiple locations. The data and its duplicated copy appear to be logically a specification. Any of these copies can be partitioned into physical subsets, so not all data items are needed at one site. However, partitioning only maintains a logical overview of one single database.

c) architecture

This architecture is a distributed database and distributed data access architecture with the following features:

Replication and motivation;

Partitioning of data files,

Simultaneous control,

Transactional capacity, and

Shared common schema.

Figure 28 shows logical system components and high level information flows. None of the described components is a physical entity. Multiple instances of each occur in the architecture. Elements of Figure 28 are:

Network 2224-external access to ISP 2100 at network side,

SVC I / F 2226-network interface to the ISP,

System 2228-external application such as order entry,

G / W 2230-gateway to ISP for external applications,

DbAppl 2232-roll requiring data access and update capacity

Db client 2234-the first role for the peripheral domain,

Db server 2236-primary role for the central domain,

DbAdmin 2238-administrative role for data,

DbMon 2240-monitoring roll,

I / F Admin 2242-administrative role for the interface, and

0ps 2244-operating cone.

d) information flow

The flow described in FIG. 28 is logical extraction. They embody the characteristics of information forms that pass between logical components. In that flow:

Request-data request from the external system to the ISP,

Response-response to external request from ISP,

Access-retrieval of data by applications within the ISP;

Update-Update data by application inside ISP

Evts-the mapping related to the data sent to the monitor,

Meas-metrics related to the data sent to the monitor,

New data-in addition to ISP master data,

Changed Data-changing ISP master data,

View-retrieving ISP master data,

Subscription-an asynchronous stream of ISP master data,

Cache copy-Snapshot copy of ISP master data,

Execution-any control activity, and

Control-Contains any control data.

e) domain combinations

Peripheral domain 2222 of data management 2138 is typically:

ISP application,

External system,

Network interface 2226 and system gateway 2230; and

Database client (dbClient) 2234, etc.

The central domain for data management 2138 is typically:

Monitoring (dbMon) 2240,

Administration (dbAdmin) 2238, and

Database master (dbServer) 2236, and so on.

4. Logical Technology

The function of each architecture component is described separately below.

a) Data application (dbAppl) 2232

This includes any ISP application that requires a database connection. Examples include ISN NIDS servers and DAP transaction servers. The application accesses the required database and obtains the required data from the database client 2234 by providing any required policy commands. The application also provides database access for external system or network elements such as order entry or switch request translation.

The data application supports the following features:

Update: allows an application to insert, update or delete data in the ISP database,

Connection request: A connection request allows an application to retrieve data, list multiple items, select items from a list, or repeat a series of procedures, and

Thought and measurement: Mapping and measurement are a special form of update directed to monitoring function 2240.

b) data measurement 2138

(1) client database 2234

The client database represents a peripheral copy of the data. This is the only way for an application to access ISP data. Peripheral copies do not have to match the format of the data as stored in database server 2236.

The client database is stored in master database 2236 for subscription or cache copy of data. Subscriptions are automatically maintained by the database server 2236, but cache copying must be made fresh when the version becomes obsolete.

The main issue of the client database is to ensure that data updates by the application are continuously listed and synchronized with the master copy held by the database server 2236. However, it is reasonable for the client database to accept the update and only later synchronize the change with the database server. Whether or not to select an update in the lock step is not a problem of data management but a problem of application policy.

Only changes made to the database server are propagated to the client database.

If client database 2234 is disabled or unable to communicate with the database server, the client database must be synchronized with the master again. In extreme cases, operator intervention may be required to reload the entire database or a selected subset.

Client database 2234 provides the following interface operations:

Access to a set of specific data by authorized applications;

· Determination of policy preferences by authorized applications;

Selecting a particular view of a local copy of the data,

Inserting, updating or deleting local copies of data;

Synchronizing subscribed data with the database server, and

Expiration guidance from database server for cached data.

In addition, the database client submits log or report and signal problems to the monitor 2240.

(2) data master (database server-dbServer)

Database server 2236 plays a central role in protecting data. At the database server, data is owned and the master copy is maintained. A copy of at least two master data is maintained for reliability. Additional master copies can be placed to improve data achievement.

This copy is synchronized at the lockstep. In other words, each update is required to obtain a corresponding master lock to prevent update contention. Strict realization policies may change, but typically all master copies must maintain a sequential update order and provide the same view of the data and the same integrated enforcement as other master copies. An internal copy of the data is transparent to the database client 2234.

Database server 2236 describes or enforces relationships between data specifications and includes a hierarchy of clerical rules that restrict specific data values or formats. All data updates must pass or reject this rule. In this way, the database server ensures that all data is managed as a single copy, and that all office rules are collected and applied uniformly.

Database server 2236 tracks data changes as they occur and provides log and summary statistics to the monitor. In addition, this change is communicated to the active subscription, indicating that the cachecopy is useless by the expiration message. The database server also provides safety checks and certifications and ensures that selected items are coded before they are stored.

The database server supports the following interface operations:

Viewing selected data from a database server,

Joining selected data from a database server,

• Copy the selected data to a cache copy on the database client 2234.

• provide a new copy of the current copy required of the database client;

Inserting new data into all master database server copies,

Changing data attributes in all database server copies, and

Canceling the previous subscription and clearing the cache copy of the data.

(3) data management 2238

Data management 2238 involves setting data policies, managing logical and physical databases, and securing and configuring data management 2138 domains. Data management policies include safety, distribution, integration rules, performance requirements, and control of replication and partitioning. Data management 2238 includes physical control of data resources such as setting data locations, allocating physical storage, allocating memory, loading data, optimizing connection paths, and troubleshooting database problems. Data management 2238 also provides logical control of the data, such as auditing, coordinating, moving, cataloging and converting the data.

Data management 2238 supports the following interface operations:

Defining the characteristics of the data form,

Creating a logical container of a given dimension,

Associating two or more containers through a combination,

Conditional triggering and execution of data values or relationships;

Placing a physical container for the data at a given location,

Moving the physical container for the data to a new location,

Removing physical containers and their data,

Loading data from one container to another,

Deleting the data contents of the container, and

· To verify or adjust the contents of data in containers.

(4) Data Monitoring (dbMon) 2240

Data monitoring 2240 represents a monitoring function that captures all data-related events and statistical measurements from ISP perimeter gateways, database clients, and database servers. The data monitoring 2240 mechanism is used to generate audit trails and logs.

Data monitoring typically represents a passive interface. The data is fed to it. But monitoring is a hierarchical activity, and further analysis and rollup takes place within data monitoring. In addition, data monitoring sends an alert when certain thresholds or conditions are met.

The speed and number of metrics are used to assess service quality, data performance, and other service level agreements. All exceptions and errors are logged and moved to data monitoring for data inspection, storage and rollup.

The data monitoring 2240 supports the following interface operations:

Setting monitor controls, filters and thresholds,

Logging activity related to the data,

·condition. Reporting metrics or audit results, and

Sending an alarm or warning signal.

(5) Data Management Operations (0ps) 2244

Operational console (0ps) 2244 provides workstation interfaces for personalnel monitoring, management, and other management systems. Ops Console provides access to the operational interfaces for dbMon 2240, dbMon 2238, and dbSever 2236 described above. The 0ps Cone 2244 has a variety of systems and interfaces. And an icon based on a storage state diagram (or a map) of an application device or the like in the data management domain.

5. Physical Technology

This paragraph describes data management 2138 physical architecture. This describes how a set of components is arranged. A general layout overview is shown in FIG.

In Figure 29:

The circle was used to represent the physics site,

The box and box combination is a computer node, and

Functional roles are abbreviated.

Abbreviations used in FIG. 29 are:

OE-Order Entry System 2250,

GW-ISP Gateway 2230,

APP-application device 2232,

CL-database client 2234,

SVR-database server 2236,

ADM-data management component 2238,

MON-data monitoring component 2240, and

0ps-operating cone, etc.

The functional role of the elements has been mentioned above in connection with FIG.

Each site shown in FIG. 29 is connected to another site by one or more wide area network (WAN) links. Correct network configuration and arrangement remains a detailed engineering challenge. It is not unusual for database copies to be distributed to order entry site 2251. However, in this architecture, the entry site is considered equivalent to the surrounding site and has a database function.

On the network side of ISP 2100, each of the peripheral sites 2252 has a database client 2234. This site normally operates a local area network (LAN). The database client acts as a local repository for network or system applications such as ISN operator consoles, ARUs, or NCS switch request translations. The central site 2254 provides the database client with redundant data storage and data access paths. Although the data monitoring component 2240 can be placed at the peripheral site for increased performance, the central site also provides rollup monitoring.

The management function is located at the desired operational or management site 2254, but does not necessarily have to be in the same location as data monitoring. Administrative functions require an operational control and dbAdmin for command and control. The remote operations site can access dbAmin node 2238 from a wide area or local area connection. Each site is backed up by replication function components at other sites and connected by various redundant links.

6. Select technology

The following paragraphs describe the various technology options that should be considered. Data Management The 2138 architecture does not require any special technology to operate, but other technology choices can affect the final performance of the system.

30 depicts a series of technologies that provide a very high performance environment. The specific application shown in the figure is to determine the minimum acceptable performance. Three general environments are shown:

At the top, a multiprotocol routed network 2260 connects external and remote elements with the central data site. High-availability application platforms such as management terminals and small mid-range computers and order entries are shown:

At the center is a large, high-performance machine 2262 with large data storage: these are typical of master databases, data processing, and data conversion / tracking features such as dbServer and dbMon:

The lower layer shows near processing and network interface 2264, such as an ISN operator center or DAP site.

7. Finished

Many of the current ISP data systems are known, but additional detailed requirements are needed before final completion can be determined. This requirement requires ISN, NCS, EVS, NIA and TMN systems, and also adds all of the new products planned for broadband, Internet and switchless applications.

8. Safety

ISP data is a protected integrated resource. Data connections are limited and authenticated. Activity related to the data is tracked and audited. Data encryption is required for all stored passwords, personal identification numbers (PINS), personal personnel records and selected financial, office and customer information. Secured data must be transmitted in clear-text form.

9. Meta-data

Meta-data is a form of data that constitutes a rule for data derivation logic. Metadata is used to describe and manage the operation of the data. Under this architecture, a lot of control is derived that is derived from metadata. Metadata usually provides the most flexible runtime options. Metadata is usually under the control of a system administrator.

10. Standard Database Technology

Completion of the proposed data management architecture should use commercially available products whenever possible. Vendors include database technology, replication services, rule systems, and monitoring devices. Cone environment and other useful provisions.

J. ISP Resource Management Model

This paragraph describes the resource management 2150 model because it relates to the ISP 2100 architecture.

a) scope

The resource management model deals with the cycle of resource allocation and deallocation in the relationship between the process that requires the resource and the resource itself. This cycle begins with resource registration and resource de-allocation, and continues with resource requests, resource acquisition, resource interactions, and resource release.

b) purpose

The resource management model 2150 is generally intended to define common architectural guidelines for ISP development communities, and specifically for ISP architectures.

c) goals

In existing traditional ISP architectures, services control and manage their physical and logical resources. Transferring resources from services to the architecture requires defining management functions that control the interactions and relationships between resources and services. This functionality is represented by the resource management 2150 model.

The goal of the resource management model is designed to allow for network-wide resource management, to optimize resource usage, and to share resources across networks:

Extracting resources from services;

Providing real-time access to resource status,

Simplifying the process of adding and removing resources,

Providing secure and simple access to resources, and

Providing equitable resource acquisition so that no one of the users of the resource monopolizes the resource.

d) basic concepts

The resource management 2150 model typically controls the relationships and interactions between resources and the processors using them. Before the model is presented, an understanding of the basic terms and concepts to describe the model must be established.

A list of terms and concepts follows.

(1) Definition

Resources-The basic unit of work that provides specific and well-defined capacity when stimulated by external processes. Resources can be logically classified as such as service engines and language-aware algorithms, and physically as CPUs, memory, and switch ports. Resources may be shared, such as ATM link bandwidth or disk space, and may also be dedicated, such as VRUs or switch ports.

Resource Pool-A set of registered resources that share a common capacity.

Services-logical representations of the flow of all activities and interactions between users of network resources and the resources themselves.

· Policy-A set of rules governing the execution of dealing with resource allocation and deallocation, resource pool thresholds, and resource utilization thresholds.

(2) concept

A resource management model is a mechanism that controls or allows a set of functions to request, acquire, and release resources to and from resource pools through well defined procedures and policies. Resource allocation and deallocation are three steps:

Resource request: The process requires a resource from the resource manager 2150.

Resource Acquisition: If the required resource is useful and the requesting process has the authority to request it, resource manager 2150 grants the resource, and the process can use it. On the other hand, the process may give up the resource allocation process and try again later, or require the resource manager to grant the resource.

Resource release: The allocated resource is returned back to the resource pool when the process no longer needs the resource. Depending on the type of resource, the process releases the resource and informs the resource manager of the new status, or the process itself informs the resource manager that the resource is useful. In either of these two ways, the resource manager returns the resource to the resource pool.

The resource management model considers the creation of resource pools and the policies that control them. The resource management model allows resources to be registered or deregistered as legitimate members of the resource pool. Resource management model policies enforce load balancing, failover and least cost algorithms, and prevent services from monopolizing resources. The resource management model tracks resource usage and automatically takes corrective action if the resource pool does not meet the needs. Any service can use any resource over the network if it is authorized.

The resource management model adopts the 0SI object-oriented approach to model resources. Under this model, each resource is represented as a managed object (MO). Each MO is defined in the following discussion.

Attributes: MO attributes are used to express the nature of the MO and to describe the characteristics and current state of the MO. Each property is associated with a value. For example, the current state (CURRENT_STATE) attribute of M0 means IDLE.

Operation: Each MO has a series of operations.

This operation includes:

Create: creating a new MO,

Delete: To delete the current MO,

Execute: performing a specific operation, such as SHUTDOWN,

Getting a value: getting a specific MO attribute value,

Value addition: adding specific MO attribute values,

Remove values: remove a particular MO attribute value from a set of values,

Value substitution: replacement of the current MO property value with a different value,

Setting values: setting certain M0 attribute values to default values,

Notification: Each MO may inform or report its status to the management entity. This can be seen as a trigger or a trap: and

Trend: The trend of the MO is expressed by how the MO reacts to a particular operation and the constraints imposed on this response. MO responds to both external and internal stimuli. The external stimulus is represented by a message indicating the operation. Internal stimuli are internal events that occur in the MO such as the expiration of a timer. Constraints on how the MO should react to expired timers may be imposed by specifying the number of times the timer expires before M0 reports such a fact.

All elements that need to use, manipulate, or monitor a resource need to treat the resource as M0 and access the resource through the aforementioned operations. Relevant elements that need to know the status of a resource need to know how to receive and react to events generated by that resource.

Local and Global Resource Management

The resource management model consists of at least two management hierarchies: partial resource management (LRM) 2190 and global resource management (GRM) 2188. Each resource management has its own domain and function.

2. Partial Resource Management (LRM)

Domain: The domain of partial resource management (LRM) is limited to specific resource pools belonging to specific places in the network. Multiple partial resource management may be in one place, and each partial resource management is responsible for managing a specific resource pool.

Function: An important function of partial resource management (LRM) is to facilitate the process of resource allocation and deallocation between processes and resources, depending on the wife of the resource management model.

3. Global Resource Management (GRM)

Domain: The domain of Global Resource Management (GRM) spans all registered resources in all resource pools spread across the network.

Function: The primary function of Global Resource Management (GRM) is to help Partial Resource Management 2190 to locate resources that are not useful within the LRM domain.

Figure 31 illustrates the GRM and LRM domains in network 2270.

4. Resource Management Model (RMM)

The resource management model (RMM) is based on the concept of dynamic resource allocation against static configuration. The concept of dynamic resource allocation means that there is no predefined static relationship between the resource and the process using the resource. Allocation and de-allocation processes are based on supply and demand. The resource manager 2150 knows the existence of the resource, and the process requiring the resource acquires the resource through the resource manager. Static configuration, on the other hand, means that a predetermined relationship exists between each resource and process. In such cases, the resource management entity does not need to manage the resource. Dynamic resource allocation and static configuration represent two extremes of resource management. Any form of resource management falls between the extremes.

The resource management model describes the trends, logical relationships, and interactions of LRM 2190 and GRM 2188. It also describes rules and policies that govern resource allocation and deallocation between LRM / GRM and processes requiring resources.

a) simple resource management model

To understand that resource allocation and deallocation can be a complex process, a simple form of the process is presented as an introduction to the real model. Simple resource allocation and deallocation are accomplished in six steps. 32 describes these steps.

1. Process 2271 requests resource 2173 from resource manager 2150.

2. Resource manager 2150 allocates resource 2173.

3. The resource manager 2150 assigns the allocated resource to the process.

4. The process interacts with the resource.

5. When the process has finished with the resource, the process informs the resource.

6. Resource 2273 is released back to Resource Manager 2150.

b) Resource management model logical elements

The resource management model is represented by a series of logical elements that interact and cooperate with each other to achieve the aforementioned goals. This element is shown in FIG. 33 and includes a resource pool (RM) 2272, LRM 2190, GRM 2188 and a Resource Management Information Base (RMIB) 2274.

(1) resource pool 2272

All information that is of the same type, has common attributes or provides the same capacity, and is located in the same network location, is logically grouped to form a resource pool (RP). Each RP has its own LRM.

(2) partial resource manager (LRM) 2190

LRM 2190 is the component responsible for managing a specific resource pool 2272. As shown in FIG. 32, a mode process requiring resources from a resource pool managed by LRM should access resources through LRM.

(3) Global Resource Manager (GRM) 2188

GRM 2188 is an entity that has an overview of resource pools on the network. GRM obtains this overall overview through LRM. All LRMs update GRM with RP 2272 status and statistics. Some LRMs may not be able to allocate resources because all local resources are busy or the required resources belong to different places. In such cases, the GRM may consult with the LRM to locate resources required across the network.

(4) Resource Management Information Base (RMIB) 2274

As mentioned above, all resources can be treated like managed objects (MO). RMIB 2274 has all the information about all MOs across the network. The MO information includes object definitions, states, operations, and the like. RMIB is part of the ISP data management model. All LRMs and GRMs have access to the RMIB, have their own overview, and have access to M0 information through the ISP data management model.

5. Component Interaction

In order to carry out their tasks, resource management model elements should interact and cooperate within the rules, policies and guidelines of the resource management model. The paragraph below describes how these entities interact.

a) Entity Interaction Diagram (Figure 33)

In Fig. 33, each rectangle represents one entity, and the vocabulary between < > denotes a relationship between two entities, and square brackets " it means. The number means that the relationship is one-to-one, one-to-many, and many-to-many.

33 is interpreted as follows.

1. One LRM 2190 manages one RP.

2. A plurality of LRM2190 connects to RMIB 2274.

3. A plurality of LRM 2190 connects to GRM 2188.

4. A plurality of GRM 2188 connects to RMIB 2274.

(b) registration and termination of registration;

Resource registration and deregistration apply only to a series of dynamically managed resources. There are some cases where resources are statically allocated. LRM 2190 runs on resource pool 2272 which has a set of resources. In order for an LRM to manage any resource, the resource must inform the LRM about its status and existence. GRM 2188 also needs to be aware of the resource's mobility across the network in order to locate any resource. The following registration and deregistration guidelines should apply to all dynamically managed resources:

All resources must be registered as members of resource pool 2272 specific to their LRM 2190.

If for any reason a resource needs to be stopped or stopped from service, all resources should be deregistered from their LRM 2190.

All resources should report their operating status to LRM 2190.

All LRMs should update GRM 2188 using the latest resource utilization rates based on the resources registered and deregistered.

c) GRM, LRM, and RP interactions

All RP 2272 will be managed by LRM. Each process that requires a particular resource type will be assigned one LRM to facilitate resource access. If a process needs a resource, the process must request it through the assigned LRM. When an LRM receives a request for resources, there can be two cases:

1. When resources can be brought up: In this case, LRM allocates resource members from the pool and passes the resources to the process for processing. The process interacts with the resource until the process is complete. When a process completes its interaction with a resource, depending on the type of resource, the process informs the resource that it is and the resource itself informs the LRM that the resource can be activated, or the process releases the resource and the LRM You can tell a resource that you are no longer using the resource.

2. If resources are not available: In this case, LRM 2190 consults with GRM 2188 about any external resources that have the required resources. If external resources are not available, the LRM informs the requesting process that no resources are available. In this case, the required ProcessTM:

Give up and retry;

· Requiring the LRM to allocate resources when the resources are available, or

If the resource can be made available within a certain time period, then the LRM requires that it be allocated.

If external resources are available, GRM 2188 communicates the location and access information to the LRM. Then LRM is:

Allocate resources for the required process, enable the process to handle the resources (in this case resource allocation via GRM can pass through the process), or

• Encourage the requesting process to contact the LRM that manages the located resources.

d) GRM, LRM and RMIB interaction

It has all the information and status of all managed resources across the RMIB 2274 network. Each LRM 2190 has an overview of RMIB 2274 and is detailed in RP 2272 managed by LRM. GRM, on the other hand, has a complete overview of all resources. This overview consists of all LRM overviews. A full overview of the GRM allows the placement of resources across networks.

In order for RMIB 2274 to maintain accurate resource information, each LRM 2190 must update the RMIB with the latest resource status. This includes adding resources, removing resources, and updating resource status.

Both GRM 2188 and LRM 2190 are accessible through an ISP data management entity and have an overview of the RMIB. The actual management of the RMIB data belongs to the ISP data management entity. GRM and LRM are only responsible for updating the RMIB.

K. Operational Support Model

1. Introduction

Most existing ISP service platforms have evolved independently, each with its own operational support. The time spent learning how to run a given set of platforms increases with the number of platforms. The ISP service platform needs to move to an architecture with a common model for all operational support functions. This requires defining a model that supports current needs and adapts to future changes. This Operational Support Model (OSM) defines a framework for completing management support for ISP 2100.

a) purpose

The purpose of the operational support model is to:

Achieving operational simplicity by integrating a platform for ISP resources,

Reducing the curve for operational personnel by providing a common management infrastructure,

Reducing the cost of the management system by reducing redundant management systems,

Improving market time for ISP services by providing a common management infrastructure for ISP services and network elements, and

To provide a framework for managing ISP physical resources (hardware) and logical resources (software).

b) scope

The described 0SM is provided for distributed management of ISP physical network elements and services running on them. The management framework can be extended to the management of logical resources. However, the architecture presented here is -----------------------------------.

Management services occur within four tiers:

·plan,

· Service management,

A network layer, and

Network element.

The information in the layers falls within four functional areas.

Environment management,

Error management

Resource management, and

· Accounting. The use of a common operational support model for all ISPs enhances the operation of the ISP and simplifies the design of future products and services within the ISP. This operational support architecture is consistent with the ITU Telecommunications Management Network (TMN) standard.

c) definition

Managed Object: A resource monitored and controlled by one or more managed systems. The managed object may be located in the management system and embedded in another managed object. The managed object may be a management or physical resource, and the resource may be represented by one or more managed resources.

Managed System: One or more managed objects.

Administrative subdomain: The administrative domain located entirely within the parent management system.

Management System: An application process within a managed domain that affects the monitoring and control of managed objects and / or subdomains.

Management Information Base (MIB-Management Information Base): The MIB contains information about managed objects.

Management domain: A set of one or more management systems, zero or more managed systems, and a management subdomain.

Network elements: transmission system, switching system, multiplexing, signal terminal, potential processor, mainframe, cluster controller, file server, LAN, WAN, router, bridge, ethernet switch, hub, X.25 A communication network composed of a plurality of types of analog and digital communication equipment such as a link, an SS7 link, and related supporting equipment. When managed, these devices are commonly referred to as network elements.

Domain: A managed environment that can be partitioned in various ways such as function (errors, services .......), geometry and network structure.

Operating system: Management functions are located within the operating system.

2. Operation Support Model

34 shows management layers 2300, 2302, 2304, and 2306 for operational support model 2308 on the network element. Operational Support The Model 2308 supports daily management of the ISP 2100. This model is broken into three. This network consists of layers 2300-2306, functional area within the layer. And activation to provide management services. Managed objects (resources) are monitored, controlled and changed by the management system.

a) functional model

The following paragraphs describe functional areas that occur within management layer 2300-2306.

(1) plan

ISP planning layer 2300 is a repository of data collected about ISP 2100, where additional value is provided to the data:

Configuration management 2312: Setting policies and objectives.

Error management 2314: Average time prediction for errors.

Resource measurement 2316: Forecast of future resources needed (trending, capacity, compliance with service agreements, maintenance agreements, work force).

Accounting: The determination of the cost of providing a service to support pricing of services.

(2) Service Management (SM)

Service ordering, deployment, preparation, service quality agreements, and service quality monitoring are within ISP service management layer 2302. The customer has a limited overview of the SM layer 2302 to control and monitor the service. The SM layer provides a manager to interact with agents in the NLM. The SM layer provides an agent to interact with the managers in the planning layer 230. The manager in the SM layer interacts with other managers in the SM layer. In this case, the manager-agent relationship is equivalent.

Configuration management 2320: Service definition, service activation, customer definition, customer activation, service features, hardware preparation, software preparation, preparation of other data and resources.

Error management 2322: Monitoring and reporting of violations of service agreements. Testing.

Resource management 2324: Predict infringement of service agreements, signal potential resource shortages, and forecast current and future service needs.

Accounting 2326: Processes and delivers accounting information.

Network layer management

ISP Network Layer Management (NLM) Layer 2304 is responsible for managing all network elements as a whole and individually, as shown in Element Management. It is independent of how individual elements provide services internally. NLM layer 2304 provides a manager to interact with agents within EM 2306. NLM layer 2304 also provides an agent to interact with a manager within the SM 2302 layer. Managers in the NLM 2304 layer interact with other managers in the NLM 2304 layer. In this case, the manager-agent relationship is equivalent.

Configuration Management 2328 provides the ability to define local and remote resources and services characteristics from the network wide perspective.

Error Management The 2330 provides the ability to detect, report, isolate, and correct errors in multiple NEs.

Resource Management 2332 provides network-wide measurement, analysis, and reporting of resource utilization from capacity perspectives.

Accounting 2334 extends accounting information from multiple sources.

(3) Element Management (EM)

Element management layer 2306 is responsible for NE 2310 and supports the extraction of functionality provided by the NE. EM layer 2306 provides a manager to interact with agents in the NE. The EM layer also provides an agent to interact with a manager within the NLM 2304 layer. The manager in the EM 2306 layer interacts with other managers in the EM layer. In this case, the manager-agent relationship is equivalent.

Configuration management 2336 provides the ability to define the characteristics of local and remote resources and services.

Error management 2330 provides the ability to detect, report, isolate, and correct errors.

Resource management 2332 provides for the measurement, analysis, and reporting of resource use from capacity perspectives.

Accounting 2334 provides for the measurement and reporting of resource use from an accounting perspective.

(b) NE-Network Element

Computers, processes, VRUs, Internet gateways, and other equipment that provide network capacity are network element 2310. The NE provides an agent to perform operations for element management layer 2306.

(c) information model

35 shows manager agent interactions. Network management is a distributed information application process. This includes the interchange of management information between a series of distributed management application processes to monitor and control the NE 2100. For the purpose of this information exchange, the management process plays the role of manager 2350 or agent 2352. The role of the manager 2350 is to send management operation requests to the agent 2352, to receive the results of its operation, to receive event notifications, and to process the received information. The role of the agent 2352 is to respond to the administrator's request by performing appropriate operations on the managed object, and send a response and a notification to the administrator. One manager 2350 can interact with a plurality of agents 2352, and an agent can interact with one or more managers. Managers can be cascaded in that high level managers act on managed objects through low level managers. In this case, the low-level manager plays the role of both manager and agent.

3. Protocol Model.

a) protocol

The exchange of information between managers and agents relies on a series of communication protocols. TMNs that provide a good model use Common Management Information Service (CMIS) and Common Management Information Protocol (CMIP), as defined in Recommendations X.710 and X.711. It provides a peer-to-peer communication protocol based on the ITU's application common service elements (X.217 description and X.227 protocol description) and remote operating service elements (X.219 description and X.229 protocol description). FTMA is also supported as a higher layer protocol for file transfer. The use of this higher layer protocol is described in Recommendation X.812. The transport protocol is described in Recommendation X.811. Recommendation X.811 also describes the interaction between different lower layer protocols. This series of protocols is referred to as Q3.

b) common context

Sharing information between processes requires a common understanding of the interpretation of the information exchanged. ASN.1 (X.209) in conjunction with BER can be used to develop this common understanding of all PDUs exchanged between management processes (managers / agents).

c) higher layer services

The minimum services required at the TMN CMIS service layer are described below.

Setting: adding, removing or replacing the value of an attribute,

Read: reading the value of an attribute,

Cancel read: cancel a previously read reading

Action: requiring an object to do something,

Create: create an object,

Delete: remove an object, and

Event reporting: Letting network resources declare events.

4. Physical Model

36 shows a physical model of the ISP 2100.

5. Interface Point

The coordinating device 2360 provides a conversion of one information model to an ISP information model. Gateway 2362 is used to connect to the management system outside the ISP. This gateway provides the functionality required for the operation of both ISP compliant and non-compliant systems. This gateway may have a coordination device 2360. 36 identifies nine interface points. The protocol associated with this interface point is:

1. There are two higher layer protocols. Protocol for communication between workstation and ISP upper layer for all other operational support communications. The lower layer is TCP / IP over Ethernet.

2. The upper layer is the protocol for communication with workstation 2364. The lower layer is TCP / IP over Ethernet.

3,4. The upper layer is the protocol for communicating with the upper layer of ISP, and the lower layer is TCP / IP over Ethernet.

5. Proprietary protocols are legacy systems that are incompatible with the supported interfaces. Equipment providing a simple network management protocol is supported by the coordinating device.

6,7,8,9. By nature, gateways support ISP-compliant and non-compliant interfaces. The gateway for planning the internal system may include such as an order entry system or a planning wide TMN system.

ISP realization of operation support model

37 shows realization of operational support.

6. General

The operational support model provides a conceptual framework for the establishment of an operational support system. Fig. 37 represents ISP realization of this conceptual model. In completing this model, all ISP network elements are represented in the operational support system by an agent process acting on management information base (MIB) 2370 and objects in the MIB.

There are two levels of field supported personalities in which the ISP 2100 is managed.

1. For fault tracking, Network Layer Manager 2372 provides an overall description of the ISP for field support. The problem detection, isolation, and troubleshooting process starts there. From that layer, the problem is isolated into one network element. Individual network elements are accessible from the network element manager and allow for more detailed levels of monitoring, control, configuration, and testing. Centralized views of ISPs are not present in today's ISPs, but many recognize their importance.

Network layer manager 2370 provides an ISP wide view for configuration and interacts with network element manager 2374 to consistently configure network elements. This helps to ensure that the ISP's configuration is always consistent across all platforms. Changing information in one place and automatically distributing it across ISP wide is a powerful tool that is not possible with the current ISP management framework.

When a service definition is created by service creation environment 2376, service manager 2378 locates it in the ISP network and allows the network to prepare a new service. The customer for the service is prepared through the service manager. As part of preparing the customer, the service manager anticipates resource usage and determines whether new services need to be added to handle the customer's service usage. It uses current usage statistics as the basis for that decision. Once the customer is activated, the service manager monitors the customer's service usage to determine whether the service is met. As a customer's use of the service increases, service manager 2378 anticipates whether resources need to be added to the ISP network. This service management can be extended to other services with appropriate limitations. Service creation is the story of the IN world, but it requires a service manager integrated with the rest of the system and one of the purposes of this model.

Finally, to plan the personal, the plan manager 2380 analyzes ISP wide resource utilization. Thus, costs are assigned to other services to determine future needs and to determine the cost of services as the basis for pricing for future services.

L. Physical Network Model

1. Introduction

This paragraph describes the physical network issues of the Intelligent Service Platform (ISP).

a) purpose

The physical network model is:

Logical Architecture Mapping;

Information flow; And

• Deploy platform deployment in architecture production environment.

b) scope

This model defines terms related to physical networks, describes the interactions between the various domains, and provides embodiments of the realization of the architecture.

c) goals

The goal of this model is to:

Creating a model to identify the various networks;

• categorizing the information flow;

Providing standard nomenclature;

Providing rules for system deployment; And

To guide the construction of future technology.

2. Information flow

One of the main issues of the IN-Intelligent Network is the flow of information across the various platforms installed in the network. By identifying and classifying the type of information, the network provides for the IN request. In a series of call flows, the customer interacts with IN. Calls can be voice-centric (as in traditional ISP products), multimedia-based (as in Internet MCI users using a web browser), video-based (as in video on demand), or a combination thereof. .

The information can be classified as follows:

·Contents:

Signal: or

·data.

In general, a customer interacting with an IN will require all three types of information flow.

a) content

The content flow contains the most important information that is conveyed. Examples include analog voice, packet switched data, continuous video, and dedicated line call volume. This is the customer's property that IN must deliver with minimum loss, minimum potential and optimal cost. In order for the content to flow in the same channel with different information, the transport network supports more connectivity lines because the IN element is standardized.

b) signal

The signal flow has control information used by the network. ISUP RLT / IMT, TCP / IP domain name lookup, and ISDN Q.931 are all examples of this. IN requests, uses, and generates this information. Signaling information integrates various network platforms and enables intelligent call flow across networks. In fact, for an IN based on SCE, service deployment requires that the signaling information flow across the network.

c) data

The data flow has the information generated by the call flow, including a record of significant billing data generated by the network and some network platform.

3. Terminology

Network: A series of interconnected network elements capable of carrying content, signals, and / or data. MCI's IXC switch network, ISP extended WAN, and Internet backbone are typical examples of networks. Current installations tend to deliver different content on different networks. Each of them is specialized for specific content transfer. Both technology and customer demands require carriers to use a more unified network for most calls. This requires the network to allow over the same channel for other content features and protocols. Another issue of this is the signal independent of the single content.

Site: A series of physical entities located in the same local area. In the current ISP architecture, examples of sites are an operator center, an ISNAP site (having an ARU), an EVS site, and the like. By definition, NT and DSC are not sites. They are a kind of transport network. A group of service engines (SEs), special resources, and data servers that are geographically co-located and along network interfaces and links form the site.

Network element: A physical entity connected to a transport network via a network interface. Examples include ACP, EVS SIP, MTOC, video conferencing reservation server, DAP transaction server, and NAS. Within a few years, a web server, video certificate server, video streamer, and network call record storage will be included in the network element.

Network interface: A device that connects network elements and transport networks. The DSI CSU / DSU, the 10Base Ethernet interface card, and the ACD port are network interfaces. According to the architecture of the preferred embodiment, the network interface provides a single, well understood set of APIs for communication.

Link: A connection of two or more network interfaces at different sites. The link can be part of a 0C-12 SONET fiber or a 100 mbps dual ring FDDI section. In the coming years, IN will handle ISO Ethernet WAN hub links and network links such as 0C-48 at gigabit speeds.

Connection: Connection of two or more network interfaces in the same site.

38 schematically depicts a physical network 2400. Network 2401 having network element 2402 at site 2404 is interconnected through network interface 2406 and one or more gateways 2408.

4. Entity Correlation

The entity correlation shown in FIG. 49 has physical network modeling rules. Some of these rules have been generalized, others have limited definitions to prevent confusion.

1. Network 2401 spans one or more sites 2404 and has one or more network elements.

2. Site 2404 has one or more network elements 2402.

3. Network element 2402 is located at only one site 2404.

4. Link 2420 connects two or more sites 2404.

5. Connection 2422 connects two or more network elements.

6. Network element 2402 has one or more network interfaces.

Preferred embodiments integrate products and service offerings for MCI's office customers. The first embodiment focuses on a limited set of products. The need for an interface has been identified for use in the integration of services. The interface provides the user with functionality, distributed list capacity, and manageability for a centralized message database.

Iii. Intelligent network

Support services for all platforms have been integrated into the platform. The integration of the platform allows the functionality / functionality of the service to create a look and feel of common functionality.

A. Network Management

The architecture is designed for remote monitoring by the MCI Operations Support Group. By this remote monitoring MCI;

Identify broken and broken connections The connection is:

Between platforms, servers, or nodes that convey information (eg objects) to the Universal In Box,

Between platforms, servers, or nodes responsible for retrieving and delivering messages,

Between the universal inbox and the PC client message interface,

Between the universal inbox and the message center interface.

Between platforms, servers, or nodes, where profile information should be passed to the profile,

-Between the platform, server, or nodes that should convey profile information to the ARU.

Identify decomposed application processes and isolate decomposed processes;

• identify hardware errors; And

• Generate alarms that can be detected and received by the MCI monitoring group for any application process, hardware, or interface failure.

In addition, remote access to system architecture components is provided to remote monitoring and support groups, where they perform remote diagnostics to isolate the reason for the problem.

B. Customer Service

The customer service team supports all services. Customer service is provided in a continuous manner and includes a complete product life cycle that includes:

Alpha test;

Beta test;

Commercial identification; And

· Identification of extensions to handling customer feedback or additional customer support needs.

Comprehensive, well-organized support procedures ensure complete customer support from start to finish. Customer service is provided from the time the accounting team submits the order until the customer cancels the accounting. Comprehensive and tidy customer support involves:

One-stop, direct access, customer service group to support ARU or VRU issues, WWW browser issues, or PC client issues;

Connection (VRU, WWW Browser, or PC Client), User Interface (ARU, WWW Browser, or PC Client), Application (APTLW Center or Profile Management), or Back-end System Interface (Universal Inbox, Direct Line MCI Voicemail) Well trained staff in diagnosing problems related to faxmail platforms, fax broadcasting systems, SkyTel paging servers, order entry systems, billing systems, etc .;

ARU or VRU capacity. A staff with online access to a database having information about WWW browser capacity, identified hardware delivery, and identified application delivery;

7 × 24 customer support;

One toll-free number 800 or 888 with direct access to the customer service group;

First, second and third stage support for most failures:

Tier 1 support is support for answering calls. This is expected to solve the most common questions and problems reported by customers. These questions and problems usually deal with connection forms (ARU, WWW browser, PC client), dial-up communications for WWW browser or PC client, installation or basic computer (PC, workstation, terminal) hardware questions. In addition, it opens and updates the trouble ticket and reactivates the customer's password.

Tier 2 support is provided within the customer support group where more experienced technical experts are needed;

Tier 3 support includes external vendors for on-site hardware support for customers or internal MCI engineering or support groups, depending on the nature of the problem.

Level 4 support will continue to be provided by the system engineering programmer.

• establishing a level that provides an acceptable customer with retention time and abandonment rate;

Staff with online access to order entry and billing systems; And

• Weekend reporting details on outgoing calls, average retention time of incoming calls, and open / closed / closed troubleshooting.

C. Accounting

Accounting is supported by current MCI procedures.

D. Delegation

Delegation is supported by current MCI procedures.

E. Report

Reporting is required for revenue tracking, internal and external customer installation / sales, use, and product / service implementation. Weekend and end of month practice reports are required from the practice house. This action report correlates with the number of orders received and the number of orders sent. In addition, the report identifies the number of other subscribers accessing the profile management or message center through the WWW site.

F. Safety

Safety is enforced in accordance with the published policy of the MCI. In addition, security is designed within the WWW browser and ARU interface options to verify and verify user access to direct line MCI profiles, message centers, personal red page calendars, and personal home page configurations.

G. Disability Handling

Problem reports of problems are documented and tracked in a database. All failures are supported in accordance with the Network Service Failure Handling System Guidelines. Any service level agreements defined between MCI organizations are organized to support network service failure handling systems.

Any faults requiring software fixation are connected to the fault reporting database and opened in the form of a problem report (PR) in the problem tracking system. This problem tracking system is used during all test phases and can be accessed by all engineering and support organizations.

Iii. Personal service exchanged

The following terms are used in this description.

Term: express

Server: Both hardware and TCP services.

Web Server: An AIX 4.2 system running Netscape Commercial Server HTTP.

Daemon

Welcome Server

Application Server

The web server, which acts as a welcome server, runs the Netscape commercial server HTTP daemon in both secure and normal mode. Web servers running various application servers run the daemon only in safe mode. Safe mode uses SSLv2.

A. Web Server Architecture

The web server is located in the DMZ. The DMZ stores the web server and necessary related database clients. The database client does not have any data, but provides an interface to the data repository behind the corporate firewall. Webspace uses round robin addressing to derive names. The domain name is registered with the administrator of the mci.com domain with an address space consisting of subnets allocated for the gallileo.mci.com domain.

40 shows a sequence of events leading to a successful login.

1. Welcome Server 450

This web server runs both secure and generic HTTP daemons. An important function of this server is to authenticate the user when logging in. Authentication requires the use of Java and switches for both normal and secure operation. There is one or more welcome servers in the DMZ. The information provided by the welcome server has no state. No state means there is no need to synchronize multiple welcome servers. The first task of the welcome server is to authenticate the user. This requires the use of one use token (TOKEN), passcode authentication, and call style IP filtering. Use of the token TOKEN is done by using token server 454, and passcode authentication, and call-style IP filtering are done by using direct database 456 connections. In the case of failed authentication, a screen (except for call styles) is displayed to the user that states why the attempt failed. This screen automatically sends the user to the initial login screen.

After successful authentication, the final task of the welcome server 450 is to send a service selection screen to the user. The service selection screen directs the user to the appropriate application server. The user selects the application, but the HTML file in the service selection page determines the application server. This allows the welcome server 450 to maintain basic load balancing.

All Welcome Server 450 in the DMZ is mapped to www.galileo.mci.com. The completion of the DNS allows galileo.mci.com to be mapped to www.galileo.mci.com.

2. Token Server 454

This is a database client, not a web server. Token server 454 is used by welcome server 454 to issue tokens to login attempts. Once issued, the issued token is used to track the status information for the connection by the application server. Token information is maintained in a database on the data server 456 behind the corporate firewall.

Token Server 454 performs the following tasks:

1. Issue one usage token during the authentication phase.

2. Validate one usage token (mark it for multiple use).

3. Validate the multi-use token.

4. Re-validate multi-use token.

The token server requires that a unique token be issued for every new connection. This designates a communication link between multiple token servers to avoid confusion of issued token values. This confusion can be eliminated by allocating realms to each token server 454.

The token is 16 characters and it is selected from the group consisting of 62 different characters [0-9, A-Z, a-z]. In each token issued by the token server, the characters at positions 0, 1 and 2 are fixed. These three characters are assigned by each token server during configuration. The character at position 0 is used as the physical position identifier. The character at position 1 identifies the server. The first two positions of the character '0' can be used to identify the token server's version number.

The remaining 13 characters can be generated continuously using the 62 characters described above. At initial startup, the token server allocates the current system's time to positions 15-10 and places the characters 9-3 in '0'. The token value is then increased continuously at positions 15-3. The character code is assumed to be smaller as 'z-a', 'Z-A', and '9-0'.

If the system time is calculated as a 4-byte value, the configuration generates a number of unique tokens corresponding to 62 ^ 6 at positions 15-10. According to another embodiment, the configuration does not generate more than 62 ^ 7 (35 * 10 ^ 12) tokens by a given token server in one second. The use of token domains allows the use of multiple token servers within a domain without surface synchronization. This method accommodates up to 62 sites, each of which can have as many as 62 token servers. Other embodiments may accommodate more sites. All token servers in the DMZ are mapped to token.galileo.mci.com. The first embodiment has two token servers. This token server is physically identical to the welcome server. In other words, the token service daemon runs on the same machine, which runs the HTTP daemon for the welcome service.

The welcome server 450 uses the token server 454 during connection authentication to obtain one use token. Once authenticated, the welcome server 450 indicates that the token is valid and marks it for multiple use. This multi-use token is accompanied by a service selection screen sent to the user by the welcome server. The design of the token database is described in detail below.

3. Application Server

An application server is a web server that handles user transactions. After authentication is successful, the final task of the welcome server is to send a service selection screen to the user. This service selection screen has a new multi-use token.

When the user selects a service, the service request is sent to the appropriate application server with the token embedded. The application server uses the token server to verify the token and, if valid, the service is provided. The token server can authenticate tokens issued by tokens on the same physical site. This is possible because the token server 454 is a database client for data maintained on a single database repository behind a corporate firewall.

Invalid tokens are always delivered on the "access denied" page. This page is provided by Welcome Server 450. All denials of connection attempts are logged.

The actual operation of an application server depends on the application itself. Application servers in the DMZ are mapped to <appName> <num> .galileo.mci.com. Thus, in one embodiment with multiple applications (e.g., profile management, message center, startup card profile, personal web space, etc.), the same welcome and token servers 450 and 454 are used and more application servers are needed. Is added.

Other embodiments provide more servers for the same application. If the load on the application server exceeds its capacity, another application server is added without any system changes. The server and token host database are updated to add records for the new server. The <num> part of the host name is used to identify the application server.

You do not need to use Round Robin for this name. The welcome server 450 uses the configuration table (the server database loaded at startup) to determine the name of the application server before sending the service selection screen.

B. Web Server System Environment

All web servers run the Netscape commercial server HTTP daemon. While the application server only runs the safe mode daemon, the welcome server 450 runs the daemon in normal and safe mode.

The token server runs a TCP service running on a well-known port that is easy to connect from within the DMZ. The Token Service Daemon uses the tcp_bag to deny access to all systems except the welcome server and application server. To speed up this authentication process, instead of using reverse name mapping for all requests, this service loads a list of addresses during configuration. The use of the tcp_bag also provides an additional tool for logging token service activations.

The application server acts as a backend for the database service behind the firewall. The important task is to verify the connection by token and then verify the database request. A database request is to create, update, or delete an existing file or data file for a user. The application server performs the necessary verification and authorization checks before serving the request.

1. Welcome Server

The welcome server serves the HTML page in front of the user at the appropriate time. This page is generated using Common Gateway Interface (CGI) scripts based on Perl. This script resides in a directory other than the HTTP document's normal document-root directory. In order to make the CGI scripter unreadable to the user, precautions should be taken to disable directory listing and remove all backup files. 41 shows directory structure 455 on welcome server 450.

Figure 41 shows that the document-root 456 is separate from the server root 458. It also shows that the <document-root> directory contains only connection errors and welcome HTML pages.

The HTTP server maps all requests to the "cgi" directory 460 based on the required URL. The CGI script uses the HTML template from the "template" directory 462 to generate and send the HTML output to the user.

The use of URLs to map CGI scripts from <document-root> 456 prevents a malicious user from accessing the <document-root> directory 456. Since all connections to the welcome server are mapped to CGI scripts in the welcome server's "cgi" directory, security is ensured by calling the authentication function at the beginning of every script.

The user authentication library is developed in Perl to authenticate user identification. NASPI's acknowledge phase routines add functionality to the service itself for token verification and connection mode detection.

The welcome server 450 enters operational parameter information from their database 456 into their environment at startup. In order to maintain the same environment on multiple welcome servers, it is necessary to store this information in a common database.

a) welcome page

The welcome page is sent to the default page when the welcome server is initially connected. This is the only page not created by the CGI scripter, which is maintained in the <document-root> directory 456. The role of this page is to:

Check whether the browser can display the frame. If the browser cannot display the frame correctly, this page displays the appropriate error message and instructs the user to download Microsoft Internet Explorer V3.0 or later.

Check whether the browser can run Java. If it fails, instruct the user to download Microsoft Internet Explorer V3.0 or later.

If the browser can successfully display the frame and run Java, this page requires the Welcome Server 450 to send the login page automatically.

The third execution by the welcome page is done by the Java Applet built into this page. It also switches the user browser from normal mode to safe mode.

b) login page

The login page is a page generated by cgi, which has one built-in token, a Java applet, and a form field for entering the user ID and passcode. This page can display graphics to highlight the service. The processing of this page may introduce artificial delays. In the first embodiment this delay is zero.

The response from this page contains a token, a mixed token generated by the applet, a user ID, and a passcode. This information is sent by the Java applet to the welcome server using a POST HTTP request. POST requests have an applet signature.

If the login process succeeds, the response to this request is a server selection page. If the login process fails, you will be directed to a connection failure page.

c) server selection page

The login page is a page generated by cgi and has a built-in multi-use token. This page also shows one or more graphics to indicate the types of services that are useful to the user. Some services can't connect to our users. In another embodiment, when more than one service is present, a user service database coordinated by user ID may be used to generate this page.

The welcome server uses this configuration information to embed the name of the appropriate application server for the purpose of splitting the load among all useful application servers. This load division is performed by the configuration data read by the welcome server at the start.

The welcome server selects an application server based on an entry in the configuration file for each service. This entry lists the name of the application server for each application based on the probability to be selected. This preference table is loaded by the welcome server at startup.

d) connection failure page

The connection failure page is a static page. This displays a message indicating that login failed due to an error in the user ID. This page automatically loads the login page after 15 seconds.

e) access denied page

The connection denied page is a static page displaying a message indicating that login failed due to an error in authentication. This page automatically loads the login page after 15 seconds. The access denial page is called by the application server when the authentication service fails to recognize the token. All loads on this page are logged and monitored.

2. Token Server 454

The token service on the website is the only source for token creation and authentication. Tokens are stored by the public database 456. The token database is behind a firewall outside the DMZ.

Token services provide services on well-known TCP ports. This service is only available to trusted hosts. The list of trusted hosts is maintained in the configuration database. This database is maintained behind a firewall outside the DMZ. The token service only reads the configuration database when it receives a signal to refresh at startup. Token service is:

Granting a single use token for a login attempt;

Verifying one use token;

Verifying the tokens; And

· Revalidating tokens, etc.

Token aging is implemented by separate services to reduce the load of token services.

All connections to the token server are logged and monitored. The token service itself is written using the tcp_bag code, which can be run from the MCI's internal security group.

3. Profile Management Application Server

The profile management application server is the only form of application server executed in the first embodiment. This server is in the same directory as the welcome server. This allows the same system to be used to provide both services if necessary.

C. safety

The data deposited by the subscriber to the web server is sensitive to them. They try to protect it if possible. Subscribers access this sensitive information through a web server. This information may physically exist on one or more database servers, but if it is about a subscriber, it is on the server and must be protected.

Currently only the following information needs to be protected in one embodiment.

In another embodiment, profile information for direct line accounting additional information, including email, voicemail, videomail, and personal home page information, is protected.

Protection against the following types of intruders:

• people who access the web;

Another subscriber;

MCI personalnel;

People who access the subscriber's network;

Who has access to the subscriber's system;

• steal subscribers; And

Another system that simulates a server.

The plan for safety is achieved using the following configuration:

One use token for a login attempt;

Verified tokens involve all transactions;

Token aging that invalidates tokens after 10 minutes of inactivity;

Tokens are associated with the IP address of the calling machine. So token theft is not an easy option;

Use of SSL prevents theft of tokens or data without a physical connection to the customer's display;

Use of tokens similar to Netscape Cookies gives you the option to replace cookies later. Cookies provide the convenience of hiding tokens in documents for extra layer of security; And

Use of a ho-style IP table to defend against multiple intruders without being noticed by intruders.

In addition to the security achieved by the tokens mentioned above, the web server is in a data management area (DMZ) for another security. DMZ safety is described below.

D. Login Process

42 shows a login process. The sequence of events that leads to a successful login is:

1. The user requires a connection to www.galileo.mci.com;

2. One server is selected from a series of servers using DNS round robin.

3. The HTML page is sent to the user's browser.

4. The page scans the browser for Java compliance and displays a welcome message.

5. If the browser is not Java compliant, the process stops with an appropriate message.

6. If the browser is Java compliant, it automatically issues a "login screen read" request to the www.galileo.mci.com server. This request turns the browser into SSL v2. This fails if the browser does not comply with SSL.

7. The web server does the following:

A. The web server gets one usage token from its internal token service.

B. The web server selects one from a series of applets.

C. The web server records applets, tokens, and client IP addresses in a database.

D. The web server sends back a login screen with the applet and token.

8. The user enters the user ID and passcode in the login screen fields.

A. The user ID is the user's direct line number (printed on the user's business card and in the public domain).

B. A passcode is a six digit number known only to the user.

9. When the user presses enter (or clicks the login button), the Java applet sends back the user ID, passcode, token, and mixed token. The scrambling algorithm is specified in the applet transmitted in step 7D.

10. If the browser's IP address is in the call style IP table, the server returns to step 7.

11. The web server authenticates the login request against the one recorded in step 7C.

12. If the test is not valid: If this is three consecutive failed attempts at the same IP address, the server records the address in the call style IP address.

13. The server returns to step 7.

14. If the test is valid, the server sends the browser a selection service with a built-in token. The token is associated with the browser's IP address, but it expires now.

E. Service Selection

When the user selects an option from the service selection screen, the request is accompanied by a token. As shown in Figure 43, the token is verified before the service is connected.

F. Service Operation

Every screen created by the application server has a token issued to the user at the start of the login process. This token has a built-in expiration time and a valid source IP address. Every operational request has this token as part of the request.

The service request is sent by the browser in HTML form, applet based form, or Hyper Link form. In the first two examples, the token is sent back in the form of hidden fields using the HTTP-POST method. Hyperlinks use the HTTP-GET method with built-in tokens, or use cookies instead of tokens. The format of the token is carefully chosen to be compatible with this approach.

NIDS Server

In the system, the NIDS server is isolated from the web server by a router-based firewall. The NIDS server runs NIDSCOMM and ASCOM services that allow TCP client access to databases on the NIDS server. NIDSCOMM and ASCOM services do not allow connections to databases that are not physically located on the NIDS server.

The following databases (C-tree services) on the NIDS server are used by the Welcome Server, Token Server, and Profile Management Application Server:

800_PIN-1CALL (this is a partitioned database);

1 CALL_TRANS;

COUNTRY;

COUNTRY-SET;

COUNTRY29 (maybe);

COUNTRY-CITY (maybe);

NPA_CITY;

NPACITY_OA300 (maybe); And

OP153T00.

In addition to the C-tree service, a new C-tree service can be defined in SERVDEF and used only on NIDS servers dedicated to the system.

Token (TOKEN);

Servers;

House style_IP (HOSTILE_IP);

Token_hosts; And

SERVER_ENV.

The description below for this database does not show the filler field required for the first byte of each record, nor does it show the other anonymous fields required for structure alignment along the 4-byte boundary. This omission is for simplicity only. The number in parentheses after the field definition is the number of bytes required to hold the field value.

2. Token Database Service

Token database service is connected by token server. Important functions of this service are to create a new record, read a record for a given token value, and update the record for a given token value.

A separate chron job itself running on NIDS connects to this database and deletes obsolete records. This cron job works every hour. This performs a continuous scan of the database and deletes the record for expired tokens.

The token database service has a token record. Token records use a single key and have the following fields:

1. version (1);

2. using flags (one / multiple) (1);

3. token value 16;

4. IP address 16;

5. User ID 16;

6. time 4 given; And

7. Expired time (4).

The main field is the token value.

3. Server Database Service

The server database service is connected by the welcome server at the time of configuration. This database record has the following fields:

1. Application name 16;

2. Application server host name 32;

3. application server domain name 32;

4. weight 1;

5. application icon file URL 64; And

6. Application Description File URL (64).

The main fields are a combination of application name, server host name, and server domain name. This database is read continuously by the welcome server. This database is accessed by the web administrator to create, read, update, and delete records. This connection is made by the ASCOMM interface. Web administrators use HTML forms and CGI scripts for their administrative tasks.

4. Style_IP Database Service

This database is accessed by the welcome server to create new records or read current records based on IP addresses. This read connection often occurs. This database file has the following fields:

1. IP address 16;

2. input time 4; And

3. Expired time (4).

The main field is the IP address. The above three values are determined by the welcome server when creating a new record. If the entry is overturned, the overturning service is only allowed to change the expired time value to &lt; epoch_start &gt;. Thus signaling the entry to be reversed.

This database is accessed by the web administrator to create, read, update, and delete records. This connection is made by the ASCOMM interface. Web administrators use HTML forms and CGI scripts for their administrative tasks.

Customer service uses specially advanced tools to access this database, and access is only allowed from within corporate firewalls.

A chron job running on NIDS also connects to this database and deletes obsolete records. This cron job logs all its activations. This log is always run by the web administrator.

5. Token_Host Database Service

The Token_Host Database Service lists the IP addresses of hosts that are trusted by the token server. This database is read at configuration time by the token service. The records in this database have the following fields:

1. IP address 16;

2. authority (1);

3. hostname 32;

4. host domain name 32;

5. Host Technology (64).

The main field is the IP address. The privileged binary flag determines the level of access. Low level connections only allow verification / revalidation commands for the current token. Higher-level connections also provide commands to grant and verify a single usage token.

This database is accessed by the web administrator to create, read, update, and delete records. This connection is made by the ASCOMM interface. Web administrators use HTML forms and CGI scripts for their administrative tasks.

6. SERVER_ENV database service

This database service is read at startup by the welcome and application servers. This defines the startup environment for this server. In one embodiment, only one field (and only for the welcome server) is designed to be used. This is extended in other embodiments.

The records that this database has are the following fields:

1. sequence number (4);

2. Application name 16;

3. environment name 32; And

4. Environment value (64).

The main field is the sequence number. Environment values can be referenced to other environment variables by their environment names. This value is evaluated by the CGI script at the appropriate runtime. The welcome server is assigned a fake application name "welcome".

This database is accessed by the web administrator to create, read, update, and delete records. This connection is made by the ASCOMM interface. Web administrators use HTML forms and CGI scripts for their administrative tasks.

7. chron job

The NIDS server runs a cron job. This job is scheduled to run every hour. The main task of this job is to:

1. Scan the homestyle IP database and report the status of all records. This report has all the records. The purpose of tracking down repeated intruders is based on this report.

2. Scan the call style IP database and report the situation for the record with <epoch-time> as the expiration time.

3. Scan the homestyle IP database and delete obsolete records.

4. Scan the token database and report the status of all records. This report format is linked to call volume reporting rather than scanning each entry.

5. Scan the token database and delete obsolete records.

G. Standard

The following coding standards have evolved:

1. HTML look and feel standard;

2. Java Look and Feel Standard (derived from the HTML Look and Feel Standard), which is a new line of libraries used to enforce common look and feel on pages of your site; And

3. HTML Programming Standards.

H. System Management

The system administration task requires the reporting of at least the following system operating parameters to the system administrator:

Time stamped system state and disk usage;

Time stamped network operating parameters;

Time stamped web page usage and access statistics;

Token usage statistics;

Call style_IP alarms and statistics;

The following tools and utilities are on the DMZ server:

Time synchronization;

Domain name servers;

System log monitoring;

Alarm reporting; And

Arsenal cell.

The system generates an alarm for the following situations;

Incorrect use of tokens;

• change the call style_IP table;

Token expiration; And

Attempt to log in.

This alarm will be generated at different levels. The web server uses the following rough guidelines.

The server operates within the root environment.

2. The administrator can start a published server on a non-standard port to test the published (new) service.

3. The server to be published is accessible from the Internet during the startup operation.

4. The administrator has the option to move the publicly available software from the camp to production using a single command. There is an appropriate test to confirm that this did not happen by accident.

I. Product / Expansion

The preferred embodiment allows the direct line MCI customer to have additional control over their profile by providing a graphical user interface and also control over a common message system. The capacity to access the capabilities of the preferred embodiment is in the form of a direct line MCI profile and a common message system. The user can complement his application in updating functionality / activity. This application will enable future capacity provided by the integration of the preferred embodiment.

The user can access all his messages by just connecting with one location. Fax, email, page and voice messages can be accessed via the centralized message interface. To retrieve the message, the user can invoke the centralized messaging interface through the message center interface. The centralized message interface allows the user to manage communications easily and efficiently.

The user interface has two components: the user's application profile and the message center. The interface is accessible via PC software (ie PC client message interface), ARU, VRU, and WWW browser. The interface supports the commercialization of applications and the management of messages.

Functional / functional requirements for the examples are given below. The VRU interface and its uses, namely user interface, message management and profile management, are described first, followed by the WWW browser and PC client interfaces.

J. Interface Function Requirements

The potential acts as an interface between the user and the screen display server. The user can connect to the system and access his profile and messages. The user interface is used to update the profile and access its messages. The user's profile information and the user's message may be in different locations, so the interface must be able to connect both locations. Profiles and message capacities are separate components of the interface and have different requirements.

Through the user interface, the user can update his profile through profile management within runtime. The application profile is at the user accounting directory prefix, where all user accounting information is placed in a virtual location. The user can also manage his messages (voicemail, faxmail, email, pager recall) through his message center. This message center is located in the centralized message database, where all user messages are placed, regardless of the content of the message.

Three user interfaces are supported:

DTMF connection to the ARU or VRU;

WWW browser access to the WWW site; And

PC client access to the message server.

From the ARU, the user updates profiles, retrieves voicemail messages and pager recall messages, and retrieves message header (sender, subject, date / time) information for faxmail and email. Through the PC client, the user is limited to message retrieval and message manipulation. The WWW browser provides the user with a comprehensive interface for profile management and message retrieval. Through the WWW browser, users update their profile (direct line MCI, information service, catalog manager, global message handling, personal home page) and retrieve all types of messages.

1. User Accounting Profile

The user can access the accounting information through the application profile. Application profiles in the user accounting directory provide an intelligent interface between the user and his accounting information. The user accounting directory connects accounting information of individual users. Users can read and write directories to update their accounts. The directory provides a search function that enables a customer service agent to search for a specific accounting when assisting a customer.

When the customer enters a phone number, the user accounting information reflects the registration, and the user can access through his user accounting profile and update the function. If the customer cancels, the user profile directory reflects this information and the service will be removed from the user's application profile.

In summary, the user accounting directory provides accounting information for each of a user's services. However, the user accounting directory is not limited to direct line MCI profiles, information service profiles, global message handling, list management and personal home page profiles. This information determines the functionality / activity of the user's application, is necessary for the user to commercialize his application, and provides the scalability to allow the MCI to meet its ever-changing communication needs.

3. Database of messages

The integration of messages is one of the important functions. Similar or dissimilar messages are combined in one virtual location. With the call the message center provides the user with an overview of his message, regardless of the content or access. Interface messaging capacity allows users to maintain address books and distributed lists.

This message database is a centralized information store and stores messages for the user. The message database provides a common object storage capacity and stores data files as objects. By accessing the message database, the user retrieves voicemail, faxmail, email, pager recall messages, and the like. In addition, by using a common object storage capacity, message distribution is very efficient.

K. Answering Device (ARU) Capacity

1. User Interface

The ARU interface may perform direct line MCI profile management, information service profile management, message retrieval, and message distribution. The DTMF connection provided through the ARU is applied continuously across other components in the system. For example, input of alphabetic characters via a DTMF keypad is done in the same way, regardless of whether the user is connected to broadcasting a fax message in stock quote information or a distribution list.

Automatic voicemail callback redialing provides the ability to prompt and collect callback numbers from guests leaving DTMF voicemail and to automatically send a reply call to the guest's callback number when a message is retrieved. Immediately after completing the callback, the subscriber can return to the original location.

Music On-Hold provides music while the guest waits without hanging up.

Park and Page allows a guest to page through a gateway to a direct line MCI subscriber and provides the option to wait uninterrupted while the subscriber is paged. The subscriber calls his direct line MCI, where he or she can browse the page and choose whether to connect with the waiting guest uninterrupted. If the subscriber fails to connect the call with the guest, the guest receives an option to leave a voicemail. If the subscriber does not have the same voicemail as the defined option, a termination message will be sent to the guest.

Note: Guests can always select the option to leave voicemail while waiting.

Call Screening with Park and Page gives subscribers the ability to respond to guests about Park and Page. This gives the subscriber the ability to choose whether to talk to the guest or leave a voicemail before connecting the call. In particular, when guests select the Park and Page option, they are prompted by the ARU to record their names. When the subscriber responds to the park and page, the ARU prompt will hear "Who did you receive a call from?" And will be offered the option to connect with the caller or send a voicemail. If the subscriber does not have the same voicemail as the defined option, a termination message will be sent to the guest. Guests can always choose the option to leave voicemail while waiting.

Interactive pager preference control and response to park and page

The system also indicates that the subscriber responds to the park and page notification via an order submitted by the two-way pager, by instructing the ARU to route the call to voicemail or final message, or by indicating that the call will continue to be held. Is allowed.

Test Pager Support

The system allows the subscriber to page the direct line MCI subscriber through the gateway and to leave a message retrieved by the text pager. Specifically, when the appropriate option is selected, the guest is sent to the network MCI paging or Skytel message center, where the operator receives and generates a message based on the text retrieved by the subscriber's text pager.

Call forwarding

This system provides an option for the recipient of a telephone to which a direct line MCI call is routed to route the call to the next called number in the direct line MCI routing sequence. In particular, the callee receives a prompt from the direct line MCI ARU gateway. This prompt indicates that the call was routed to the called party's number by direct line MCI, and the option to receive the call to the callee or to route the call to the next destination number (or destination) in routing order. To provide. The options available to the callee are:

An option to accept the call;

An option to send the call to the next called number; And

· Call forwarding to the next called number after time passes (no action required);

Redial # Less Than 2 Seconds

Embodiments provide the ability to redial an outgoing call by pressing the # key for less than two seconds from a direct line MCI gateway. Currently, the direct line MCI requires the subscriber to press the # key for two seconds or longer to redial a call.

L. Message Management

1. Multimedia message notification

The subscriber can receive accounting of the current message through multiple media, including voicemail, faxmail, email, and paging. Specifically, the subscriber can hear the ARU script saying, "You have three new voicemails, two faxmails, and ten new e-mail messages."

2. Multimedia message manipulation

Subscribers are allowed to access the universal inbox through the direct line MCI ARU gateway. This is where subscribers perform basic operations on messages received via multiple media (voicemail, faxmail, email, paging).

Subscribers can search for voicemail manager and pager manager and retrieve message header (priority, sender, subject, date / time, size) information for faxmail and email messages. In addition, the subscriber can store, forward and delete the overview message from the ARU interface. The forwarding function is limited to distributing the message in the form of voicemail or faxmail. Only voicemail messages are delivered as voicemail. Faxmail, email and pager messages are delivered as faxmail. However, email and pager messages need to be converted to G3 format. In addition to forwarding the message by fax, the subscriber can send the message to a distribution list and a fax broadcast list.

3. Text to Speech

The system can convert text messages received as faxmail, email, or pager messages into voice. This voice can be played back through the direct line MCI gateway. Initially, the text-to-speech capacity will be limited to message header (priority, sender, subject, date / time, size) information.

The subscriber is first given the option of choosing which message header to listen to, and then selecting which full message he wants to hear. The only message type that does not support text-to-speech capacity for the entire message is faxmail. In other words, the text-to-speech capacity is supported only for the faxmail head in the faxmail. The faxmail head information includes the sender's ANI, the date / time the faxmail was received and the size of the faxmail.

4. Forwarding email to fax machine

The subscriber may forward the retrieved and opened email through the direct-line MCI ARU gateway to the called party's designated call number. Specifically, the subscriber can open an email message through the direct line MCI ARU gateway. After the message is opened, the subscriber has the option of receiving a prompt asking whether to forward the email to the designated called number, or entering an impromptu number. By selecting this option and indicating the called number, the email message is converted to G3 format and sent to the designated called number. Binary files, email connectors are supported. If the connecting device is not connected to the receiving fax machine, the text message should provide the recipient that the binary connecting device is not delivered. Even if the email is delivered to the fax machine, the message is not deleted from the universal inbox.

5. Pager notification of receiving a message

The subscriber may receive a pager notification at the interval set by the subscriber informing the number of messages currently present in the subscriber's universal inbox by the message media. Specifically, the subscriber may set a notification schedule for receiving a pager message indicating the number of voicemail, faxmail, email, and pager messages currently present in the subscriber's universal inbox through the direct line MCI ARU gateway.

6. Confirm delivery of voicemail

If the voicemail message delivered by the subscriber was not successfully delivered to the destination, the system allows the subscriber to receive a confirmation voice message.

7. Prioritize messages

The system allows the guest to prioritize messages. When a subscriber is accounted for a message, urgent messages are usually indexed before the message. This condition applies only to voicemail and not to faxmail. This is accomplished by Universal Inbox providing proper priority for direct line MCI voicemail.

M. Information Service

Through the ARU interface, a user can receive content from an information service. This can be configured via the WWW browser interface. The information content is provided in the form of inbound service and outbound service. The information content defined through the WWW browser (i.e. profile management) is defined as the inbound information content:

Stock quotes and economic news; And

• Limited to headline news.

The subscriber can also access additional information content via the ARU interface. However, this information cannot be configured through the WWW browser interface (ie profile management). The additional information content is defined as the outbound information content:

Stock quotes and economic news;

Headline news;

·climate;

Sports news and scores;

Home drama update;

Astronomical information;

Lottery results;

Entertainment news; And

· Consists of tourist information.

Environment configuration parameters of the inbound information content are defined below. The retrieval of outbound information content supports entry of alphabetic characters through the DTMF keypad. The input of alphabetic characters should be the same as the alphabetic characters entered through DTMF for list management.

Access to the tourist information is combined with other outbound information services, so the subscriber only needs to dial one 800 / 8XX number. The 800 / 8XX call can be extended to other destinations depending on the information content selected.

N. Message Store Request

The message storage condition matches the message storage request defined below.

O. Profile Management

Direct Line MCI Profile Management

Subscribers can overview, update, and retrieve direct line MCI accounting profiles. The direct line MCI profile management capacity through the ARU interface is consistent with the submission provided through the WWW browser and supports the following requirements:

Create a new direct-line MCI profile and assign a name to it;

Import the direct line MCI profile;

Voice annotates the direct line MCI profile name;

• current straight line MCI profile;

Supports logic based rules for creating and updating direct-line MCI profiles (for example, selecting only one call routing option, such as voicemail, will invoke override routing for voicemail) ;

Enable direct line MCI numbers;

Enable and define override routing numbers;

Enable and define FollowMe routing;

Enable and define final routing (formerly known as alternate routing);

Voicemail and pagers;

-Only voicemail;

-Only pager;

-Final message;

Invoke menu routing if more than one call routing option (FollowMe, voicemail, faxmail, or pager) is available;

Define a default number for fax mail delivery;

Enable paging notification for voicemail;

Enable paging notification for faxmail;

Provide a guest option to categorize voicemails for urgent delivery;

Define call screening parameters for:

-For names and ANI;

-Just for names;

-Only for ANI;

Enable or disable park and page.

P. Call Routing Menu Changes

The system also provides the capacity to modify and supplement the call routing called number without re-entering the number that the subscriber does not want to change from the existing called number. Specifically, if one wants to change any of the routing numbers, the direct line MCI routing handset capacity requires the subscriber to reenter all called numbers. However, this function requires the subscriber to enter only the number he / she wants to change and the # key for the number that he does not want to change.

Q. Bidirectional pager preference control and response to park and page

The system may enable or disable a predefined direct line MCI profile via a command submitted by the bidirectional pager.

R. Personal Greeting

The system allows the subscriber to overview and update the personal greeting that is heard from the ARU or displayed on the personal home page. Each greeting can be commercially available for functions that can be maintained separately and run through each interface (ARU or personal home page).

S. List Management

The system also enables subscribers to create and update lists, and to create voice annotation names for lists. The FAX inventory management capacity is integrated with the direct line MCI inventory management capacity to provide a single catalog database. From the ARU interface, the subscriber can overview, update, add or delete portions of the list. In addition, the subscriber can delete or create a list. The ARU interface can use lists to distribute voicemail and faxmail messages.

Access to a distributed list supports alphabetical list names, so the list is not limited to list code names. The input of alphabetic characters for list names to ARUs via DTMF is the same as the alphabetic characters entered via DTMF for information services. List management requirements are described in detail below.

In addition to providing message handling capacity, the PC client provides access to address books and lists. The user can modify and supplement the address book and administrative distribution lists for voice, fax, email and paging messages. In one embodiment, the list created and maintained via the PC client is not integrated with the list created and maintained via the WWW browser or ARU interface. However, in other embodiments such integration is done. The subscriber can send a message from the PC client to the distribution list. This requires a bi-directional interface between the PC client and the list management database, whereby the PC client passes the scoped or DBF formatted file to the list's database.

The user can create or modify the recipient address information via his interface PC software. The user can record a plurality of types of addresses in his address book, including 10 digits ANI, voice mailbox ID, fax mailbox ID, paging number and email address (MCI mail and the Internet).

T. Global Message Handling

From the ARU interface, the subscriber can define what types of messages can be accessed from the universal inbox. Global message handling requirements are consistent with the requirements defined below.

X. Intelligent Phone and Related Services

So far, the introduction to the Internet has been discussed, so I will describe the Internet phone. But Internet telephony has made progress in only a few areas. Below is a summary of Internet telephony divided into six main areas.

The first area consists of access to Internet telephony services. This area includes satellite, dial-up service, T1, T3, DS3, OC3, and OC12 dedicated lines, SMDS network, ISDN B-channel, multi-rate ISDN, ISDN system combined with multiple B-channels, Ethernet, Token Ring, It includes access to and use of the Internet using mechanisms such as FDDI GSM, LMDS, PCS, cellular networks, frame forwarding, and X.25.

The second area involves sharing internet phones. Multimedia data makes it very easy to use circuit-switched networks because of its high reliability and processing potential. This includes sharing public data, URL data, data conferencing, public whiteboarding, resource collaboration, and ISDN user-user signaling.

The third area deals with routing internet phones. This includes time of day, day of week, date of month, date of year, and geographic location of the signal source, network location of the signal source, time domain of the signal source, and the like. The analysis of routing includes user data, destinations, telephone numbers, source lines, types of delivery services, pre-subscribed function routing, ANI, IP addresses, and the like. VNET plans, zone privileges, directory services, and service control points also belong to routing Internet phones.

The fourth area deals with quality of service. This area should cover the switching network, ISDN, dynamic handset, Internet telephony, RSVP, and nested network services. In addition, this area includes charging for hybrid Internet / telephone switches, Ethernet functions, ISDN functions, analog local loop and public telephones, and reservation and usage services.

The fifth area consists of directory services, profiles, and notifications. Examples are distributed directories, finding-me and follow-me services, directory management of phones, user interfaces, and the like. Caller authentication security is also included. Hierarchical and object-oriented profiles exist along with directory service user profiles, network profile data structures, service profiles, and order entry profiles.

The sixth area consists of hybrid Internet telephony services. This area includes object-oriented messaging, internet telephony messaging, internet conferencing, internet faxing, information routing, voice communications, intranets (such as those in a company), and the like. Other services include operator services, management services, paging services, and billing services. Wireless integration, message broadcasting, monitoring and reporting services, card services, videomail services, compression, authorization, authentication, encoding, telephone application installers, charging, and data collection services.

The seventh service consists of a hybrid Internet media service, which includes an area of cooperative work involving multiple users. Users can collaborate on voice, data and video. This area includes media conferencing within the hybrid network. Broadly speaking, the scheduling mechanism, the conference assisted by the operator, and the introduction of the conference content are related. Meetings in this virtual space will increase in importance in the future. The next generation of chat rooms will feature virtual meeting spaces with simulated office environments.

A. System Environment for Internet Media

1. Hardware

According to a preferred embodiment of the present invention, the system of the present invention can be applied to a personal computer (PC), such as an IBM PS / 2, Apple Macintosh computer, or a UNIX based workstation. An exemplary hardware environment consistent with the preferred embodiment is illustrated in FIG. 1A, which illustrates a typical hardware configuration of workstation 99. This hardware configuration has a plurality of other devices interconnected by a central processing unit (CPU) 10 and a system bus 12 such as a microprocessor. The workstation shown in FIG. 1A is a bus that connects RAM (Random Memory Access) 14, ROM (Read Only Memory) 16, communication networks (e.g., data processing networks), printers, and disk storage devices to the booth. / O adapter 18, user interface 22 for connecting keyboards, mice, speakers, microphones, etc., and / or other user interface devices (not shown) for connecting the touch screen to the booth, and displays for connecting the display devices to the booth Adapter 36 and the like. The workstation has an operating system on top of it, such as the Macintosh Windows NT or Windows / 95 operating system (OS), IBM OS / 2 operating system, Mac system / 7 OS, or UNIX operating system. Those skilled in the art will appreciate that the invention may be practiced on platforms and operating systems in addition to those mentioned above.

2. Object-oriented software tool

Preferred embodiments were written using the Java, C, and C ++ languages, and used object-oriented programming methods. Object-Oriented Programming (OOP) is increasingly used in developing complex applications. As OOP becomes mainstream in software design and development, various software solutions require adaptation to take advantage of OOP. The principles of OOP need to be applied to the messaging interface of an electrical messaging system, so a series of OOP classes and objects for a messaging interface can be provided.

OOP is the process of developing computer software that uses objects to analyze problems, devise systems, and build programs. An object is a software package that simultaneously holds a set of data and related structures and procedures. Because a software package has a set of data and associated structures and procedures at the same time, it is a self-contained component that does not require other additional structures, procedures, or data to perform a particular task. OOP thus makes a computer program appear as a set of huge autonomous components, each of which is called an object to perform a specific task. This concept of tying data, structures, and procedures together into one component or module is called encapsulation.

In general, OOP components are reusable software modules that provide an interface based on the object model and are accessed at run time through the component integration architecture. Component integration architecture is a set of architectural mechanisms that allow software modules in different process spaces to take advantage of different capacities and capabilities. This is usually done by assuming a common component object model that installs the architecture thereon. You need to distinguish between objects and their classes. An object is an example of an object class, which is often called a class. The class of an object can be thought of as a blueprint, from which many objects can be formed.

OOP allows programmers to create objects that are part of other objects. For example, the object representing the piston engine is said to be in component relationship with the object representing the piston. In practice the piston engine comprises a piston, a valve and a plurality of other components. The fact that a piston is an element of a piston engine can be expressed logically and semantically as two objects in the OOP.

OOP also allows the creation of derived objects from other objects. If there are two objects, ie one object representing the piston engine and the other one representing the piston engine made of ceramic, the relationship between the two objects is not a component relationship. Ceramic piston engines do not constitute a piston engine. Rather, it is simply a type of piston engine that the piston is made of ceramic, that is, one more limitation than a piston engine. In such a case, the object representing the ceramic piston engine is called a derived object, which has all the features of the object representing the piston engine, with the addition of another limitation. The object representing the ceramic piston engine is derived from the object representing the piston engine. The relationship between two objects is called inheritance.

When an object or class representing a ceramic piston engine inherits all the features of the object representing the piston engine, it inherits the thermal properties of the standard piston defined in the piston engine. However, the ceramic piston engine object overwrites the thermal properties inherent in the ceramic, which are completely different from those of the metal piston engine. It goes beyond the original and uses new features related to ceramic pistons. Different types of piston engines have different characteristics, but they have the same basic functions (eg number of pistons, ignition sequence, lubricant, etc. in the engine). In order to access each of these functions for each piston engine object, the programmer will identify the same function with the same name, but each type of piston engine can have a different / overwrite function accomplishment after the same name. The ability to hide the achievement of different functions behind the same name is called polymorphism, which greatly simplifies communication between objects. Using the concepts of component relations, summarization, inheritance, and polymorphism, objects can represent everything in the real world. In fact, the logical perception of reality is limited to determining the kinds of objects that can be objects in object-oriented software. Some typical categories are:

Objects can represent physical objects such as cars in traffic flow simulations, electrical components in circuit design programs, countries in economic models, and aircraft in aviation control systems.

Objects can represent elements of a computer-user environment such as windows, menus, or graphical objects.

An object can represent a list, such as a personality file or a table of latitude and longitude of a city.

Objects can represent data types such as time, angle, and complex or point defined planes defined by the user.

Using this huge capacity of objects to represent any logically distinguishable substance, OOP allows software developers to design and complete computer programs that are models of reality (eg, physical entities, processes, systems or components of matter). To be able. Because an object can represent anything, software developers can create objects that can be used as components of large projects in the future.

If 90% of OOP software programs are made from existing reusable objects and consist of proven current components, the remaining 10% of new software projects must be recorded and tested from scratch. Since 90% are from pre-tested reusable objects, the potential domain where errors can occur is 10% of the program. Thus, OOP allows software developers to construct objects from other prebuilt objects.

This process is very similar to a composite machine built from assemblies and subassemblies. Therefore, OOP technology makes software engineering almost identical to hardware engineering in that it builds software from existing components (objects to software). This not only improves the quality of the software, but also increases the speed of development.

Programming languages are beginning to support OOP principles such as summarization, inheritance, polymorphism, and component relationships. With the advent of the C ++ language, a number of commercial software developers have adopted OOP. C ++ is an OOP language that is fast, machine-applicable code. C ++ is also suitable for commercial application and system-programming projects. C ++ is now the hottest choice among OOP programmers, but there are other OOP hosts such as Smalltalk, Common Lisp Object System (CLOS), and Eiffel. Additionally, OOP capacity can be added with more traditional computer programming languages (eg Pascal).

The benefits of object classes can be summarized as follows:

Objects and corresponding classes decompose complex programming problems into a plurality of small, simple objects.

Summarization can communicate with each other through the data organization, forcing data abstraction into small, independent objects. Summarization also allows other objects to interact with the data by invoking the element functions and structures of the object, while preventing data in the object from being inadvertently lost.

Subclassing and inheritance make it possible to extend and modify objects by deriving new kinds of objects from standard classes useful in the system. Therefore a new dose can be created without starting from scratch.

Polymorphism and multiple inheritance allow different programmers to mix and combine the properties of multiple different classes and create specialized objects that can collaborate with related objects in a predictable way. Make it possible.

Class hierarchies and constraint hierarchies provide an extensible mechanism for modeling real-world objects and their relationships.

Libraries of reusable classes are useful in many situations, but there are some limitations. For example:

complexity. In a complex system, the class hierarchy for related classes can be confusing by dozens or hundreds of classes.

Control flow. A program written with the help of a class library is responsible for controlling the flow (that is, controlling the interaction between all objects created from a particular library). The programmer has to decide what function to call and when to make an object.

Nest of effort. Class libraries allow programmers to use and reuse multiple small pieces of code, but each programmer combines them in different ways. Two different programmers can use the same class library to write two programs that are quite different in their internal structure, with hundreds of small decisions. As a result, similar code ends up doing something similar in a slightly different way, and does not work better than working together.

The class library is very flexible. As programs become more complex, more programmers are forced to continue to find basic solutions to basic problems. A relatively new extension of the class library concept is to have a class library framework. The framework consists of a more complex and cooperative set of classes. This class has a small scale pattern and a major mechanism for implementing common needs and ideas within specific domains. The framework was developed to free application programmers from the chores of displaying menus, windows, dialog boxes, and other standard user interface elements for personal computers.

The framework also changed the way we think about the interaction between code written by programmers and code written by other programmers. In the early stages of procedural programming, the programmer required a library provided by the operating system to perform some task, but basically the program ran from beginning to end of the page, and the programmer was solely responsible for controlling the flow. I am responsible. This is appropriate for solving problems with salaries, calculations, and programs that run in only one direction.

Development of graphical user interfaces has begun to reverse this procedural programming arrangement. This interface, not the program logic, allows the user to derive a program and determine when and what execution should be performed. Most personal computer software today accomplishes this by an event loop that controls the source of the mouse, keyboard, and other external events, and calls the appropriate programmer's code as the user executes it. The programmer no longer decides the order in which the events occur. On the other hand, the program is divided into separate pieces that are called at random and irregularly. By yielding control to the user in the manner described above, the developer can create a program that is easy to use. Nevertheless, individual pieces of a program written by a developer call a library provided by the operating system to perform a certain task, and the programmer must programmer within each piece after it is called by an event loop. Determines the control of the flow. The application code is located on top of the system.

An event loop program calls the programmer to write multiple pieces of code that do not need to be written individually for every application. The concept of an application framework extends the concept of mapping loops further. Instead of handling all the nuts and bolts that make up the main menus, windows, and dialog boxes, and making them all work together, programmers using application frameworks work properly with application code and basic user interface elements. Start by letting it go. And they build from there by replacing some general capacity framework with a specific capacity of the intended application.

The application framework reduces the overall amount of code that the programmer must write from scratch. However, because the framework displays windows, supports copying and pasting windows, and other common applications, programmers can yield more control than a mapping loop allows. Framework code manages almost all mappings, control of flow, and programmer's code is called when the framework needs it (eg, creating or manipulating data).

The programmer writing the framework program not only gives control to the user, but also gives control of the detailed flow in the network within the framework. This approach allows control of a more complex system of co-operation, as opposed to an isolated program where custom code is generated repeatedly for similar problems.

Thus, as mentioned above, a framework is basically a set of cooperating classes consisting of a reusable design solution for a given problem domain. Frameworks typically provide objects that define default behaviors, and programmers use the framework by inheriting some of the default behaviors and overriding other behaviors to invoke application code at the appropriate time.

There are three important differences between frameworks and class libraries:

1. Function vs. Protocol.

The class library is basically a set of functions that can be called when you need these individual functions in your program. The framework, on the other hand, contains not only functionality but also rules about what the programmer expects to provide against what the protocol or framework provides, and provides a set of rules that control how features can be combined.

2. Call vs. Overwrite.

In a class library, code written by a programmer demonstrates an object and calls the function of that element. It is possible to demonstrate and call objects in the same way as the framework (ie, to treat the framework as a class library), but in order to take full advantage of the reusable design of the framework, the programmer is called by the framework. Write code that overwrites. The framework manages the flow of control between the objects. Writing a program involves assigning responsibilities to the various pieces of software called by the framework, rather than specifying how the different pieces should cooperate with each other.

3. Implementation versus design

In the class library, the programmer only reuses execution, but in the framework, reuses the design. The framework implements a family of related programs and how a piece of software works. This provides a generic design solution that can be applied to solve various specific problems within a given domain. For example, although two different user interfaces created in the same framework can solve quite different interface problems, a single framework can implement how the user interface works.

B. Telephone over the Internet

Voice over the Internet has become a cheap necessity for hobbyists. Some companies have evolved this technology to include interacting with the PSTN. This provides both challenges and opportunities for established carriers such as MCI and BT, particularly in the IDDD field. This discussion examines how carrier class services can be provided based on the advanced technology. Of particular interest is the possibility of interacting between the PSTN and the Internet using 1 plus dialing.

Preliminary discussion takes into account the technical needs to support the connection of PC to PC and PSTN to Internet voice gateways. Also consider how the call is forwarded from the PC to the PSTN and vice versa. In addition, the case of PSTN to PSTN communication using the Internet as a long distance network is investigated.

It complements existing PSTN services and shows how services can be provided that offer lower prices for lower quality of service. In the long run, the issue is whether the continuous improvement of the quality of Internet telephony and its improvement can compete with traditional voice services.

1. Introduction

In the mid-1970s, experiments on voice transmission over the Internet were conducted as part of a research program sponsored by the US Defense Advanced Research Project Agency (DARPA). In the mid-1980s, workstations based on UNIX were used to conduct general voice / video conferencing sessions. In the late 1980s, this experiment was larger and extended to unidirectional multicasting of audio and video. In 1995, a small company (VocalTec) (www.vocaltec.com) introduced a low-cost software package that can provide two-way voice communications between multimedia PCs connected to the Internet. The result is a new chapter in telephone calls on the Internet.

The first software packages and intermediate follow-up packages provided tools for hobbyists. Meeting locations based on Internet relay chat rooms were used to establish end-to-end point-to-point connections for voice transmission. This caused accidental meetings, as often happens in chat rooms, or caused predetermined meetings if the party had previously coordinated by email or other means.

a) how it works

A user with a multimedia PC and an internet connection can have internet telephony capacity by loading a small software package. For Vocaltec, the package connects to the conference venue (IRC server) based on the modified chat server. In IRC, users see a list of other users connected to the IRC.

The user calls another user by clicking on his name. The IRC sends the callee's IP address in response. For dial-in users on the Internet, an IP address is assigned at dial-in time, resulting in a change between dial-in sessions. If the destination does not have a voice connection yet, the PC will ring. The called user responds to the call through a mouse click, and the caller starts sending the call directly to the callee's IP address. Multimedia microphones and speakers installed in or coupled to a PC are used as speakerphones. The speaker's voice is digitized, compressed and packetized for transmission over the Internet. On the other side it is decompressed and converted to voice through the PC's speakers.

b) relationships

Calls on the Internet provide users with low cost, regardless of distance or border. At the current cost of Internet connection (low price per hour, or flat rate), the caller can have a voice conversation with another PC user connected to the Internet. The callee pays for the conversation by paying for his Internet connection. If either or both ends are LANs connected to the Internet by leased lines, the call is exempt from additional costs. All of this contrasts with traditional long distances, perhaps international currencies.

c) quality of service

Sound quality through the Internet is good, but not as good as traditional phone calls. In addition, there is a significant delay during the conversation. Attempts to suspend the speaker can cause problems. Changes in delay and quality are a result of distance and available capacity and are also related to the function of compression, buffering and packetizing time. The delay in voice transmission is due to several factors. One of the most important factors is the sound card used. The first sound card was a half duplex and was designed for the reproduction of recorded voices. Long voice data buffers that help ensure uninterrupted voice playback led to real-time delays. As full-duplex cards designed for speakerphone applications become available, delays based on sound cards are decreasing.

Other delays are due to the connection line speed (14.4-28.8 Kbps for dial-up Internet access) and packet delivery delays within the Internet. It also comes from filling in digitized and coded voice packets. For example, to fill a packet with 90 ms of digitized voice, the application must wait at least 90 ms to receive voice for digitization. Shorter packets reduce packet-filling time, but increase overhead by increasing the ratio of packet headers to packet payload data. The increased overhead increases the bandwidth demands on the application. Therefore, applications that use short packets will not work for 14.4 Kbps dial-up connections. PCs based on LANs experience less delay, but everyone is subject to various delays that are cumbersome.

Finally, there is a delay due to the voice codec. Codec delays vary from 5 to 30 ms in encoding or decoding. Despite the longer wait times associated with Internet telephony, prices are fair, and this type of voice communication is becoming increasingly popular.

2. IP Phones for Commercial Services

IP telephone technology exists regardless of whether traditional telephone systems like it or dislike it. Using the Internet to make international voice calls is a potential threat to the traditional international long-distance telephone (IDDD) revenue stream. After a few years, even if there is a significant income impact, it cannot be abandoned except within the boundaries of a regulatory-based country. The best defense by traditional telephone systems is to provide these services in a powerful way on their own. In order to do so, an advanced call installation facility and an interface to the PSTN are required.

Promoting a PC-to-PC connection is very useful when concurrently performing Internet data packet communication and voice conversation without having to access separate telephone facilities. Dial-up Internet subscribers with only one access line may face such a situation. Cost considerations also stimulate the use of PC-to-PC phones. The use of this technology will increase significantly when the Internet can be used in place of long distance networks to interconnect regular telephones. The number of PCs connected to the multimedia Internet in the world (estimated at 10 million) is small compared to the number of subscriber lines (estimated at 6.6 billion). This service is being planned by several companies.

Each endpoint combination is described in the following paragraphs. The most important issue is related to the connection of the PSTN and the Internet gateway. Of particular interest is to allow the PSTN caller to make one-step dialing of the called party. The one-step dialing solution described below is within the context of the North American numbering plan. There are basically four cases:

1. PC to PC;

2. PC to PSTN;

3. PSTN to PC; And

4. PSTN to PSTN.

In the first case it is addressed by today's IP phone software. The second and third are similar but not equal, each requiring a gateway between the PS and the Internet. The last case uses the Internet as a long-distance network for two PSTN phones.

a) PC to PC

(1) directory services

To facilitate PC-to-PC Internet calling, a directory service is needed that finds the IP address of the called party based on the name provided by the caller. Early Internet telephony software provided a modified Internet chat server as a meeting place. Recently, Internet telephony software has replaced the chat server with a directory service that specifically identifies (possibly by email address) Internet telephony users. To receive the call, the customer registers with the directory service and tells the directory system their location (IP address) when they connect to the Internet or want to answer the call. The best way for automatic notification is for the IP phone software vendor to agree on a protocol that notifies the directory service when the software starts. Optionally, it would be desirable to find a way to automatically invoke IP telephony software when the IP stack starts up.

Directory services are planned as an Internet domain name system and a few distributed systems for scalability. This does not mean the user@foo.com format for user identification.

In theory, only the called party needs to be registered. If the caller is not registered, a charge for the call may be charged to the called party (collect call). On the contrary, we can argue that the caller should also be registered in the directory and charged through this mechanism (this is desirable because we avoid the complexity of charging for registration and requiring a collect call). Charges for call setup, rather than call continuity, are more than normal Internet charges. Charges for ongoing calls are pre-applied to dial-up Internet users, and Internet charges for dial-up and dedicated use will not be far away.

Collect calls from registered users may be needed to meet market needs. In addition to the mechanism for determining whether the called party will accept or reject the collect call, a configuration must also be devised to identify such a call to the called party. Directory Services will track the ability of the called software to support this functionality by version number. In the case of a collect call (assuming the caller is unregistered), the caller can be anyone he chooses. The directory service requires the caller to be a temporarily "assigned" subject to know that the caller is an unauthenticated caller. The IP address does not necessarily need to be fixed, so you cannot rely on it to identify the other party.

(2) interoperability

Almost all IP telephony software packages in circulation today use different voice encodings and protocols to exchange voice information. To facilitate a useful connection, the directory should store the type and version of the Internet telephony software used. To do this effectively, the software vendor will automatically report this information to the directory service. This information can be used to determine interoperability when there is a call. If the parties are not interoperable, an appropriate message should be sent to the caller. Alternatively, or in addition to registration in the form of software, it may be designed to determine interoperability during negotiation protocols, but all packages should say that.

There is a question as to whether the conversion between IP phone encodings can be performed to an acceptable end user. Such a service may have a duration and / or a volume fee associated with it, and may limit its use. Also, after the improvement period, only a few configurations remain, and perhaps they can be expected to have interoperability through the least common denominator compression and signaling protocol. All IP telephony software vendors we have contacted so far prefer Esperanto, which allows for interoperability. If this happens, the life of the conversion service will be shortened and creating it will not be economically attractive.

We can help major software vendors seek a match for "common" compression schemes and signaling protocols that provide the necessary interoperability. If a major vendor supports this method, other vendors will follow. This is already happening with recent declarations that Intel, Microsoft, Netscape and Bocaltech are supporting the H.323 standard next month. This can be checked automatically at call setup. Directory Services remembers which versions of which software can interoperate. To facilitate this functionality, automatic notification of existence includes the current software version. This type of upgrade is dynamically recorded in the directory service. Several configurations must be defined to allow registration information to pass between software packages, so that if a user replaces a package, the registration information can be moved to a new application. There is no reason to oppose a user having two applications with the same properties. The directory service will know what the user is doing as part of the automatic attendance notification. This causes problems only if the user can operate more than one IP telephony package at the same time. If the market demands this ability. Directory services can be backed up to handle this. The problem can also be overcome by using a negotiation method between interacting IP telephony software packages.

(3) Call Progress Signaling

If the user can reach using the directory system but is currently using a voice connection, a call waiting message (along with the caller ID, something that cannot be used for PSTN calls) is sent to the called party, and the corresponding message is sent to the caller. Is returned. If the user can be reached using the directory system but is not currently running voice software (the IP address responds, but is not an application), an appropriate message is sent to the caller. (Optional, an e-mail can be sent to the callee to alert the call attempt. An additional option is to allow the caller to enter a voice message and attach the voice mail to the e-mail. It may signal to indicate that it is unreachable, such as in operation, ignoring call waiting, etc. Other notification methods may be provided for the called party, such as fax or paging, etc. In each case, the notification may be provided by the caller's entity. May be included if known.)

Once the directory system is distributed, it is necessary to request another copy if no contact is made based on local information. The system can have various types of notifications and can control these types of parameters.

(4) party identification

An important question is how the directory system knows this if the callee was not at the last reported place (they disappeared somewhere). The party dialing in can leave the network in a variety of ways (such as by disconnecting a dialed line, turning off a PC, or crashing a terminal server) without informing the directory service of a change in status. I can go out. Worse, some users leave the network, and other users with voice applications can be assigned the same IP address. (If the new user is a registered user with automatic attendance notification, there is no problem because the directory service can find duplicate IP addresses. There may be some timing issues in the distributed part of the directory service.) Therefore, there must be some configuration that can determine if the directory service is still where the customer last reported.

One approach to this is to enforce a shared secret with the application at registration. When the directory system is contacted by software (automatic attendance notification or call initiation), or when the directory system attempts to contact the callee at a recently known location, it sends a challenge (such as a chat) to the application and , Prove the response. Such a construct removes the requirement of the declaration "I am not here now" or removes the obsolete retention of the message. The customer can turn off or disconnect his IP phone application at any time without worrying about notifications to the directory system. If multiple IP telephony applications are supported by the directory system, then each may have a different challenge.

(5) other services

Coded Internet telephony conversations require consensus from software vendors to minimize the number of encoding mechanisms. This is another interoperability solution for directory systems. Directory services can provide support for major public applications and provide public key certificates issued by appropriate certification authorities.

The user can specify to the directory service that his PC should be dialed out if the PC is not currently online. Charges for dialing out are charged to the called party as incurred in POTS for call forwarding. A call detail record (CDR) for dialing out is required to be associated with a call item of an entity (called party) in an IP telephone system. Note that this differs from the PC to PSTN case in that it does not require conversion of coded speech to PCM. In fact, dial out uses TCP / IP over PPP. If the dial out fails, the appropriate message is returned.

The dial out can be domestic or international. In international cases it is not practical because of cost. However, there is no reason to exclude this case, and no additional functionality is required to do this.

b) PC to PSTN

PSTN-to-Internet gateways are required to convert PCMs into multiple encoding schemes to interact with software provided by various vendors. A common compression scheme can be used if it is mounted. If possible, the best configuration in terms of quality should be used. In many cases, it is a proprietary version of the vendor. To achieve that, telco needs to license technology from selected vendors. Some vendors will do the work necessary to make their configurations work on the telco platform.

(1) Domestic PSTN Destinations

The PC caller needs to be registered to call the PSTN. The only exception to this is when collect calls are allowed from the Internet. This adds complexity to the charge. To call the PSTN destination, the PC caller specifies a domestic E.164 address. The directory system maps the address to an Internet dial out device based on NPA-MXX. It is expected that the dial-out device is close to the destination and therefore will be a local call. However, the first problem is how to handle this if there is no local dial out device. Another problem is how to handle this if the local dial out device is full or cannot be activated. There are three approaches to this. The first approach is to provide a dial out service only if local calls are possible. The second approach is to inform the caller that a long distance call should be placed and ask whether the caller will be allowed to incur this cost. The third approach is to place the call irrespective of it and without any notification. Each approach requires a method of correlating the cost of a dial out call (PSTN CDR) with the billing record of the call originator (via the directory service).

The third approach adds customer support loads and can lead to unhappy customers. The first approach is simple but limited. Most users are very cost conscious, so the first approach can be satisfactory. The second approach can provide scalability for placing calls at any cost, but can introduce operational complexity. A possible compromise is to use the first approach, so the call is rejected for local dial out. We can also add attachments to calls that do not care if the call results in a long distance call. In such a case, even if the call was originally rejected by a caller, even if the call resulted in a long-distance call, the second set could be attempted using the subset if it does not care. For customers with limited budget, all PSTN calls can be made with a subset.

Positioning domestic PSTN calls supports international call requests for Internet calls originating from Internet locations outside the United States.

(2) International PSTN Destinations

There are two ways to make a call to an international PSTN. The first is that international calls are located from domestic dial out stations. This is not a fascinating way because customers are not saving money than making international phone calls on their own. The second is that the Internet forwards the call to the destination country, and local dial out is done there. This can be a problem because there must be agreement by the carrier at the international destination. This can be survived by two options: The first option is to use a local carrier in the destination country as a partner. The second option is to use an Internet service provider at the destination or some other service provider connected to the Internet.

c) PSTN to PC

In this case, some applications are provided for its completion, but its interest is low.

As shown in the PC-to-PSTN case, the PSTN-to-Internet gateway needs to support the conversion of PCM into a multi-coded configuration by interacting with software from various vendors. The directory system is required to identify the called PC. Automatic attendance notification is important in keeping the called party reachable. The PSTN caller does not need to register with the directory service because caller charges are made based on the PSTN information. The caller is always constant and has an E.164 address that can be used to charge and send back a call. Perhaps we can pass the call number to the callee to indicate who is calling. Call numbers may not always be available due to technical or personal privacy. It is possible to indicate to the PC software that a PSTN call has arrived and provide an E.164 number or that it cannot be activated. The service is based on charging a call phone. This can be done as if the Internet is part of a long distance call. This is possible by using a second dial tone. If 800 or local dial service is used, it is necessary for the caller to enter billing information. On the other hand, the 900 service will enable charging based on the PSTN caller. In either case, the caller needs to specify the destination phone number after the billing information or after dialing the 900 number.

The main issue disclosed is how the caller specifies the destination to the second dial tone. Touch tones work best. To simplify the entry, we can send an E.164 address to each directory entry. In order to avoid confusion with actual telephone numbers (PSTN to PSTN), the numbers are required to be under directory control. If you have enough capacity, the 700 number can be used. Alternatively, specific area codes can be used. Spelling using touch tone pads (PADs) is a less familiar approach.

3. Phone number on the Internet

The best approach is to assign a region code. This not only keeps future options open, but also allows for simpler dialing from scratch. Given a reasonable area code, the PSTN caller can directly dial the E.164 address of a PC on the Internet. The telephone system can route the call to the MCI POP, from which it can be routed back to the PSTN-to-Internet voice gateway. The called number can be used to place the call on the PC if the PC is online and reachable. This allows the PSTN caller to regard the Internet as if it is part of the PSTN and dial. It is not necessary to enter the second dial tone and billing information. The charge for the call is charged to the calling PSTN station, and the charge is incurred only if the destination PC answers. Other carriers will be assigned specific area codes, and directories must be compatible.

For calls originating from within the country, all the billing information needed to be charged to the caller can be obtained, and the intelligent network service function or other billing method for the third party can be activated via a second dial tone.

4. Other internet phone carrier

All of this becomes more complicated when number portability is required. It may be desirable to assign a country code to the Internet. This may complicate domestic dialing (dialing other than 1 + 10 numbers can greatly reduce the use of the service), but it has several desirable advantages. In any case, the assignment of area codes and the assignment of country codes are not mutually exclusive. The use of country codes makes dialing geographically a single standard.

5. International access

Making international calls to the United States to enter the Internet in the United States seems unlikely. However, if this happens, the system will have enough information to charge the caller based without adding any functionality.

Another possibility is to install (as a partner relationship) entry to the Internet in that country to handle incoming calls outside the United States and to return to the United States or any other country on the Internet. If the partner is a local carrier, the partner will have the necessary information to charge the STN caller.

a) collect call

The collect call from the PSTN to the PC takes several steps. The first step requires that the call from the PSTN to the Internet gateway be a collect call. This collect call is signaled in the same way as a PC to PC. It may be necessary to indicate that the caller is based on the PSTN and possibly include the calling E.164 address.

b) PSTN to PSTN

The choice of voice compression and protocol configuration for delivering voice between the PSTN and the Internet gateway is entirely under the control of the carrier. Different levels of service can be provided by varying the level of compression provided. Different fees may apply for each level. The caller may select a quality level, perhaps by dialing another 800 number service in advance.

In making a call over the Internet, neither the caller nor the callee need to register with the directory service. The caller dials the PSTN-to-Internet gateway, receives a second dial tone, and uses touchtone to specify the billing information and the destination domestic E.164 address. 900 services can also be used. The directory service (which may be a separate system, but the directory service had previously mapped a function to handle PC-to-PSTN dial-out cases) maps the call to an out dialer to provide local calls if possible. There is a charge to the caller, and the call specification of the out dial call needs to be related to the call specification of the inbound caller.

The question is how to treat the dial-out device closest to the called number, as in the case of the PC-to-PSTN above, if it causes a long distance or long distance call. The present situation is different in that the notification must be made by voice and authentication for making long distance or long distance call dial out must be done by touch tone. In case of long distance dial out, the internet can all be omitted and the call can go entirely onto the PSTN. In this case, it is not clear whether using the Internet is economical.

(2) one-step dialing

The problem is that the destination PSTN number needs to be entered and it should be indicated that the destination should arrive via the Internet instead of the traditional long distance network.

This selection criterion can be conveyed by any of the following methods:

1. Assign a new 10XXX number that is the internet of carriers.

2. Sign up.

The first method allows the carrier to select the Internet as a long distance carrier. The second method makes the Internet the default long distance network. In the second case, the customer can go back to the carrier's traditional long distance network by dialing the 10XXX code.

The first method has the drawback that the caller must dial five extra digits. Although many people do this to save money, requiring extra dialing will reduce the number of users of this service. The second method does not need to dial extra digits, but requires the subscriber's promise to use the Internet mostly for long distance networks. Therefore, the choice of service quality and price is the determining factor.

In the PSTN to PSTN case, it is possible to consider providing different classes of service at different prices. This class is based on the combination of coding scheme and the amount of compression (bandwidth) applied, and low cost will be required for low bandwidth usage.

In order to preferably indicate a class of service, three 10XXX codes may be used. By subscription, certain classes can be pre-arranged and other service classes can be selected by the 10XXX code.

(3) quality of service

Quality of service can be measured by two main factors. The first is sound quality, the ability to recognize the caller's voice, and the second is a delay that does not exist in the PSTN.

In the first view, we can say that most of the offerings available today provide acceptable sound quality. But the delay is different. PC-to-PC users experience delays of 0.5 to 2 seconds. As mentioned above (introduction), most of the delay is due to the sound card and the slow dial connection. In the PSTN to PSTN service, both factors may be removed.

In the case of the PSTN-to-Internet gateway, the use of DSPs greatly reduces compression and protocol processing time. The connection to the gateway is 64 kbps on the PSTN side and almost ethernet on the Internet side. Because the gateway is usually located near the backbone, routers on the Ethernet are connected to the backbone by the T3 line. This combination will provide a service with very low delay. Some buffering may be necessary to eliminate the various delays in the backbone, thereby keeping them in the domestic carrier backbone with delays of 0.25 seconds or less.

Quality of service is differentiated by speech recognition related to bandwidth usage. In order to guarantee a lower delay deviation if necessary, the proposed IETF Resource ReSerVation setup Protocol can be used, but the complexity by the addition of RSVP should be solved. There is also a problem with the scalability of RSVP for large scale internet telephony.

(4) cost

One question is whether it is practically more economical to use the Internet instead of a switched telephone network for long distance voice transmission. It is priced that way now, but does the current price represent real costs? Routers are certainly cheaper than phone lines. And the 10 kbps (essentially half-duplex) used by IP software is less than the dedicated 128 kbps of a full duplex 64 kbps DSO. Despite this comparison, the question still exists.

Although routers are much cheaper than telephone lines, routers have much less capacity. Building large networks using small building blocks is expensive and quickly reaches its peak. We have seen that the Internet backbone is overloaded by end routers, and they will still have to experience the significant increase in call volume that successful Internet telephony offerings bring. Here we can talk two things.

1. The current Internet backbone does not seem to support the major increase in call volume associated with successful Internet telephony services. We need to wait for the router technology to improve.

2. The second issue is about the use of bandwidth. The 10 kbps half-duplex (slightly more if both parties speak at the same time, but much less for silence) is considerably less than the dedicated capacity of the 64 kbps full-duplex. Two points of view are noted in this debate.

First, the bandwidth is cheap when there is spare fiber. If the last strand is used, then the next bit / second becomes very expensive. Secondly, in maritime telecommunications routing where bandwidth is very expensive, we are already compressing voice bandwidth to 9.6 kbps. This is essentially the same for Internet calls of 10 kbps. How can IP capacity be much cheaper than POTS? The answer is that price differences are partly related to the Internet's supporting history. There is one process underway by the Internet backbone provider that addresses the cost issues of the Internet. The essence of this process is the perception that the Internet requires a fee. These charges already apply to dial-up users, but do not normally apply to users with dedicated connections.

If a PC-to-PC Internet phone is successful, users will want to keep their PCs connected for a long time. This will make them suitable for receiving calls. It will also increase the retention time of the dial at the port. This will have a significant impact on the financial and recurring costs of the Internet.

(5) fee

The directory service should provide the above functions and collect enough information to charge for the service. Fees may be charged for directory services, registration (subscription fee + basic monthly fee), call setup, etc., but not for call duration. Call continuity is charged in advance to Internet dial-in users and integrated to LAN-coupled users. Usage fees for Internet services will be charged in the near term. Call persistence rates may be available for incoming or outgoing PSTN segments.

Incoming PSTN calls may be charged to long distance segments by using the specified area code. Other direct billing options include 900 calling and calling card (or credit card) billing options.

The requirement that all callers be registered with the directory service will eliminate the immediate need for a collect call. This is not a big obstacle because most users of IP telephony services will want both incoming and outgoing calls. The caller may have an entry that is not in the list, such as an entry with an E.164 address, but the name does not. The caller given the E.164 address can call the other party (as in the PSTN or PC) as in the current telephone system.

Different levels of compression may be used to provide different quality of speech reproduction, and some Internet traversal resources may be used simultaneously. For PC-to-PC connections, software packages at both ends can negotiate the bandwidth used. This negotiation can be facilitated through directory services.

(6) technical issues

It is necessary to coordinate the IP phone vendor to fulfill registration, automatic attendance notification and attestation capacity. We need to add the ability to deliver service requests. This includes authorizing the collect call to make a dial out call to the PSTN even at long distances and specifying something else to be determined.

Registration with the directory is an essential feature described below. The DNS model for distributed directory services seems to facilitate this feature request. Assigning a virtual E.164 number to a directory will work best if the actual area code is used. If each carrier has one area code, this will make the interaction between the directory systems much easier. Clearly, complexity is added if number portability is required.

IP telephony consistent with the preferred embodiment will continue to be in use at least in the near future. This technology-based combination of carrier-level services and growth in router capacity will make the Internet a significant part of long-distance calls.

In homes such as cable modems, faster Internet access makes it easier to obtain quality IP telephone service. The addition of video doubles the need for the service.

Fax services over the Internet are of interest. This is similar to the voice service mentioned above. The debate over the fax protocol makes fax services a more difficult offering. Meetings on the Internet using digital bridges make voice and video services more attractive. This can be done by using multicasting technology developed in the Internet world. By using multicasting, the cost of providing such a service will be reduced.

C. Internet Phone Service

1C is a schematic diagram of an Internet telephone system in accordance with the preferred embodiment. Processing begins when the telephone 200 is used to initiate a call by the other party dialing and answering the telephone number. The telephone 200 is typically connected via a two-wire subscriber loop through which analog voice signals are carried in both directions. Those skilled in the art will readily understand that the telephone may be connected by optical fiber, ISDN, or other means. Alternatively to the above method, the user may use a computer 210, a paging system, a video conferencing system, or The telephone number can be dialed through another telephone cable device or the like. This call enters the local switched carrier (LEC), which is another name for the regional bell operating company (RBOC) central switch. The call is terminated by the LEC on a dedicated common business line (CBL) 230 of an interchange carrier such as MCI. As a result of the termination to the CBL, the MCI switch 221 receives a response status indication.

The switch 221 responds by initiating a DAL hotline procedure request to a network control system (NCS) that is a data access point (DAP) for the response state. Switch 221 has been simplified to show operation on a single DSI, but it should be understood that an exchange actually occurs between multiple lines, so that thousands of individual subscribers can be routed through the switch to their final destination. The DAP 240 sends the routing response back to the originating switch 221, which instructs the originating switch 221 to route the call to the destination switch 230 or 231. Routing of the call is performed by DAP 240, which translates the transaction information into a specific switch ID and a specific exit trunk group, which correspond to the route needed to reach the destination switch 230 or 231. Another embodiment of a hybrid network integrates an internet access facility into a switch 232. This integration allows switch 232 to directly connect to the Internet 295, which reduces the number of ports needed to connect the network to the Internet 295. The DAP sends this response information to the originating switch 221 which routes the call to the correct end switch 230 or 231. The termination switch 230 or 231 then finds the correct termination trunk group that routes the call to the ISN 250 or directly to the modem pool 270 based on the routing information of the DAP. If the call is destined for ISN 250, the DAP instructs the switch to terminate at switch 230.

Based on the analysis of the dialed number, the ISN routes the call to an automatic voice device (ARU) 252. The ARU distinguishes between voice, fax, and modem calls. If the call is in the form of a modem, the call is routed to modem pool 271 to connect to authentication server 291 for authenticating the user. If the call is authenticated, the call is forwarded to the Basic Internet Protocol Platform (BIPP) 295 via UDP / IP or TCP / IP LAN 281 or another media network, which is another processing and computer or other media device. Finally delivered to.

If the call is voice, the ARU prompts the caller for a card number and a destination number. The card number is verified using the card verification database. Once the card number is verified, and if the destination number is in the United States (domestic call), the call will be routed over the current MCI voice line. If the destination number is international, the call is routed to codec 260, where it converts voice to TCP / IP or UDP / IP and sends it to the Internet 295 via LAN 280. The call is routed through the destination gateway and then finally routed to a device capable of making a telephone or other telephone or the like.

1D is a schematic diagram of a hybrid switch in accordance with a preferred embodiment. Reference numerals coincide with FIG. 1C and additional block 233 is added. Block 233 has a connection device for connecting the switch directly to the Internet or other means of communication. Specifications for the connection device are provided in FIG. 1E. The main difference between the hybrid switch of FIG. 1D and the switch of FIG. 1C is that switch 221 can be directly connected to the Internet 295.

1E is a configuration diagram of the connection device described in FIG. 1D. Message booth 234 connects the switch organization to internal networks 236 and 237. Dynamic Telephone Connection (DTC) 238 and 239 alternately provide demuxing for signals originating from multiple DS1 lines 232-235, and internal networks 236 and 237 alternately receive this. The DS1 line is referred to as the traditional bit format on the T1 line.

To accommodate a rapidly distributed telephone / media environment, the embodiment uses separate switch connections for other internal network 237. Spectrum Peripheral Module (SPM) 247 is used to handle telephone / multimedia signals received from pooled switches 248, 249, 251, 254, 261-268. The pulled switch matrix is managed by the SM 247 via switch commands via the control line. SM 247 communicates with the service provider's call processing system, which is responsible for determining which lines require which types of hybrid switches.

For example, fax transmissions produce tones that identify transmissions as digital data rather than digitized voice. After confirming the digital data transmission, the call processing system instructs the calling circuitry to allow the particular input line to connect to the corresponding line with the appropriate processing characteristics via a pooled switch matrix. Thus, for example, an Internet connection may be connected to TCP / IP modem line 268, thereby ensuring proper handling of the signal before it is passed through the internal network 237 to the outgoing switch 221 through the message booth 234. Can be.

In addition to facilitating connecting the switch directly to the Internet, the pull switch matrix increases the scalability of the switch to accommodate current and future communication protocols. The echo removing means 261 is efficiently arranged in the switch to remove the echo. Relatively small echo cancellers efficiently service a relatively large number of individual transmission lines. The pulled switch matrix dynamically routes either connection-side or network-side transmissions from either direction of the switch to OC 3 demox, DSP processing, or other specialized processing.

In addition, the preferred embodiment shown in FIG. 1E provides additional system efficiency. For port devices on either side of a voice or data line switch, for example, a combination of multiprocessing steps makes it possible to connect a fiber optic cable directly to the multiprocessed output of the port device. In addition, to replace the path for combining various communication ports, redundancy is placed on the switch via a useful alternate route on CEM 248/249 and RM 251/254.

The switch 221 of FIG. 1D is connected to the Internet 295. The process is as follows.

The line from the Internet 295 enters the switch via modem port 268 and enters a pulled switch matrix that performs demux and other operations before information is passed to the switch 221 via internet network 237 and message booth 234. Modules 261-268 provide plug and play care for engaging around from various communications sectors.

Fig. 1F is a schematic diagram of a hybrid (Internet-telephone) switch in accordance with the preferred embodiment. Hybrid switch 221 replaces a switch on a public switched telephone network (PSTN) with a TCP / IP or UDP / IP port on an Internet network. Hybrid switch 221 is a PSTN network interface (247, 260), high-speed Internet network interfaces (271, 272, 274), a series of digital signal processors (DSP) (259, 263), time division multiprocessing booth 262 and high-speed data booth 275 It is composed.

Hybrid Internet telephony switch 221 is generated by a combination of router architecture and circuit switched architecture. Calls arriving at the PSTN interface 275 are initiated using ISDN User Part (ISUP-ISdn User Part) signaling. PSTN interface 257, with an IAM-Initial Address Massage with a called number and an optional calling number, sends the original address message to host processor 270. The host processor 270 examines the originating PSTN network interface, called number and other original address message parameters, and selects the outgoing network interface for the call. The selection of the outgoing network interface is made based on the routing table. The switch 221 may query an external service control point (SCP) 276 on the Internet to request a routing indication. Routing instructions derived from local switch 221 or derived from SCP may be defined in terms of subnets used to reach specific destinations.

In the same way as a router, each network interface can be labeled using a subnet address. The IP address contains the subnet where the computer is located. The PSTN address does not have an IP address, so the subnet is mapped to the PSTN area code and exchange. Switch 221 selects a route for an IP address and a PSTN address, by selecting an interface for a subnet that has a packet closer to the destination subnet or local switch.

The call may exit the switch via another PSTN interface 258 or exit the switch via a high speed internet network interface 273. If the call exits the switch via PSTN interface 258, the call exits in the form of a standard PCM voice call, or in the form of a modem call carrying a compressed digital voice.

When the call exits switch 221 in the form of a standard PCM voice call, the PCM voice is switched from PSTN interface 257 to PSTN interface 258 using TDM booth 260. Similarly, PCM voice is switched from PSTN interface 258 to PSTN interface 257 using TDM booth 260.

If the call exits the switch in the form of a modem call carrying compressed digital voice, switch 221 may initiate an outbound call to the PSTN number via PSTN interface 258, and then across the TDM booth 260 You can connect to DSP resources 259, which act as a resource. Once the modem session with the destination is established, the incoming PCM voice on PSTN interface 257 can be connected to DSP resource 263 which acts as a voice codec to compress the voice. Examples of speech formats include ITU G.729 and G.723. The compressed voice is packetized in a Point-to-Point Protocol (PPP) packet on DSP 263 and sent to DSP 259 for modem delivery over PSTN interface 258.

If the call exits switch 221 on high-speed Internet interface 272, switch 221 can connect PSTN interface 257 to a DSP resource 263 that acts as a voice codec that compresses PCM voice, and transmits the voice over the Internet network. Packets in UDP / IP packets. UDP / IP packets are sent from the DSP resource 263 to the high speed internet interface 272 via the high speed data booth 275.

1G is a schematic diagram illustrating a software process associated with hybrid Internet telephony switch 221. Packets received on the Internet network interface 296 are sent to a packet classifier 293. The packet classifier 293 determines whether the packet is a generic IP packet, or part of a routing protocol (ARP, RAPP, RIP, OSPF, BGP, CIDR) or management protocol. Routing and management protocol packets are forwarded to routing daemon 294. Routing daemon 294 maintains a routing table for use with packet classifier 293 and packet scheduler 298. Packets classified as general IP packets are sent to a packetizer / depacketizer 292 or a packet scheduler 298. Packets that are converted to PCM voice are sent to packetizer / depacketizer 292. The packetizer / depacketizer accepts the packet contents, converts the compressed voice to PCM voice, and forwards the PCM voice to codec 291, which forwards to PSTN interface 290.

Generic IP packets sent to other Internet devices are forwarded by packet classifier 293 to packet scheduler 298, which selects the outgoing network interface for the packet based on the routing table. The packet is placed on an outbound packet queue destined for the selected outgoing network interface, and the packet is sent to network interface 296 for delivery on the Internet.

D. Call Processing

This paragraph describes how the call is handled within the network context.

1. Handling VNET Calls

Figure 10A illustrates a public switched network (PSTN) 1000 comprised of LECs, through which the caller connects to a switched network including a plurality of MCI switches 1011, 1011, etc. using telephone 1021 or computer 1030. Directory services and other information for routing telephone calls are provided by directory service 1031 shared between public branch exchanges 1041 and 1040 and the PSTN.

This series of scenarios allows subscribers to use a PC and / or phone to receive or originate VNET calls. In this service, the subscriber may have the following equipment.

·telephone. Phones using VNET routing are useful in MCI's network. In such a case, the VNET call reaching the MCI PSTN network using the subscriber's VNET number is routed using the DAP as it is currently being done.

· A PC that can make Internet calls. The call is routed from or to the PC using an Internet or intranet directory service that tracks the login status and the current IP address of the VNET user.

PC and telephone can be used to receive and originate calls. In this case, the user profile has information that allows the DAP and directory services to decide whether to send incoming calls to the PC or to the telephone. For example, a user can always send a call to the PC when the PC is logged in, or to the phone at other times. Or, the user can always send the call to the PC during normal working hours, or the telephone at other times. This type of control, which determines where to send a call to a phone or PC, is controlled by the subscriber.

The scenario below applies to this type of service.

1. PC-to-PC call where directory service is asked about the location of the destination PC:

PCs connected to the intranet using the intranet as the transport device;

Both PCs connected to the corporate intranet by dial-up connections;

PCs on separate intranets, with both PCs connected through the intranet;

Both PCs on the Internet via dial-up connection;

One PC directly connected to the corporate intranet and another PC dial-up to the Internet;

One PC dialed up and another PC dialed up on a corporate intranet;

PCs on separate intranets with both PCs connected through the PSTN

One PC or both PCs connected to the corporate intranet by dial-up connection;

One PC or both PCs connected to an Internet service provider;

· In-network elements, one or both ITG.

2. A PC-to-phone call that requires the directory service to determine that the incoming VNET is a phone. The PC then contacts the Internet gateway to place the call on the incoming call.

A PC on an intranet that has ITG as an out-network element and uses a dedicated ITG connected to the PSTN. The destination phone is connected to the PBX.

The PC on the intranet may also be a PC using a public ITG which must be connected via the Internet.

The PC on the intranet may be a PC that is connected to the Communicator intranet using a dial up connection.

A PC on an intranet that has ITG as an in-network element and uses a dedicated ITG connected to the PSTN. The destination phone is connected to the PBX.

The PC on the intranet may also be a PC using a public ITG which must be connected via the Internet.

The PC on the intranet may be a PC that is connected to the Communicator intranet using a dial up connection.

A PC on an intranet that has ITG as an in-network element and uses a dedicated ITG connected to the PSTN. The destination phone is connected to the PSTN.

The PC on the intranet may also be a PC using a public ITG which must be connected via the Internet.

The PC on the intranet is connected to the comparator intranet using a dial-up connection.

The ITG may be an in-network element.

• A PC on an intranet using a dedicated ITG connected to a PBX that has calls carried over the intranet.

The PC is at a different location than the destination phone that is delivered over the Internet or intranet.

The PC may use a dial-up connection to the Communicator intranet.

3. A phone-to-PC call that stimulates an Internet directory service that identifies the destination IP address and ITG to route the call to the DAP or PBX. The call is routed through the PSTN to the ITG and from the ITG to the destination PC.

Possible variables:

There may be variables like PC to phone.

4. A telephone-to-phone call that allows the DAP or PBX to determine whether the directory service will be called by the subscriber's phone or PC.

Possible variables:

Both phones are on the PBX;

One phone is on the PBX and the other phone is on the PSTN; And

Both phones are on the PSTN.

In each of these variables, the DAP and directory service may be a single entity or separate entities. The directory service may also be a dedicated service or may be a public service. Each scenario is described below with reference to a call flow description and is consistent with the preferred embodiment. The block elements associated with each element of the call flow diagram are provided below to assist in understanding the embodiment.

2. Description of Block Elements

E. Reusable Call Flow Blocks

1. The VNET PC is connected to a common intranet and logs in to the directory service.

1 .PC users connect their computers to the IP network, turn on the computers and start the IP Telephony service package. The software package registers the computer "on-line" and sends a message to the directory service to receive the call. The on-line registration message will most likely be sent to the directory service in encrypted form for safety. The encryption will be based on the shared key assigned between the PC and the directory service. The message contains the following information:

A virtual dedicated network number or any kind of identification of the computer that can be used to address the computer. In the above VNET scenario, this is the VNET number assigned to the individual using the PC. The information can be used to identify a customer profile associated with the user. It may also be any identification, such as a name, employee ID, or any unique ID that a directory service can link to a VNET customer profile.

· Any other mechanism or password for authenticating the user identified by the VNET number.

An IP address identifying the port being used to connect the computer to the network. The address will be used by another IP telephony software package to establish a connection to the computer.

The message may contain details of the PC or software package used for the IP telephony and additional information regarding the software or the configuration / capability of the PC. As an example, it may be important for the calling PC to know what type of compression algorithm is being used or may affect other users' ability to access them or other capabilities of software or hardware that may use special features during the connection. have.

The location of the directory service that receives the "on-line" message will be determined by the data distribution implementation for the customer. In some cases, this may be a dedicated database for the organization or company using the VNET service, or in other cases, it may be a national or global database for all customers of the service provider. The location is configured and placed in a telephony software package running on a PC.

2. When the directory service receives the message from the PC, it identifies the user by using the VNET number to find the user profile or by comparing the password in the profile with the received password. Once the user is verified, the directory service will update the profile entry associated with the VNET number (or other unique ID) to indicate that the user is "online" and located at a particular IP address. The directory service updates the profile with the configuration data sent during the login request. Upon successful update, the directory service returns a response to the specific IP address indicating that the message has been received and processed. This receipt notification message may also include a security or encryption key to ensure secure contact with the directory service when issuing additional commands. When the PC receives the response message it may choose to inform the user via a virtual or audible indicator.

Transformation for on-line registration

The call flow segment shown earlier in this chapter showed PC on-line registration, where the PC simply sends a password to the directory service for log-on. The transformation for the log-on procedure may be a subsequent call flow segment, where the directory service issues a challenge and the PC user must respond to the load to complete the log-in sequence. The transformation on the log-on sequence does not appear in any call flow included in this document but can be used.

1. PC users connect their computers to the IP network, run the computers, and start the IP telephony software package. The software package registers the computer "on-line" and sends a message to the directory service to receive the call. The on-line registration message will most likely be sent to the directory service in an encrypted format for security. The encryption will be based on a shared key between the PC and the directory service. The message contains the following information:

Identification of any kind of computer or virtual dedicated network that may be used to address the computer. In the above VNET scenario, this is the VNET number assigned to the individual using the PC. The information will be used to identify a customer profile associated with the user. The information may also be any identification such as a name, employee ID or any unique ID that the directory service can associate with the VNET customer profile.

The IP address identifying a port being used to connect the computer to the network. The address will be used by another IP telephony software package that establishes a connection to the computer.

The message may contain details of the software and PC used for IP telephony and additional information regarding the software and the configuration / capability of the PC. For example, it may be important for the calling PC to know the type of compression algorithm being used and the other capabilities of the software and hardware to affect the ability of other users to connect to the user or to use special features during the connection. .

The location of the directory service that receives the " on-line " message may be determined by performing data distribution for the customer. In some cases, the location of the directory service may be a dedicated database for companies or organizations that have subscribed to the VNET service, and in other cases, may be national or global for all customers of the service provider (MCI). The location is configured and placed in the telephony software package running on the PC.

2. In this scenario, the PC does not provide a password in the initiation registration message. This is because the directory service uses a challenge / response registration process. In that case, the directory service will use a shared key to calculate the load to be provided to the PC.

3. The PC receives the baggage and provides the baggage to the PC user. The PC user uses the shared key to calculate the response to the baggage and send the response back to the directory service.

4. When the directory service receives the response from the fraudulent PC, the directory service validates the user. Once the user is validated, the directory service will update the profile entry associated with the VNET number (or other unique ID) to indicate that the user is "on-line" and located at a particular IP address. The directory service will also update the profile with the configuration batch data sent during the login request. After a successful update, the directory service sends a response to a specific IP address indicating that the message has been received and processed. The receipt notification message may include some kind of secure or encrypted key to ensure secure communication with the directory service when issuing an additional command. When the PC receives the response, the PC may choose to notify the user via a visible or audible indicator.

2. The VNET PC queries the directory service for VNET translation.

1. The PC uses the Internet Telephony software package to attempt to access the VNET number. To establish the connection, the PC user dials the VNET number (or another unique ID such as name, employee ID). Once the telephony software package confirms the call as a VNET call, it sends a translation request to the directory service. At a minimum, the translation request includes the following information.

IP address sending the request

The VNET number sending the request

The VNET number (or other ID) of the dialed computer

Requested configuration for connection. For example, the calling PC may want to use a white-board capable output inside a telephony software package and may want to verify the capable output on the destination PC before establishing a connection. If the VNET number is not translated to a PC, the configuration information may not provide any benefit but the user does not know whether the VNET number is translated to PC or phone when sending the request.

2. When the directory service receives the message, the directory service uses the VNET number to determine if the user associated with the VNET number is on-line and to determine the IP address of the location to which the computer can connect. The directory service may also include and use features such as time of one routing, time of primary routing, ANI screening, and the like.

If the VNET number is translated to an on-line PC, the directory service will compare the configuration information on the request with the configuration information available on the profile for the destination PC. When the directory service returns a response to a translation request from the originating PC, the response will include the following.

• Registered "on-line" IP address of the destination PC. This is an IP address that can be used by the calling PC to connect to the called PC.

Configuration information indicating the possible outputs of the called PC and / or any information whose possible outputs are compatible between the calling and called PCs.

If the VNET number translates to a number that must be dialed through the PSTN, the response message to the PC will include:

IP address of the Internet telephony gateway that can be used to make the call on the PSTN of the MCI. The selection of the gateway may be based on the number of selection algorithms. This association between the ITG and the caller used is made based on the information in the profile contained within the directory service.

-The VNET number dialed by ITG to access the incoming phone. In the case of the call flow this is the VNET number of the called phone. This allows the call to use the path selection mechanism provided by the DAP and the current VNET translation.

If the VNET number is translated into a phone that can be reached through a private ITG connected to the customer's PBX, the directory service will come back as:

The VNET number of the ITG gateway connected to the PBX serving the incoming phone. The connection between the called phone and the ITG connected to the serving PBX is provided by a directory service.

-The VNET number dialed by ITG when making a call to a PBX. In most cases this will only be an extension.

3.PC connection to ITG

1. The PC uses a telephony software package to send a "connect" message to ITG. This IP address is usually returned to the directory service in response to a VNET translation. The particular format and content of the message depends on the software sending the message or the ITG software receiving the message. The message may include information identifying the user of the PC or may include information detailing the parameters associated with the requested connection.

2. The ITG responds to the access message by responding to the message with a receipt notification indicating that the call has been received. This step of call setup may not be necessary for an ITG calling PC, but this step is seen as an attempt to maintain a consistent call setup procedure regardless of whether the PC is connected to an ITG or another PC. When connected to a PC, this step of the procedure allows the calling PC to know if the called PC is ringing.

3. The ITG accepts the call.

4. A voice path is established between the PCs.

4. ITG access to PC

1. ITG uses its telephony software to send "connect" messages to the PC. The ITG must know the IP address of the PC being connected. The specific format and content of the message depends on the ITG software sending the message or the PC software receiving the message. The message may include information identifying the call as information provided from ITG or may include information detailing the requested configuration arrangement for the call.

2. The message from step 1 is received by the PC and the receipt of the message is a receipt notification by sending back a message to the ITG indicating that the PC is providing the call to the PC user.

3. The PC user answers the call and a message is sent back to the calling PC indicating that the call was accepted.

4. A voice path is established between the ITG and the PC.

5. Describe the VNET Call Flow to the PC

The PC 12 1051 user connects the computer to the Internet Protocol (IP) network 1071, turns the computer on, and starts the IP Telephony software protocol system. The system software sends a message to directory service 1031 that registers the computer "on-line" and registers the call receiveable. The message includes an IP address that identifies the connection being used to connect the computer to the network. The address can be used by another IP telephony software package that establishes a connection to the computer. The address consists of an identification of the computer or a virtual dedicated network that can be used to address the computer 1051. In a VNET scenario, the address is a VNET number assigned to an individual using the PC. VNET represents a virtual network where a particular set of telephone numbers is supported as a dedicated network of numbers that can exchange calls. Many enterprises are now buying communication time into trunks, which are used as dedicated communication channels for placing and receiving inter-entry calls. The address may also be any identification such as a name, employee ID or any other unique ID.

The message may include additional information regarding the hardware configuration arrangement or system software details of PC 11 1051 used for IP telephony. For example, the calling PC knows what type of algorithm is supported and running on the current communication, and the other capabilities of the software and hardware that affect the ability of other users to access or use special features during the connection. It is important.

6. Determination of the best choice for Internet clients of Internet telephony gateways on the Internet

10B shows an internet routing network according to a preferred embodiment. If a client computer 1080 on the Internet is required to access the Internet Telephony Gateway 1084, then the ideal choice for the gateway to select is divided into two categories according to the client's needs.

If Client 1080 makes a phone call to a regular PSTN phone and it is determined that the use of the PSTN network will be cheaper or of higher quality than the use of the Internet network, it will allow the user to access the PSTN network from the point closest to the Internet access point. Choosing a gateway is the preferred choice. This is sometimes referred to as HEHO, where the client hops off the Internet at the "head end" or "near end."

If client 1080 requires a telephone call to a regular PSTN phone and the PSTN network is determined to be expensive relative to the use of the Internet network, then choosing a gateway that allows the client to access the PSTN from the point closest to the incoming call Is the preferred choice. This is referred to as Tie-End Hop-Off (TEHO), where the client hops off the Internet at the tail end or far end of the Internet.

a) head-end hop-off method

(1) client ping method

This approach selects the best head-end hop-off Internet telephony gateway by obtaining a list of candidate Internet telephony gateway addresses or by pinging each to determine the best choice of latency and number of router hops. The process is as follows.

Client computer 1080 Contact Directory Service 1082 to obtain a list of candidate Internet telephony gateways.

The directory service 1082 selects a list of gateways by looking at the database of gateways to provide candidates to clients. Decision criteria for selecting a gateway as a candidate may be included.

■ Last gateway selected.

■ Matches one, two, or three octets in an IPv4 address.

■ The last client access point, if you know it.

■ If at least, select at least one gateway from all primary gateway sites.

The directory service 1082 sends back an "n" candidate IP address to the client 1080 in a TPC / IP message.

At the same time, the client 1082 sends the echo type message to each candidate Internet telephony gateway 1084,1081,1086 using the IP ping. The "-al" option will be used with the ping command to get the trace route.

Based on the ping results of each Internet telephony gateway, client 1080 will sort the ping results in the following order:

If the Internet telephony gateway can access client 1080 without going through any arbitration router exposed by the ping trace path, they are sorted first.

Residual Internet telephony gateways are sorted in order of the lowest latency of round-trip ping results.

Using a client ping scheme with the Sample Network Topology, the client computer 1080 queries the directory service 1082 for a list of Internet telephony gateways to ping:

166.37.61.117

166.25.27.101

166.37.27.205

The client computer 1080 simultaneously issues the following command:

ping 166.37.61.117-r1

ping 166.25.27.101-r1

ping 166.37.27.205-r1

The result of the ping command is:

Pinging with 32 bytes of data 166.37.61.117:

Response from 166.37.61.117: Bytes = 32 Hours = 3 Minutes TTL = 30

Path: 166.37.61.101

Response from 166.37.61.117: Bytes = 32 Hours = 2 Minutes TTL = 30

Path: 166.37.61.101

Response from 166.37.61.117: Bytes = 32 Hours = 2 Minutes TTL = 31

Path: 166.37.61.101

Response from 166.37.61.117: Bytes = 32 Hours = 2 Minutes TTL = 30

Path: 166.37.61.101

Pinging with 32 bytes of data 166.25.27.101

Response from 166.25.27.101: Bytes = 32 hours = 14 minutes TTL = 30

Path: 166.37.61.101

Response from 166.25.27.101: Bytes = 32 hours = 2 minutes TTL = 30

Path: 166.37.61.101

Response from 166.25.27.101: Bytes = 32 hours = 3 minutes TTL = 31

Path: 166.37.61.101

Response from 166.25.27.101: Bytes = 32 hours = 4 minutes TTL = 30

Path: 166.37.61.101

Pinging with 32 bytes of data 166.37.27.205

Response from 166.37.27.205: Bytes = 32 hours = 1 min TTL = 126

Path: 166.37.27.205

Response from 166.37.27.205: Bytes = 32 hours = 1 min TTL = 126

Path: 166.37.27.205

Response from 166.37.27.205: Bytes = 32 hours = 1 min TTL = 126

Path: 166.37.27.205

Response from 166.37.27.205: Bytes = 32 hours = 1 min TTL = 126

Path: 166.37.27.205

The path chosen as 166.37.27.205 does not go through the router (the path and ping address are the same). The remaining Internet telephony addresses are sorted in average latency. The preferred alignment result of the Internet telephony gateway is

166.37.27.205

166.37.61.117

166.25.27.101

The first choice gateway is most suitable for providing high quality service because it is located in the same local area network. The gateway will be the first that the client attempts to use.

(2) access device location method

The scheme for identifying the optimal selection of the Internet telephony gateway uses a combination of the above client ping schemes and information about the origin of the client computer 1080 accessing the Internet. The scheme may be effective for clients accessing the Internet through a dial-up access device.

Client computer 1080 dials the Internet access device. The access device answers the call and operates a modem tone. At that time, the client computer and the access device establish a PPT session. The user of the client computer is verified (username / password prompt validated by the verification server). Once the user passes the confirmation, the access device updates the user profile of the directory service for the identified user, earning the following information.

"Username" "account code" "online timestamp"

"Access device site code"

Later, when the client computer requests access through the Internet telephony gateway, it consults directory service 1082 to determine the choice of the best Internet telephony gateway. If the access device site code is found in the user profile of the directory service, the directory service 1082 selects the Internet telephony gateways 1084, 1081 and 1086 in the same site code and returns the IP address to the client computer 1080. If the Internet telephony gateways 1084, 1081 and 1086 cannot be used at the same site as the access device site code, then a suboptimal selection is made according to the network topology map stored in the directory server.

If no access device site code is found in the directory server 1082, then the client 1080 accesses the network through a device that cannot update the directory server 1082. If this is the case, the client ping scheme described above is used to determine the best alternative Internet telephony gateway.

(3) user profile method

Another way to choose the Internet Telephony Gateways 1084, 1081 and 1086 is to embed the information needed to select a gateway into a user profile stored on a directory server. In order to use this approach, the user must run an Internet telephony software package on the client computer. Initially when the package is executed, registration information is gathered from the user, including username, email address, IP address (for a fixed location computer), site code, account code, visual Internet access code and other related information. Include. Once the information is entered by the user, the software package stores the information in a directory server, especially in a user profile.

When the user starts the Internet telephony software package, the user's IP address is automatically updated in the directory service. This is known as automated presence notification. Later, when the user needs the Internet telephony gateway service, the user inquires of the directory service about the available internet telephony gateway. The directory service knows the user's IP address and the user's visual site and access point to the network. The directory service may use the information in addition to the network maps of all Internet telephony gateways 1084, 1081 and 1086 to select an available Internet telephony gateway for the client computer.

(4) Gateway Ping Method

The last approach makes the best choice for the head-end hop-off Internet telephony gateway by getting a list of candidate Internet telephony gateway addresses and pinging each one to make the best choice according to the latency and number of router hops. The process is as follows.

The client computer consults the directory service to obtain the best choice for the Internet telephony gateway.

The directory service finds a database of gateways and selects a list of candidate gateways. Gateway selection criteria as candidates may include the following.

■ Last gateway selected.

■ Matches one, two, or three octets in an IPv4 address.

■ The last client access point, if you know it.

■ If practical, select at least one gateway from all primary gateway sites.

The directory sends a message to each candidate gateway instructing each candidate gateway to ping the client computer's IP address.

Each candidate gateway simultaneously sends the echo-type message to the client computer using the IP ping. You can use the know-option with the ping command to get the trace path. The ping results are returned to the directory service from each candidate gateway.

■ Based on the ping results for each Internet telephony gateway, the directory service orders the following ping results.

If any Internet gateway can access the client exposed by the ping trace path without going through any arbitration router, they are ordered first.

Residual Internet telephony gateways are sorted by hand with less average latency for round trip ping results.

The client ping scheme and the gateway ping scheme may use a tracking path program in place of the ping program in making the best choice for the head-end hop-off gateway.

(b) Tail-end hop-off scheme

Tail-end hop-off involves selecting a gateway from the Internet to an exit point, where the possible exit point is closest to the terminating PSTN location. This is required to avoid high PSTN call rates. The Internet can be used to bring packetized voice to the local calling area of the called telephone number, where a low local rate can be paid for carrying the call on the PSTN.

(1) Gateway Registration

One way of tail-end hop-off service is to have Internet telephony gateways 1084, 1081 and 1086 register with the directory service. Each Internet telephony gateway will have a profile that aligns the directory service with the calling area serviced by the directory service. These may be ordered according to country code, area code, switching center, city code, line code, radio cell, local access transport area (LATA) or any other way that can be used to subset the numbering plan. Upon initiation, the gateway sends a TCP / IP registration message to the directory service sorting into the area serviced by the directory service.

If the client computer wants to use the TEHO service, it inquires of the directory service about the Internet telephony service 1084, which serves the desired destination telephone number. The directory service 1082 looks for a qualifying Internet telephony gateway and, if found, returns the IP address of the available gateway. A load balancing algorithm can be used to balance call volume across multiple Internet telephony gateways 1084, 1081 and 1086 serving the same incoming telephone number.

If the Internet telephony gateways 1084, 1081 and 1086 do not serve the calling area of the specially given destination telephony number at all, the directory service 1082 sends an error TCP / IP message back to the client computer 1080. The client 1080 then has the option to query the directory service for any internet gateway, not just the gateway serving a particular incoming telephone number.

As a variant of the gateway registration mechanism, the gateway can register call rates provided for all call areas. For example, if a gateway is not available at all in Seattle, calling Seattle from a gateway in Los Angeles may be cheaper than calling Seattle from a gateway in Portland. The call rate registered with the directory service may cause the directory service to be the least expensive gateway for using any particular call.

7. VNET Call Processing

11 is a diagram illustrating a call flow diagram according to a preferred embodiment. Processing begins at 1101, where the location of the directory service that received the on-line message will be determined by the data distribution implementation for the customer. In some cases this may be a private database for a company or organization that has subscribed to a VNET service and in other cases it may be an international or global database for all customers of a service provider (MCI). When the directory service receives the message from PC12 1051, it will update the profile entry associated with the unique ID indicating that the user is on-line and located at a particular IP address. At 1102, after a successful update of the profile associated with the ID, the directory service sends an acknowledgment (ACK) to a particular IP address indicating that a message has been received and processed. When the computer PC12 receives the response message, it may choose to notify the user via a visual or auditory indicator.

At 1103 the user of PC11 1052 connects the computer to the IP network, turns on the computer and starts the telephony system software. The registration process for the computer follows a similar procedure to that of PC12 1051. In this scenario, it is assumed that the directory service receiving the message is the same as the directory service receiving the message from PC12 1051 physically or logically.

When the directory service 1031 receives a message from PC11 1052 at 1104, the directory service starts a procedure similar to the procedure following the message at PC12 1051. In this case, however, we will update the profile associated with the identifier received from PC11 1052 and use the IP address received from PC11 1052. When an acknowledgment is sent from the directory service due to the updated profile information, it is sent to the IP address associated with PC11 1052. At this point, both computers PC12 1051 and PC11 1052 are "on-line" and can be used to receive calls.

At 1105, PC12 1051 uses the telephony system software of PC 12 1051 to access computer PC11 1052. To establish the connection, the user of PC 12 1051 dials the VNET number (or other unique ID such as name, employee ID, etc.). Depending on the implementation of the software package and the customer network, a unique network identifier may have to be placed in the dial string. For example, in telephony implementation of VNET, the subscriber is required to enter the number 8 before dialing the VNET number to signal the PBX that the VNET network is in use for routing the call. Once the telephony software package identifies the call as a VNET type call, the telephony software package will send a translation request to the directory service. At a minimum, the translation request will include the following information:

The IP address of the computer sending the request and

The VNET number of the dialed computer

At 1106, when the directory service receives the message, the VNET number (or other ID) is used to determine if the user associated with the VNET number (or other ID) is on-line and to which the computer can be connected. Identifies the IP address. Any additional information available about the computer that is connected (to PC11 1052), such as a compression algorithm or special hardware or software functionality, may also be recovered by the directory service 1031. The directory service 1031 then sends a message along with status information about the PC11 1052, such as whether the computer is on-line and if the computer is available, its IP address and any other information available about the functionality of the PC11 1052. Is sent back to PC12 1052. When PC12 1051 receives the response, it determines whether PC11 1052 can be connected. The determination will be based on the on-line state of the PC11 1052 and the additional information regarding the functionality of the PC11 1052. The call flow stops here if PC12 1051 receives status information indicating that PC11 1052 cannot connect, but continues otherwise.

Subsequent steps 1107 to 1111 are normal IP telephony call preparation and tear-down steps. At 1107, PC12 1051 delivers a "ring" message to PC11 1052. The message is sent to the IP address received from the directory service 1031 in step 1031. The message may include information identifying a PC12 1051 user or may contain information specifying parameters related to the requested connection.

At 1108, PC11 1052 receives the message from step 1107, and receipt of the message is notified by sending back a message to PC12 1051 indicating that the PC11 1052 user has been informed of the incoming call. The notification can be viewed or heard depending on the software package and configuration of the PC11 1052.

At 1109, when the PC11 1052 user accepts the call, a message is sent to PC12 1051 confirming the response to the call. If the PC11 1052 user does not answer or refuses the call, a message indicating an error condition is sent to PC12 1051. If there is no response to the call, the call flow stops here but otherwise continues.

At 1110, users of PC12 1051 and PC 11 1052 can communicate using their telephony software. The conversation proceeds at 1111 until both PC users disconnect by sending a disconnect message to the other call participant. The format and content of the message depends on the telephony software package used by the PC12 1051 and PC11 1052. In this scenario, PC11 1052 sends a disconnect message to PC12 1051 and the telephony software systems of both computers stop voice transmission.

12 is a view showing a VNET PC information call flow for the PC out of the network in accordance with a preferred embodiment. In the flow, the Internet telephony gateway is an out-of-network element. This means that the Internet telephony gateway cannot use SS7 signaling to communicate with the switch and must simply pulse the dialed VNET number. Alternate embodiments facilitate directory services directly translating VNET numbers into switches / trunks and pulse the appropriate numbers. The process facilitates translation in a switching network but may require a more complex signalrun interface between the Internet gateway and the switch. This type of in-network internet gateway scenario will be addressed in another call flow.

The scenario assumes that there was no integration between the Internet and the customer premises exchange (PBX). If there was integration, it may be possible for the PC to access ITG on the customer PBS via the Internet (or intranet). 12 is a diagram illustrating a call flow diagram according to a preferred embodiment. Processing begins at 1201, where the location of the directory service that received the on-line message will be determined by the data distribution execution for the customer. In some cases, this may be a private database for a company or organization that subscribes to a VNET service, or in other cases an international or global database for a service provider (MCI).

When the directory service receives the message from PC12 1051, the directory service will update the profile entry associated with the unique ID indicating that the user is on-line and located at a particular IP address. Then, at 1202, after a successful update of the profile associated with the ID, the directory service sends an acknowledgment (ACK) indicating that the message has been received and processed. When the computer PC12 receives the response message, it may choose to notify the user via a visible or audible indicator.

At 1203, a VNET translation request is then sent to the directory service to determine the translation for the dial call path to the out-of-network Internet gateway phone. A response including the IP address and DNIS is returned at 1204. The response completely decomposes the phone address information to route the call. Then, at 1205, an IP telephony dial call using the DNIS information occurs. DNIS refers to a dialed number information service that is explicit information about a call for use in routing the call. At 1206 ACK is returned from the IP telephony, at 1207 an IP telephony response occurs and the call path is set at 1208.

1209a shows a VNET PC going into the answer state and sending a dial tone 1209b. Then, at 1211, the routing translation of the DNIS information is used by a routing database to determine how to route the call to an incoming call. A translation response is received at 1212 and a switch-to-switch pulse is emitted at 1213. Then at 1215 a ring is sent to the called phone and a ringback to the PC occurs. At 1216 the call is sent and answered out of the network via the Internet gateway connection. At 1217, the conversation continues until one of the participants hangs up at 1218.

FIG. 13 is a view illustrating a VNET PC phone information call flow for an out-of-network phone according to an exemplary embodiment. The call flow prevents the use of the PSTN by routing the call from the PC to the Internet / Intranet to an Internet gateway directly connected to a PBX.

14 is a view illustrating a VNET PC phone information call flow for a phone in a network according to an exemplary embodiment. In the call flow, the Internet telephony gateway is an element in the network. This requires that the Internet gateway can use SS7 signaling and act as if it were a switch to hand off the call to a switch. This allows the directory service to return the switch / trunk and pulse the digits on the first VNET lookup. This step prevents further lookup by the switch. In this case the directory service must have access to the VNET routing information.

a) PC to PC

15 illustrates a PC to PC internet telephony call according to an exemplary embodiment. In step 1501, a net phone user is connected to the step 1502 MCI directory service via the Internet by IP connection, where a lookup is performed to determine how to route the call. Step 1503 ends at the Intelligent System Platform (ISP) to determine where to send the call. An IP router is a gateway to the MCI ISP feature engine to determine how the intelligent service network (ISN) receives the call over the network. In step 1504 the call is connected to the net phone user via the Internet. In step 1504 of the alternative scenario, the call participant wants to speak with the MCI operator and the IP router is going through the net-switch (interface) (to the voice world), so no person at the phone is unnecessary. In step 1505, the net switch asks the call processing engine whether it performs a DSP engine function. In step 1506 the call is routed through the WAN hub to the MCI switch to the MCI operator or in step 1507 to voicemail.

b) PC to phone

16 shows a telephone routed from a PC to the telephone via the Internet. In step 1602, the MCI directory is queried to obtain ISN information for routing the call. The call is then directed back to the ISP gateway in step 1603 and routed to the call processing engine using the IP router in steps 1604 and 1605. Then in step 1606 the call is routed to the WAN and finally to RBOC where a body charge is recorded for the call.

c) phone to PC

17 illustrates a phone to PC according to a preferred embodiment. In step 1701 the phone is routed to a special net switch, where in step 1702 the call processing engine determines a DTMF tone using a series of digital signal processors. The system then finds directory information and connects the call at step 1703.

If the caller is not there or is in a call, then at step 1704 the call is routed over the switch through an IP router using the call processing engine at step 1705.

d) phone to phone

18 illustrates a phone call to a phone on the Internet according to a preferred embodiment. The call comes to the switch in step 1801 and is processed by a call logic program executed in the call processing engine in step 1802. In step 1803 a lookup is performed in the directory information database to determine the call path designation described above. Routing includes storing the billing record in the main billing task 1808. All ISN functions can be used for the call even though the call is routed through the Internet. An IP router is used at each internet end to facilitate the call progress through the Internet 1804 and towards the network switch. The call from the network switch is routed to the call processing engine and to the target phone via WAN hub 1806 and through RBOC 1807. Various DSP engines 1803 are used to implement digital transcoding, DTMF detection, speech recognition, call processing, VRU functions, and modem functions.

XI. TELECOMMUNICATION NETWORK MANAGEMENT

The preferred embodiment utilizes a network management system for telecommunication networks to analyze, correlate, and provide network events. Modern telecommunications networks use data signaling networks of different nature from call-bearing networks to carry signaling data required for hortool setup, processing and cancellation, which collectively is a common channel. It uses the Common Channel Signaling System # 7, ie, the commercial-standard architecture and protocol, which is weakly referred to as Signal System # 7. SS7 has made significant progress over existing signaling schemes, where call signaling data is transmitted over the same line as a call. It provides a unique dedicated network for the circuit to carry SS7 call signaling data. Using SS7 reduced call setup time (detected by caller as post-dial delay) and increased capability in call-bearing networks. A detailed description of SS7 signaling is provided by Signaling System # 7, Travis Rusell, Mcgraw Hill (1995).

The standards for SS7 networks are set by ANSI for national (US) networks and by ITU for international access, and are referred to as ANSI SS7 and ITU C7, respectively. A typical SS7 network is shown in FIG. 1B. Call-bearing telecommunication networks use matrix switches 102a / 102b to switch customer call volumes. The switches 102a / 1O2b are standardized, such as DMS-250 manufactured by Northern Telecom or DEX-600 manufactured by Digital Switch Corporation. The switches 102a / 102b are interconnected with voice-grade and data-grade call-bearing trunks. The connection is not shown in FIG. 1B but can take many kinds of configurations.

Switches in telecommunication networks perform multiple functions. In addition to switching the line for voice calls, the switch must relay signaling messages to other switches as part of call control. The signaling message is delivered through the computer's network, each of which is named signaling point (SP) 102a / 102b. There are three kinds of SPs in the SS7 network:

Service Switching Point (SSP)

Signal relay point (STP)

Service Control Point (SCP)

The SSP is a switch interface to the SS7 signaling network.

Signal relay points (STP) 104a ... 104f (collectively referred to as 104) are packet-switching communications devices used to switch and route SS7 signals. The signal relay points are arranged in pairs known as clusters for redundancy and restoration. For example, in FIG. 1B, STP 104a is paired with STP 104b in Regional Cluster 1, STP 104c is paired with STP 104d in Regional Cluster 2, and STP 104e is STP 104f in Regional Cluster 3. Paired with. A typical SS7 network includes a plurality of STP clusters 104; In Figure 1 three are shown for purposes of illustration. Each STP cluster 104 serves a specific geographic area of SSP 102. The plurality of SSPs 102 has a primary SS7 link with each of the two STPs 104 in the cluster. This serves as the primary homing arrangement. In FIG. 1B, for the purposes of illustration only two SSPs 102 are shown to home into a local cluster: in practice several SSPs 102 will home to a particular STP cluster 104. SSP 102 will also generally have a secondary SS7 link with one or two STPs in another cluster. This serves as a second out-of-band system.

The SS7 link connecting the various elements is identified as follows:

A link connects the SSP to each of the primary STPs.

The B link connects STP in one cluster with STP in another cluster.

The C link connects one STP to another STP in the same cluster.

The D link connects STP between different carrier networks (not shown).

The E link connects the SSP to STPs that are not in the same cluster (secondary homing).

The F link interconnects two SSPs.

STP cluster 104 from each carrier's network may be connected by D links or A links to connect a network of two different carriers, such as an Interchange Carrier (IXC) network and a Local Exchange Carrier (LEC) network. SS7 provides a standardized protocol for the interface to also send signaling for calls passed between LEC and IXC.

When the switch receives and routes a customer call, signaling for that call is accepted (or generated) by the connected SSP 102. When the intermachine trunks that connect the switches take a customer's call, the signaling for that call is sent to STP4. The STP4 routes the signal to either SSP 102 of the call termination switch or to another STP 104, and then the other STP 104 routes the signal to SSP 102 of the call termination switch. . Another element of the SS7 network is Protocol Monitoring Units (PMU) 106 as shown in FIG. The PMU 106 is located at the switch site and provides independent monitoring tools for the SS7 network. INET Inc. The devices, such as the device manufactured by of Richardson, TX, monitor the A, E and F links of the SS7 network as shown in FIG. They generate error and performance information for the SS7 link.

Like any telecommunications network, the SS7 network is fatal to fiber tearing and other severe transmission and device errors. Since the SS7 network takes all the signaling required to carry the customer call volume, it is essential that any difficulties be quickly removed and corrected. Therefore, the system must be able to monitor the SS7 network, analyze errors and performance, and manage corrective actions.

The prior art of the SS7 network management system has several disadvantages although it performs the above basic functions. Much is required of the passive configuration of the network topology, which is fatal to human error and delay of phase update. The configuration arrangement of the systems generally requires the system to be down for a period of time. Many systems that are available in the industry are intended for a particular vendor's PMU 106 and are actually getting topology data from their PMU 106 and therefore ignore network elements that are not connected to PMU 106 and other vendor's equipment.

Since prior art systems only operate with data received from proprietary PMU 106, they do not provide correlation between PMU events and events originating from other types of SS7 network elements. They also only provide rigid and proprietary analysis of event correlation.

Methods and systems for enhanced SS7 network management functionality are provided by a distributed client / server platform that can receive and process events generated by various SS7 network elements. Each network event is analyzed and standardized to allow processing of events generated by any type of element. Events can also be received by the network topology database, the transport network management system, the network maintenance schedule, and system users. 3, the system architecture of the preferred embodiment of the present invention, referred to as SS7 Network Management System (SNMS), is shown. The SNMS consists of four logical servers 302/304/306/308 and a number of client workstations 312a / 312b / 312c connected through a network management wide area network. All four logical SNMS servers 302/304/306/308 may exist in a single or multiple physical units. In a preferred embodiment, each logical server resides in a separate physical unit to enhance functionality. The physical units may be of any conventional form, such as an IBM RS6000 unit running with an AIX operating system.

The client workstation 312 may be a conventional PC running with a micro Windows or IBM OS / 2 operating system, a dumb terminal, or a VAX VMS workstation. In practice, the client workstation may be any terminal or PC running with X-Windows with Internet Protocol (IP) and connected to WAN 310. No SNMS-specific software runs on client workstation 312.

SNMS receives events from various SS7 network elements and other network management system (NMS) 338s. It also receives network topology, configuration and maintenance data from external systems, which will be described later. Various network elements that generate events include network controller 314 and international and domestic SP 316/102, STP 104 and PMU 106. Network controllers 314 are devices that switch circuits based on external commands. They use SS7 signaling in the same way as SSP 102 but are not connected to any STP 104. International SP 316 serves as a gateway between national and international telecommunication networks. The STP 104 may be national or international.

The PMU 106 scans the SS7 packet across the SS7 line, analyzes the error condition and generates a network event passing over the SNMS at that time. The PMU 106 also generates periodic statistics about the function of the monitored SS7 line.

All SP 102/316, STP 104, PMU 106, and SS7 network controllers 314 send network events over the communications network to the SNMS. This removes the requirement that SNMS maintain a session with each device. In one exemplary embodiment, as shown in FIG. 3, an asynchronous data communication network 320 is used to send events from network controller 314 and international SP 316. IBM body Front End Processor (FEP) 324, such as IBM's 3708, is used to convert the asynchronous protocol to SNA so that the asynchronous protocol can be received by the IBM mainframe-based switched Host Interface Facilities Transport (SWIFT). SWIFT 326 is a communication interface and data distribution application that maintains logical communication sessions with each network element.

In the same embodiment above, the X.25 Operating Systems Support (OSS) network 328 is used to send events from STP 104 and SP 102 and PMU 106. The Local Support Element (LSE) system 330 receives the events. The LES 330, which may be a VAX / VMS system, is essentially a packet assembler / disassembler (PAD) used to convert event data from the X.25 OSS network 328 to an SNMS server 302/304. It is a protocol converter. It also services functions such as SWIFT 326 in maintaining communication sessions with each network element and thus eliminating the need for SNMS to do so. The need for SWIFT 326 and LSE 330 represents one embodiment of a typical telecommunications network, where different types of elements are present at locations requiring different transmission mechanisms. SNMS assists with all of the above types of elements.

All network events are entered into the SNMS alert server 302 for analysis and correlation. Any event is also entered into the SNMS Reporting Server 304 to be stored for activity recording purposes. Control system 332, which may be a VAX / VMS system, is used to collect phase and configuration placement data from each network element through the X.25 OSS network 328. Any element such as STP 104 and SP 102 may send the data directly through the X.25 OSS network 328. Elements such as International SSP 316, communicating only in asynchronous mode, use the Packet Assembler / Disassembler (PAD) 318 to connect to the X.25 OSS network 328. The control system 322 then supplies the phase and configuration data to an SNMS phase server 306.

Network topology information is used by the SNMS to implement alert correlation and provide visual display. Most of the topology information is received from the network topology database 334, which in the preferred embodiment is generated and maintained by the order entry system and the network engineering system. Phase data is input from the network topology database 334 and the control system 332 to the SNMS topology server 306. The ability to enter manual overrides through the use of PC 336 is also provided by the SNMS topology server 306.

The SNMS alert server 302 also receives events, in particular DS-3 transmission alerts, from other network management system (NMS) 338. Using the phase data, the SNMS will correlate the event with the event received from the SS7 network element. The SNMS alert server 302 also receives network schedule information from the network maintenance schedule system 340. The SNMS uses this information to account for planned network outages due to maintenance and thus eliminates the need to respond to maintenance-occurring alerts. SNMS also uses this information to proactively alert maintenance personnel to network outages that may affect planned maintenance activities.

The SNMS alert server 302 has an interface with a failure management system 342. The interface allows the SNMS user of client weak station 312 to submit a trouble ticket for an SNMS-generated alert. The interface as opposed to using an SNMS-internal fault management system may be configured to use a number of different types of fault management systems. According to a preferred embodiment, the SNMS image server 308 supports all client workstations at a single site and thus the SNMS image server 308 is a plurality of servers. The geographic distribution of the SNMS image server 308 eliminates the need to send large amounts of data supporting image presentation from the Middle East location to each workstation. Only data from alert server 302 and reporting server 304 and topology server 306 is sent to the workstation site, thus saving network transmission bandwidth and improving SNMS functionality. According to an alternate embodiment, the image server 308 may be located at the center.

According to FIG. 4, a high-level process flowchart represents an SNMS logic system component. At the heart of the process is process event 402. The component serves as a monetary cop for the SNMS process. Process event 402 is primarily run on SNMS alert server 302, which is responsible for receiving, processing and storing events from other SNMS components and supplying processed event data to reporting and display components. The process event process 402 is shown in more detail in FIG.

The receiving network event component 404, which is primarily executed on the alert server, receives network events from various SS7 network elements (STP 104, SP 102, PMU 106, etc.) via systems such as SWIFT 326 and LSE 330. The component analyzes the event and sends it to process event 402 for interpretation. The receiving network event process 404 is shown in more detail in FIG.

The process topology component 406, which is primarily run on the topology server 306, receives network topology and configuration data from the SS7 network element and from the manual override 336 via the control system 332 from the network topology database. The data is used to correlate network events and perform impact assessment on the events. The data is also used to provide a visual presentation of the event. Process phase 406 analyzes, stores and transmits the phase and configuration data to process event 402 for interpretation. The process phase process 406 is shown in more detail in FIG.

The prescriptive algorithm component 408, which is primarily run on the alert server 302, specifies the particular analysis and interpretation used by the SNMS. The definition is then loaded into process event 402 for use in analysis and interpretation. The algorithm is defined by code stored and programmed in a software module. The programmer simply programs the predefined algorithm into the software module, which is then used by process event 402. The algorithm is procedural in nature and based on network topology. The algorithm consists of a simple rule that can be written in dedicated words and dynamically converted by the SNMS user, and a rather complex rule that is programmed within the SNMS software code range.

The receiving NMS data component 410, running primarily on the alert server 302, receives events from other network management system (NMS) 338. The event includes a DS-3 transmission alert. The receiving NMS data component 410 also receives a network maintenance event from the network maintenance schedule system 340. The receiving NMS data component 410 then analyzes the event and sends it to process event 402 for analysis. Display alert component 412, which is primarily executed on video server 308 and alert server 302, includes a graphical user interface (GUI), uses associated data provided by process event 402 and includes associated software to support phase and alert presentation. It also supports user interactions such as alert cancellation, receipt notification and submission of trouble tickets. It enters process event 402 for the storage of the interaction and the required data update. The display alert process 412 is shown in more detail in FIG. 8.

The data reporting component 414, which is primarily run on the reporting server 304, supports phase and alert reporting using data supplied by process event 402. Data reporting process 414 is shown in more detail in FIG. 9.

5 shows a process of detailed process event component 402. This process is the main process of SNMS. The process event component 402 analyzes each event and identifies the type of event to receive general purpose events from other SNMS components and extract related data. If the event is an SS7-related event, process event 402 applies the selected algorithm, such as generating an alert or correlating the current alert.

The first three stages 502-506 are initialization processes that are run at the beginning of each SNMS session. Step 502-506 sets the state in which the system can be executed. 510-542 then executes as a continuous loop. In step 502 the current phase data is read from the phase data storage on the phase server 306. The phase data store is created in process phase process 406 and input into process event 402 as shown in FIG. The read phase data is analyzed at process phase 406 and thus is read as a standardized event that is easy to process by process event 402 at step 502.

In step 504, the algorithm generated in the prescribed algorithm component 408 is read. The algorithm determines what action the SNMS takes on each alert. SNMS has a map of the algorithm invoked for this type of alert.

In step 506, alarm records from the error management (FM) reporting database generated in data reporting process 414 are read. All previous alarms are discarded. Any alarm acting on a line or node that is not present in the phase (read in step 502) is discarded. Also any alerts that do not map to any current algorithm (read in step 504) are discarded. The alarm is only read at initialization. Additional alert records are retrieved from the database inside the process event 402 component to improve system functionality. Step 506 includes an initialization process; Once the current phases, algorithms, and alerts have been read, the SNMS can begin the process of continuing reading, processing, and storing events.

The process begins with step 510, where the process receives and identifies the next pending event. The queue is a First In / First Out (FIFO) queue providing network process, phase event and NMS event to the process event component 402. In other words, the alert data read in step 502 is initialization data read at the start of the system state. In step 510 Ongoing events are continuously read from process components 404, 406 and 410. The event has already been analyzed and received as a standardized SNMS event. The SNMS then identifies the type of event that is being received. The event is discarded if the event turns out to be earlier than a certain threshold, such as about an hour ago.

Steps 512, 520, 524, and 534 determine how the SNMS should handle the event based on the event type identification generated in step 510.

In step 512, if the event is determined to be phase data, the SNMS performs a GUI display to indicate the new phase in step 514. Then, in step 516, the SNMS performs a match with the active alarm to discard any alarms that are not mapped to the new phase. In step 518 the new phase data is written to the phase data storage, which is stored in the SNMS phase server 306.

In step 520 the event is stored in the FM reporting database on a SNMS reporting server 304 for reference by subsequent SNMS rules.

If in step 524 the event is determined to be a defined SS7 network event then in step 526 one or its director's algorithm will be loaded for the event. Such an algorithm may use data retrieved from network management system 338 and network maintenance schedule 340 and network topology 334.

For example, when each line level algorithm generates an alert, the algorithm performs a check on the network maintenance schedule 340 and NMS 338 records. Each alert record is marked if a particular line is present in the maintenance window (network maintenance schedule 340) or transferred to DS-3 with a transmission alert (NMS 338). The TDRL network topology database 334 provides DS-3 in the DS-0 translation table when the SS7 circuit is running at the DS-0 level. Any DS-0 line in DS-3 is marked as potentially included in a transmission error. The cancellation record from NMS 338 will cause the operational SNMS line level alerts to be evaluated so that the associated NMS 338 association can be eliminated. The SNMS cancel event will cancel the actual SNMS alert. The GUI filter allows the user to mask out alerts that match the maintenance window and are involved in transmission errors because the alerts do not require SNMS operator operation.

In step 528 an active alarm is matched with a new alarm generation and cancellation resulting from step 526. In step 528 the GUI display is updated. In step 532 the new alarm data is stored in the FM reporting database.

In operation 534, the event may be determined as a timer. SNMS algorithms sometimes need to delay additional processing of certain conditions for defined periods of time, such as duration and rate algorithms. The delay timer is set for this state and processing of the new SNMS event continues. When the time elapses, SNMS treats the time as an event and runs the appropriate algorithm.

For example, an SS7 link can momentarily prevent the possibility of resuming within a few seconds, or it can fail for a very long time due to a serious stop that requires action. When the SNMS receives the event, the SNMS may place a timer of about one minute in the event. If the event is deleted within 1 minute, the SNMS does not take any action on the event. However, if the event does not change after the one minute timer has elapsed (if the SS7 link is still down), the SNMS will take action.

In step 536 an appropriate algorithm is invoked to take such action. In step 538, the active alarm is matched with the active alarm generated or deleted in step 536. In step 540 the GUI display is updated. In step 542 new alarm data is stored in the FM reporting database. As mentioned above, the SNMS operates continuously in connection with receiving and processing events. After the data storage in steps 518,522,532 and 542 the process returns to step 510.

In Figure 6, the detailed process of the receiving network event component 404 is shown. The component collects events from the SS7 network element via data transfer mechanisms such as Async Data network 320 and SWIFT 326 and X.25 OSS network 328 and LSE 330. The event is received by the SNMS alert server 302 in a First In / First Out (FIFO) queue. In steps 602 and 604, events from the SS7 network element are collected by mainframe applications outside the SNMS, such as SWIFT 326 and LSE 330, and the protocol of event data is converted from network element-specific protocol to SNA or TCP / IP. According to an embodiment, the SNMS may also have software running on a mainframe that converts the protocol into a protocol recognizable by the SNMS RTUFBo server 302. The event data is then sent to the SNMS alert server 302 via SNA or TCP / IP. Preserve signaling event list 608 of all SS7 event types that can be SNMS processed. In step 606 the SNMS examines the signaling event list 608 and if the current event is found in the list, the SNMS traps the event for processing. If the event is not found in the list, the SNMS discards it.

In step 610 the event is analyzed according to a defined analysis rule. The analysis rule 614 specifies which item should be extracted from what type of event and which SNMS code should be programmed. The event analysis on step 610 extracts only the event data items needed in the alert algorithm or display. Also input to step 610 is a scheduled event 612 from the network maintenance schedule 340. Scheduled event 612 is used to identify each network event collected at step 602, which may be scheduled network maintenance. This allows the SNMS operator to account for the network outage due to planned maintenance.

In step 616 the analyzed event data is used to create standardized event objects in the SNMS resident memory for use by other SNMS processes. The event object is read into the main process which is process event 402 in step 510.

7 shows a detailed process of the process phase component 406. The process component retrieves network topology and configuration configuration data from three types of signal sources for use by other SNMS processes, generates standardized phase data records, and stores the data. In particular, in step 502 the process component 406 feeds the active phase data to a process event 402 executed on the alert server 302.

In step 702, the SNMS phase server 306 collects phase data from three different signal sources. The SNMS topology server 30 collects the current connection and configuration configuration data generated by the SS7 network element via the control system 332. The SNMS topology server 306 collects topology data input to the order entry and engineering system and stores it in the network topology database 334. The topology server 306 also accepts a manual override 336 through the workstation. The collection of data from the phase database 334 and the control system 332 occurs on a periodic basis and runs independently of the SNMS alert server 302. Unlike the prior art using data retrieved from PNU 106, SNMS receives phase data from all types of network elements, including network elements that are not connected to PMU 106, as shown in FIG. SNMS also uses data that represents the topology of foreign networks such as Local Exchange Carriers (LECs) or international carriers. The data is used to implement impact imposition that will allow the SNMS user to determine the facts such as which end customers can be affected by SS7 link outages. This type of phase data is collected and used by SNMS, and for example for the SS7 link between STP 104 and Switch / SSP 102 the data is received by a network order entry and engineering system. A brief description is given below.

STP Link ID Identifies each SS7 link to the STP.

Switch Link ID Identifies each SS7 link to the Switch / SP.

STP Link Set Identifies the trunk grouping of links to the STP.

Switch Link Set Identifies the trunk grouping of SS7 links to the Switch / SP.

MCI / Telco Line ID Identifies the SS7 link to an external system. For an interface in two different networks, each ID (MCI ID and Telco ID) provides an identification of the SS7 link for each network (MCI and Telco in this embodiment).

Link Type Identifies the SS7 link of this type.

SLC signal link code

For switched voice networks supported by SS7 data is received by network order entries and engineering systems and used to perform SS7 event impact imposition.

Voice Trunk Groups Voice Trunk Groups Supported by Each SSP 102

For SS7 connection of domestic STP 104g to international STP 104h, data is received by network order entry and engineering system.

Circuit ID Identifies the SS7 link to an external system

SLC signal link code

For the purpose of implementing impact imposition, local exchange carrier (LEC) NPA / NXX imposition and END OFFICE to access tandem homing arrangements are received by a call area database generalized by Bellcore's Local Exchange Routing Guide (LERG).

LATA local access transport area

NPA / NXX Numbering Plan Area / prefix (conventional)

END Office LEC Customer Serving Node

Access Tandem LEC End Office Hub

Foreign network STP 104 clustering and SSP 102 homing arrangements are received by the SS7 network via the control system.

Identify point code SS7 nodes (conventional)

Data identifying any aspect of each network element is received by a switch configuration batch file, which is located in an external system.

Data mapping each network DS-0 onto DS-3 is received by a network topology database. The data is used to assign a DS-3 alert received by the NMSD to a DS-0 level line.

Data required to overwrite data acquired through an automated process is provided by manual override.

Returning to step 704 in FIG. 7, various phase data is analyzed to extract the data items needed by the SNMS algorithm. The data is then normalized to an event record that can be processed by process event 402.

In step 706, the standardized data record is validated against other data. For example, line topology recording is a validity check for node topology recording to ensure that end nodes are identified and defined.

In step 708 the phase data is stored in the phase server 306 of FIG. 3 even in an associated database such as that provided by Sybase.

In step 710 the new phase record is transferred from the upper right server 306 to a main SNMS process running on alert server 3O2 and compared against an active configuration batch (a configuration batch currently loaded into memory). The active alarm and the GUI display are coordinated with removing alarms related to phase entries that do not exist.

In step 712 the phase is stored in the alert server 302 (for use of process event 402) in the form of a flat file for performance reasons. The flat file then reflects the topology server 306 database from step 708. The flat file can only be accessed by the main process. In step 714 the new phase write is loaded into the active SNMS memory and a new process requiring idol data now uses the new configuration batch.

8 details the process of display alert component 412. The process component provides the result of SNMS processing to the user (referred to as an operator) and accepts operator input as an action to be executed in the SNMS. Thus, the process between display alert 412 and process event 402 has two paths, the presence of the display alert process 412 executed for each operator logged onto the SNMS when there is a single process event process 402 executed for the entire SNMS system. Note that there are other examples. That is, each operator causes a separate execution of display alert 412.

When the operator logs on to SNMS, first steps 802-808 are executed as initialization steps. From this step steps 810-838 operate as a continuous loop. Initialization provides each operator with a state of the system that can operate. In step 802 the current phase is read and displayed via a graphical user interface (GUI). Each operator has its own GUI process that is initialized and terminated based on operator requests. Each GUI process manages its own display independently. Any state change is controlled by each process.

In step 804, a filter that defines a particular operator view is read. Each operator can define the view that the GUI process will display. Filter parameters include:

1.Call alert or use difficulty alert or both

2. Acknowledgment alarm or non-acknowledgement alarm or both

3. Alerts on the line in the maintenance window or alerts on the line that are not in the maintenance window or both.

4. Alerts on the line with associated dedicated alerts (DS-3 alerts via stop ID) or alerts on the line without associated transmit alerts or both.

5. Alerts with specific severity.

6. Alarm on Mode / Line with the above mentioned Customer ID.

7. Alarm on international line or alarm on domestic line or both.

The operator's GUI display is updated at initialization in step 804 and when a filter change is requested in steps 828 and 830. An instance of each particular operator of the display alert 412 process opens a connection with process event 402 to ensure that only alert records relating to the filter of the particular operator are sent. In step 806 the process of the particular operator writes itself to process event 402 to identify what alert has been sent. In step 808 the GUI display is provided to the operator.

Continued execution of display alert 412 is initiated at step 810. As defined by the operator filter, each event to be retrieved and provided is received and identified. Steps 812, 816, 820, 826, and 826 determine what the SNMS should do to the event based on the event type identification made in step 810. If it is determined in steps 812 and 816 that the event is an alarm update or phase update, the operator GUI display is updated to reflect this in steps 814 and 818, respectively. The next event is then received at step 810.

In step 820, if it is determined that the event is operator operation, two actions are required. First, in step 822 the GUI display of the operator is updated to reflect the state change. Then, in step 824, a state change update is sent to the main process. Process event 402 may be received and respond to the state change to allow the state change to be reflected in the SNMS record and other GUI processes (for other users).

In step 826, if it is determined that the event is an operator display run, then it is determined whether the run is a filter change request or a display request. If it is determined in step 828 that it is a filter change request, then in step 83O the GUI process records in process event 402 such that an appropriate alarm record is sent. If it is determined in step 832 that it is an operator display request, then in step 834 the request display is provided to the operator. The display request may include:

1. Node Details and Connections

2. Line connection

3. Link set access

4. Unknown phase alerts (alerts to objects not specified in the phase database)

5. STP pair access

6. Nodes contained within LATA

7. Home / Mate Connection (for non-adjacent nodes)

8. NPA / NXX List

9 Trunk Group List

10. Final Office Access Tandem

11. Rule definition help screen (helps the operator understand the actual algorithm used to generate the alert)

12. Execution of advisories (performing operator regulations that must be taken when certain alerts are received)

If at step 836 it is determined that the event is an end request, then the GUI process of the particular operator is terminated at step 838. Otherwise the next event is received at step 810. Within the display alert process, SNMS provides several unique display windows that support error isolation, impact assessment, and fault handling. All of the above GUI displays, including node and line symbols, are active windows in the SNMS (ie, the screen is dynamically updated when the alert status of the node and line changes). All of these displays may be due to the set of MCI phase sources used within the SNMS. SNMS has the extended phase processing of SNMS used in operator displays.

A. SNMS Line Map

The window displays phase and alarm status information for the selected link set. When a network event is received, the SNMS recognizes the relationship between the end points and isolates the error by reducing the occurrence alarm. The display allows the operator to examine the set of links as seen from both sides of the signaling line (from the perspective of the node).

B. SNMS Connection Map

The window provides a cluster view of the signaling network of the MCI. Both non-MCI nodes and MCIs connected to the MCI STPs in the cluster are displayed along the relevant link set. The cluster view is important because a single STP error / isolation is not a service impact but cluster error is not important because every MCI SP has connectivity with both MCI STPs in the cluster.

C. SNMS Non Adjacent Map

The window provides an STP pair view of the selected LEC signaling network. All LEC SPs, STPs and SCPs (with signaling relationships with the MCI network) connected to the LEC STP pair are displayed. The area of responsibility of the MCI does not include the LEC STP to the LEC SSP signaling link and therefore no link set is displayed. The display allows the SNMS operator to inspect the LEC signaling network as seen by the MCI node.

D. SNMS LATA Connection Map

The window provides a map of all LEC owned nodes located within a particular LATA. In addition, the MCI STP pair serving the LATA is also displayed according to a set of related links (as applicable). The display allows the operator to closely examine a particular LATA when / if a problem is revealed within the LATA. The LATA problem may introduce a problem inside the MCI network, although outside the control domain of the MCI, because signaling messages are shared between the networks. In addition, MCI voice calls received from the specific LATA may be affected by the LATA suspension.

E. NPA-NXX Information List

The window provides a list of NPX-NXX information served by a particular LEC switch. The display is very useful during the impact assessment period (i.e. the NPA-NXX information is useless if the particular LEC switch is isolated).

F. Final Office Information List

The window provides a list of LEC final office nodes located in a particular LEC access tandem. The display is very useful during the impact assessment period (i.e. the end office is useless if the particular LEC tandem switch is isolated).

G. Trunk Group Information List

The window provides a list of MCI voice trunks connected to a particular MCI switch and the LEC end office switch to which it terminates. The display is very useful during the impact assessment period (i.e. the end office is impacted when the MCI switch is isolated). The display can also be used for the selected LEC end office switch.

H. Filter Specification Window

The SNMS operator can define the scope of the display as follows:

Type of alarm to be provided;

-Severity of alarms to be provided

Received notification alerts or unreceived notification alerts or both.

An alarm on the line inside the planned stop window or an alarm on the line outside the planned stop window, or both

-Alarms that are not the result of certain transmission network outages;

-An alert on a particular customer node or an alert on a line connected to a specific customer

1. Fault Ticket Window

The SNMS operator may open a trouble ticket on a signaling alert. The trouble ticket is opened in MCI's trouble ticket system. The operator can also display the status of the current trouble ticket.

9 illustrates the process of data reporting component 414 in detail. The process component runs on the reporting server 304 to store SNMS processing data and provide a report.

The standardized network element (NE) event record 914 is received with a location specific time stamp. In step 902 the time stamp is changed to Greenwich Mean Time (GMT) to allow a standardized report to be generated.

In step 904 all received data is stored in each database table. Data can also be stored on tape or disk for long term storage. The data includes performance statistics from SNMS-occurring alert 916, standardized phase record 918 and PMU 920. The data may also include raw data, such as DS-3 alerts from NMS 328 and network maintenance schedule data 340.

In step 906, a report is generated. The report can be on-demand or form report. The report can also be generated as soon as requested or on a schedule. The report may be provided in some manner, but is not limited to electronic mail 908, X-terminal display 910 and printed report 912.

XII. Video telephony through the port

The logical next step from voice over the port is video. Today's computers can make mutual image "calls" when connected to any type of computer network. However, most people connect to a computer network only by making a call with another modem on a computer connected to the network from their modem on the port, and as a result they can then call another computer on the network. The computer is in turn connected to another network computer by a modem. It is simpler (and more efficient) to call another person directly on the port and allow modems to communicate with each other directly without network overhead. ITU Recommendation H.324 describes terminals for low bit rate (28.8kbps modem) multimedia communications using a V.34 modem operating on a port. H.324 terminals may implement any combination including real-time audio, data and video or video telephony. The H.324 terminal can be integrated into a personal computer and provided to standalone devices such as video telephony and television. Support for each media type (voice, data, video) is optional, but if supported, the ability to use a particular common mode of operation is required, so that all terminals supporting the media type can interact. H.324 allows more than one type of channel to be used. Other recommendations in the H.324 series include H.324 multiplex (combination of voice, data and video), H.245 control, H.263 video codec (digital encoder and decoder) and G.723.1.1 audio codec. .

H.324 uses the logical channel signaling procedure of ITU Recommendation H.245, which describes the content of each logical channel when the channel is opened. The procedure is provided to allow each user to use only the multimedia capabilities of their device. For example, a person attempting to make a video (and voice) call to someone who has no video capability but only voice capability can still communicate by voice (G.723.1.1).

H.324 by convention is a point-to-point protocol. To confer with two or more others, a multipoint control unit (MCU) is required to act as the video-calling bridge. H.324 computers can interact with H.320 computers on ISDN as well as with computers on wireless networks.

A. Components of a Video Telephony System

1. DSP modem pool with ACD

The Digital Signal Processor (DSP) modem pool is a modem bank with the ability for each modem to be programmed for a particular function (new V. modem protocol, DTMF detection). The call is routed from the MCI switch to the ACD. The ACD has a matrix that the DSP modem can use. It can also communicate with ISNAP, which makes group selection to determine which group of agents are free to handle the call. According to an alternative embodiment, the DSP resource may be directly connected to a deployment, or switch, without an ACD. In this embodiment, the DSP resources are managed using NCS-based routing steps.

2. Agent

The agent can be a human video operator (video capable MTOC), or an automated program (video ARU). The ACD knows which agent port is available and connects the agent to the agent port.

3. Video on Hold Server

If the ACD does not have an available agent port, then the caller is connected to the video On Hold Server until the ACD finds a free agent port, which is used for advertising and other non- Has the ability to send interactive video.

4. Video mail server

Video-mail messages are stored here. Customers can manage their mail and record greetings stored on the server.

5. Video Content Engine

Video content on demand is located on the video content engine. Images stored therein may be pre-recorded video-conferences, training videos, and the like.

6. Reservation Engine

When people want to plan a multi-group video-conference, they should list the conference participants and times in detail in the system. The configuration may be done with the help of a human imaging operator or by any other form entry method.

7. Image Bridge

Since H.324 is a point-to-point protocol, the multi-point conference unit (MCU) needs to manage each participant and resend the video flow as appropriate. MCU conferencing could be used for customers with H.324 and H.320 compliant systems.

B. Scenario

A computer or set-top TV has a modem for use via H.324 compliant software and POTS that is very suitable for 28.8 kbps (V.34) or higher. One purpose is to call another group. If they do not answer or are in a call, the sender has the option to leave a video-mail for the called party. Another objective is to plan and participate in meetings of three or more participants.

C. Connection Setup

19B shows a call connection setup according to a preferred embodiment. There are three ways to make a video call to someone. The first way is simply to call him. If the destination is busy or does not answer then the caller makes another call with 1 800 VID MAIL and executes the appropriate procedure as follows.

When the user dials "1 800 VID MAIL" at 1, the ACD on the DSP modem pool will connect the switch to Modem 2 and the port to Agent 3. The user log-in to the system of a particular custom terminal program using the H.324 bandwidth data flow section (using the ITU T.120 standard) then invokes a V-mail data interface (VMID). From the graphical user interface, icons, or other menus, the caller can choose to:

-Randomly reading or searching a directory of video-capable MCI customers

Invoking another H.324 compliant software program

-Making video-mails for Store & Forward for late arrivals

-Personalize and record video-mail greetings

-Viewing and managing their video-mails, or

Viewing the selection from the archive (Video On Demand)

According to an alternative embodiment the user may dial-in "1 800 324 CALL" to call the number. Then, if the called number is 1 310 375 1771, the modem dial string reads "ATDT 1 800 324 CALL ,,, 1 319 375 1772" (the comma ',' indicates that the modem will pause during the dialing call. Will be When a connection to 1 800 324 CALL is made, the connection is made from the source to ARU 5a from MCI switch 1 selected by ACD 2a, 3a.

The ARU 5a detects the DTMF tone entered through the telephone keypad or another device generating the DTMF tone to obtain the called number. The originator remains on hold when making separate calls to the ARU 5a called numbers 5a, 6a, and 7. When the destination responds, the sender is connected to the destination and both modems can be connected and the ARU 5a is recovered. If the called party is busy or does not answer, the call is forwarded to the 1 800 VID MAIL or agent via the DSP modem pool 2. The agent will make an H.324 connection with the caller and inquire (or provide assistance) about their called number. The structure of the alternative is similar to how faxes are detected and transmitted in the directlineMCI system as discussed with respect to the alternative embodiments.

D. Calling Destination

The video 0n Hold Server provides the video input to the H.324 connection 4 when the called number is known. A new call is made from agent 5.6 to called number 7. One concern that needs to be interpreted in implementing the detailed embodiments requires the determination of whether the modem can be re-synchronized without being offline after switch operation. If the called number responds and it is a modem, the connection must be made at the same speed as the source modem speed. After modem handshaking is performed, the ACD instructs the switch to recover the agent 3.5 and to restore the modems 2 and 6 and connects the source to destinations 1 and 7. The destination PC recognizes that the connection is an H.324 call (fax, not other) and the video-call proceeds.

According to an alternative embodiment, the destination responds and a connection is made if it is a modem. The two H.324 calls then use two DSP modems. The agent can recover from both calls 3 and 5. Input data from each call is copied to the other calls 2 and 6 above. In this manner the agent can examine the video call to the Video Store & Forward 9. When one connection misses the carrier, the video-call is complete and the modem carrier for the remaining call is missed.

E. Recording Video-Mail, Store & Forward Video and Greeting

If the called number does not answer or is busy, the video mail server sends the appropriate video-mail greeting for the called number 8 owner. The caller then leaves a video-message, which is stored in the video mail server. The video record for Store & Forward video is exactly the same as leaving a video message as described above, and parameters such as called number, dispatch time and other voice S & F functions currently available can be entered via the VMDI or the Human Video Operator (or Auto). Video ARU).

If someone can't reach you because you're busy or not answering, recording a personalized greeting for playback is similar to leaving a video-mail. The selection of whether to record is made via the VMDI or in communication with a human video operator.

F. Search of video-mail and order video

The user may choose to poll the user video-mail periodically for new messages, or have the video mail server call the user periodically when the user has a new waiting message. Configuration deployment is done through the VMDI or human video operator. Managing and inspecting video-mails is also performed through VMDI or communicated with human video operators.

The selection of the video view for the ordered video (VOD) is made via VMDI. The video may be a pre-recorded video-conference, training video, or the like and may be stored on an image Content Engine 9.

G. Video-Conference Scheduling.

Users can navigate through VMDI or Internet 10 WWW forms or communicate with human video operators to schedule multi-branch meetings. The information is stored in the reservation engine. Other meeting participants receive schedule notifications by video-mail, e-mail messages, and the like. All registered meeting participants can choose to be reminded via video-mail (or e-mail, voice-mail, paging service, or any other available notification method) at a special time (eg one hour before the meeting). will be. The MCU (video bridge) may call each participant 12 and the H.324 user may dial call to the MCU at the scheduled time 12.

XIII VIDEO TELEPHONY OVER THE INTERNET

19E shows a structure for transmitting a video call over the Internet according to a preferred embodiment. Video conferencing based on Real-Time Transfer Protocol (RTP) RTP refers to voice, video and data transmissions summarized in messages. For a video-conference session based on RTP, the end user station first establishes a dial-up point-to-point (PPP) connection with the Internet used to send the RTP message. Voice information is compressed according to the G.723.1.1 voice codec (coder-decoder), video is compressed according to the ITU H.263 video codec standard, and data is transmitted according to the ITU-T.120 standard.

RTP is a protocol that provides support for applications with real-time state quantities. UDP / IP In its initial target networking environment, RTP is transport independent for use on IPX or other protocols. RTP does not address resource reservations or the issue of queries of service control. Instead it relies on resource reservation protocols such as RSVP. The transport service familiar to most network users is either a point-to-point or unicast service. This is a standard form of service provided by networking protocols such as HDLC and TCP.

Broadcast services are somewhat less commonly used (on a wire-based network, anyway). Broadcast over large networks is unacceptable (because broadcasts use network bandwidth everywhere, regardless of whether a private sub-net is involved), so broadcasts generally use LAN-wide usage. (Broadcast service is provided by a low-level network protocol such as IP). Even on a LAN, broadcasts are sometimes undesirable because the broadcaster requires that all devices perform processing to determine whether all devices and the broadcast data are involved.

A more practical data transmission service for a potential wide audience is multicast. In the multicast model over the WAN, only hosts that are actively involved in a particular multicast service will have the data routed to them. This prevents bandwidth consumption for the link between the sender and receiver of the multicast data. Many interface cards on a LAN provide the convenience of the interface card to automatically ignore multicast data that does not record relevance; This results in avoiding unnecessary processing overhead on unrelated hosts.

A. Components

RSVP Routers with Video Broadcasting MBONE capability from Video Content Engine and MCI Conference Space Network. The MCI may have an MBONE network that multi-branches locally and sends multiple unicasts outside the Internet.

RSVP is a network control protocol that can allow Internet applications to obtain special quality of service for their data flow. The RSVP may generally require reserving resources along the data path either ahead of time (not required) or dynamically. RSVP is a component of the "Integrated Services" Internet of the Future, which provides quality performance and real-time quality of services. Embodiments are described in detail in the specification as described below.

When an application on a host (end system) requests a specific QOS for data flow, RSVP forwards the request to each router along the path of the data flow and maintains the router and host state to provide the requested service. Used. Although RSVP has been refined for the setup of resource reservations, the RSVP can easily adapt to transferring other kinds of network control information along the data flow path.

1. Directory and Registration Engine

When people are connected to the Internet (via modem dial-up, direct access, etc.) they can register themselves in the directory. The directory is used to determine if a particular person can attend the meeting.

2. Agent

The agent may be a human video operator (image Capable MTOC) or an automatic program (image ARU). Internet ACD according to a preferred embodiment is designed so that the agent port can be managed. The ACD knows which agent port is available and connects the agent to an available agent port. If the ACD does not have an available agent port, then the caller is connected to a video On Hold Server, which is capable of operating advertising and other non-interactive video until the ACD finds a free agent port. Has

3. Video Mail Server

Video-mail messages are stored here. Customers can manage their mail and record greetings to be stored on the server.

4. Video Content Engine

The custom video content is located in the video content engine.

The video stored therein may be a pre-recorded video-conference, training video, or the like.

5. Conference booking engine

When people want to plan a group video conference, they can specify the meeting participants and time on the system. The configuration may be done with the help of a human image operator or any other form of entry method.

6. MCI Meeting Space

This is the virtual reality area where customers can appear.

All attendees are personalized as "avatar". Each Aberta has many capabilities and features, such as visual identity, video and audio. Alberta interacts with each other by coordinating various objects that represent document sharing, file transfers, and so on.

7. Virtual Reality Space Engine

Meeting space is created and managed by the virtual reality engine.

The virtual reality engine manages object manipulation and other logical descriptions of the conference space.

B scenario

Assume that the user is currently connected to the Internet. The user can use H.263 compliant system software using RTP (as opposed to TCP) over the Internet. If the user also attends a VR MCI meeting-space and wants to create / view a video-mail, the user can join a VR session.

C connection setup

The easiest way to make a video call to someone on the Internet is to make the call simply without having to navigate through menus and options as an initial phone call. However, if the destination is busy or does not answer, MCI provides a service for depositing messages. Customers can log in to a telnet server (eg telnet vmail.mci.com) or use an order-producing client or WWW (eg http://vmail.mci.com). The service menu is referred to as a V-mail data interface (VMDI) similar to VMDI that can be used when dialing through a port as described above.

From the menu the caller can select:

Sparse reading and searching directories of video-capable MCI customers

Invoking another H.263 compliant software program

Image-mail generation for accumulation and delivery in case of delay

-Personalize and record their video-mail greetings

-Viewing and managing their video-mails, and

Viewing selections from the recording library (Video On Demand)

When the user describes the call participant in detail by indicating the destination name, IP address or other ID, the directory is checked. It is possible to determine whether the destination can accept the call without the actual call; Because it may be determined that the called party can accept the call and thus the source video client may be informed that the destination may be connected. If the caller uses a WWW browser (eg Netscape Navigator, Microsoft Internet Explorer, internetMCI Navigator, etc.) to access the VMDI then the call is automatically initiated using a Java, JavaScript or Helper App. If the call cannot be completed, you can leave the picture-mail.

D. Recording Video-Mail, Store & Forward Video and Greetings

If the agent determines that the called party is unavailable (off-line, busy, no answer, etc.), the video mail server will do an appropriate video-mail greeting for the owner of called number 8. The caller then leaves a picture-message, which is stored in the picture mail server. The image record for the accumulation & transfer (S & F) image exactly matches the left image-message described above. Parameters such as called number forwarding time and other voice S & F functions that can be used now are entered through the VMDI or communicated with a dormant picture operator (or an auto picture ARU). Customers can record their own personalized greeting cards for callers who are busy or unresponsive to reach them. This is done in a manner similar to the left picture mail communicated via the VMDI or with a human picture operator.

E. Retrieving Video-Mail and Video On Demand

The user can choose to either periodically poll their videomail for new messages or have the video-mail server call them periodically when they have new messages waiting. Configuration arrangement is performed through the VMDI or human image operator. Management and inspection of image-mails are also executed via the VMDI or communicated with human image operators. Selection of the visible picture for the ordered picture VOD is provided via the VMDI. The picture may be a pre-recorded picture-conference, training picture, and the like, and is stored in an image content engine.

F. Video-Conference

A user may navigate through the VMDI or Internet 10 WWW format or communicate with a human video operator to schedule a meeting in a meeting space. The information is stored in conference reservation engine 8. Other meeting participants will be notified of the schedule by video-mail, e-mail message or otherwise. An optional reminder is provided to all registered meeting participants at a special time (eg, one hour before the meeting) via video-mail (or e-mail, voice-mail, paging service, or other available notification method).

G. Virtual Reality

The virtual reality space engine creates a virtual meeting place for multi-group meetings. Execution of the interface includes an embodiment based on VRML. Each is under Aberta's control. Each Averta can have many other functions, such as visible images (static images or vivid images "faces") and voices (voice or music). Data exchange and cooperation are all actions that can be executed in each VR meeting room. The private MBONE network allows for multi-casting of the data flow of conference members. Since everyone has a different view when interacting in VR-space, the VR-space engine broadcasts all of its input H.263 flows to everyone by multi-casting only their Aberta GM in their respective views. Can be optimized to cast.

XIV. Video-conference structure

MCI video-conference describes a structure for multimedia tones including real-time voice, video and data or any combination including video telephony. The structure also defines inter-operation with other video-conferencing standards. The structure also defines a multi-point configuration arrangement and control, directory service and image mail service.

A. Function

The video-conferencing structure is a multimedia service system and is designed to provide a number of functions and features, including the following.

Point-to-point phone

Multimedia video-conference with MCU and multimedia information processing for control

Gateway support for interaction with other video-conferencing systems based on ITU H.320 and ITU H.324 standards

Support any combination of real-time voice, video and data

Multimedia information flows are transported between end-users using the standard transport protocol RPT.

Support for dynamic capability exchange and mode selection, such as ITU H.263 video and ITU G.723 voice between end-user terminals

19C shows a video-conference structure according to a preferred embodiment. The components and details of the video-conference structure are as follows.

B. Components

The video-conferencing system consists of a set of components comprising:

End-user terminal

LAN interconnection system

ITU H.322 server

Support service unit

1. End-user terminal

The end-user terminal is the last point of communication. The user communicates and joins in a video conference using the end-user terminal. End-user terminals, including ITU H.322 Terminals 1 & 8, ITU H.320 Terminal 9, and ITU H.324 Terminal 10, are interconnected through the ITU H.323 Server providing call control, multipoint control, and gateway functions. Connected. End-user terminals are capable of multimedia input and output and include telephone instruments, microphones, video cameras, video display monitors, and keyboards.

2. LAN interconnection system

The LAN interconnect system 3 is an interface system between the MCI switched network 2 and other H.323 systems including H, 323 server 4, video content engine 5, video mail server 6, and also H.323 directory server 7. . Establish a communication link with an MCI switched network and communicate with the H.323 server through the LAN interconnect system. The LAN interconnect system provides ACD-like functionality to the H.323 video-conferencing system.

3. ITU H.323 Server

H.323 Server 4 includes call control, multipoint control, multipoint processing, and gateway services for interaction between ITU H.320 and ITU H.324 and terminals supporting many different video-conferencing standards. Provide various services.

The H.323 server consists of a set of components that communicate with each other system and with other external systems such as end-user terminals, video mail servers, and H.323 directory servers. The various components of an H.323 server include:

H.323 gatekeeper

Operator Service Module

H.323 multi-point control unit (MCU)

H.323 gateway

4 Gatekeeper

The H.323 gatekeeper provides call control services to H.323 terminals and gateways. The gatekeeper provides a variety of services, including:

Call control signaling with terminal, gateway and MCU;

Admissions Control for access to the video-conferencing system;

• call permission;

Bandwidth control and management;

Transport address translation for address translation between various types of interactive video-conferencing systems;

• call management of calls in progress;

• interface with a directory server [7] for providing directory services; And

Interface with video mail server [6] for video mail service.

The gatekeeper uses ITU H.225 flow packetization and synchronization procedures for various services and is tightly integrated with the operator service module to provide manual operator services.

5. Operator Service Module.

The operator service module provides manual / automatic operator service and is tightly integrated with the gatekeeper. Manual or automatic operator terminals located elsewhere on the LAN interact with the gatekeeper through the operator service module providing all of the required operator services.

6. Multi Point Control Unit (MCU)

The MCU is composed of a multi-point controller and a multi-point processor and provides a multi-point control and processing service for video conferencing. The multipoint controller provides a control function to support conferencing between three or more terminals. The multipoint controller performs capability exchange with each terminal in a multipoint conference. The multi point processor provides processing of data flow, voice and / or video including mixing, switching and other required processing under the control of a multi point controller. The MCU uses ITU H.245 messages and methods to implement the features and functions of the multipoint controller and multipoint processor.

7. Gateway

H.323 gateways provide appropriate translation between various transport formats. The translation service includes the following.

Translation of call signaling messages between H.221 and H.225 forming part of the H.320 system

Translation of communication procedures between H.245 and H.242; And

Translation between video, audio and data formats such as H.623, H.261, G.723, G.728 and T.120

The H.323 gateway provides transformations for transport format and call setup and control signals and procedures.

8. SUPPORT SERVICE UNITS

The support service unit includes an H.323 directory server 7, a video-mail server 6, and a video content engine 5 that interact with an H.323 server to provide various services to the end-user terminal. The H.323 directory server provides directory services and interacts with the gatekeeper unit of the H.323 server. The video mail server is a repository of all video mails generated in the H.323 system and interacts with the gatekeeper unit of the H.323 server for the generation and playback of video mails. The video content engine is a repository of all other types of video content that can be served to end-user terminals. The video content engine interacts with the gatekeeper unit of the H.323 server.

C. Overview

Based on the video-conferencing structure, H.323 describes a structure for any combination, including multimedia communications or video telephony, including real-time voice, video and data. H.323 terminal users may participate in multimedia video-conferencing sessions, point-to-point video telephony sessions, or voice-only sessions with other terminal users who do not have video equipment. Gateways may be included for interaction with other video-conferencing terminals based on standards such as ITU H.324.

The structure includes a directory server to provide a complete directory service that includes a search facility. The video mail server is an essential component of the structure for providing recording and playback of video mail. The video content engine also forms part of the overall structure for providing multimedia content delivery services.

H.323 terminals participating in a video-conference or video telephony session communicate with an H.323 server through an MCI switch network. The H.323 server provides various services including call control, information flow transfer, multi-point control and gateway service for interaction with H.320 or H.324 terminals. The server also provides directory services and video mail services.

The H.323 terminal initiating the video call establishes a communication link with the H.323 server via the MCI switch network. Upon entry into the network by the H.323 server, the server provides a directory of other available terminals in a call to initiate a terminal that selects a destination terminal or a group of parties to join a video conference. The server then sets up a communication link with the selected destination terminal or terminals, and finally connects the called terminal with the called terminal / terminal. If the called terminal is busy or unavailable, the server may provide the option to save the video mail to the calling terminal for storing the video mail. The server notifies the recipient of the video mail and provides a recipient service for retrieving the ordered video mail. Additional services, such as order content delivery to an H.323 terminal, are provided and controlled by the H.323 server.

D. Call Flow Example

Call flows for H.323 structures based on video-conference include point-to-point calls and multipoint video-conference calls, including calls to other H.323, H.320, and H.324 terminals. It is described in detail in the form of various calls.

19C shows various call flows according to a preferred embodiment.

1. Point-to-point call

a) Case 1: H.323 terminal to another H.323 terminal

A call initiating H.323 terminal 1 initiates a call to another H.323 terminal [8] via the MCI switched network. The gatekeeper is included in the control of the session, including call establishment and call control. The terminal end-user interface is any commercially available web-browser.

Calling terminal 1 initiates a dial-up call to the MCI switched network;

The call is terminated at the H.323 gatekeeper module of the H.323 server via the LAN interconnect 3 system;

A PPP link is established between the gatekeeper 4 and the calling terminal on a well known untrusted transport address / port;

The calling terminal sends an authorization request message to the gatekeeper [4];

The gatekeeper 4 sends an authorization receipt notification message, communicates with the directory server 7, and sends directory information back to the calling terminal for display on the calling terminal, and the call includes both the point-to-point or conference mode. Is displayed as a web-page following selection of;

• After the exchange of permissions, a setup of a reliable connection is made for the H.225 call control message on a well-known port;

The terminal user selects the point-to-point mode and also selects the destination of the call. This is a setup request message;

Gatekeeper 4, together with the operator service module / operator, continues the call of terminal 8 called with the setup request.

If the setup request fails, the gatekeeper 4 notifies the calling terminal 1 of the failure and provides an option to leave a video mail on the calling terminal 1;

If the user of calling terminal 1 chooses to leave video mail for the user of incoming terminal 8, the gatekeeper 4 establishes a connection with the video mail server 6 and trusts from the mail server 6 for H.245 access. Receive a port address.

Gate 4 additionally establishes a connection for H.225 call control with video mail server 6.

Gatekeeper 4 in turn sends a reliable port address to calling terminal 1 for the H.245 control channel. The gatekeeper 4 may be included in the H.245 control channel communication.

The calling terminal 1 establishes a reliable connection for the H.245 control channel and executes H.245 procedures such as capability exchange, mode selection, and the like.

After the capabilities exchange, the H.245 procedure can be used to establish logical channels for various media flows.

The capabilities exchange also includes the receipt of dynamic port addresses for the transport of various media flows.

The media flow is carried through dynamic ports in the various logical channels.

Once the terminal has finished video mail, the terminal closes the logical channel for video after terminating the transmission of the video flow.

Data transfer is terminated and the logical channel for data is closed.

Voice transmission ends and the logical channel for voice is closed.

H.245 call and delete messages are sent to peer entities.

Calling terminal 1 sends a disconnect message to gatekeeper 7 on the H.225 port, which in turn sends the disconnect message to videomail server 6.

Disconnect message is received and the call is disconnected.

If the setup request succeeds, the called terminal 8 responds with a connect message containing a trusted port address for the H.245 connection.

The gatekeeper 4 responds to the call terminal 1 with a connection message along the port address for the H.245 control channel communication.

Calling terminal 1 sets up a connection for H.225 call control signaling with the gateway 4 and sets up another connection for H.245 control channel communication and responds with a connection acknowledgment message to the gateway 4.

The gatekeeper 4 in turn sends a connection receipt message to the called terminal 8.

The called terminal 8 now sets up the H.225 call control connection and also establishes another connection for the gatekeeper 4 and H.245 for control channel communication.

The terminal establishing the H.245 control channel for reliable communication exchanges capabilities and other initiation procedures of H.245, and the voice channel may be optionally opened before the capability exchange.

A logical channel through the dynamic port following the capabilities exchange is set up for each media flow.

Once the media logical channel is opened through the dynamic port, the media information can be exchanged.

During the session, H.245 control procedures can be invoked to change the channel structure, such as mode control, capability, etc.

H.225 control channels also exist for specific procedures such as those requested by the gatekeeper [4], including call status, bandwidth allocation, and the like.

For termination either terminal may initiate the end video message and stop the video transmission and then close the logical channel for the video;

Data transmission is interrupted and the logical channel for data is closed;

Voice transmission is interrupted and the logical channel for voice is closed;

An H.245 end session message is sent and transmission on the control channel is terminated and the control channel is closed;

The terminal receiving the end session message can repeat the closure procedure and then the H.225 call signaling channel is used for call deletion; And

The terminal initiating the termination may send a disconnect message to the gatekeeper 4 on an H.225 control channel, which in turn sends a disconnect message to the peer terminal.

The peer terminal receives notification of the disconnect being forwarded to the initiating terminal and the call is eventually recovered.

b) Case 2: H.323 terminal to H.320 terminal

Calls initiated from H.323 terminal 1 result in calls to H.320 terminal 9 over the MCI switching network. The gatekeeper, along with the gateway, is called to control the session, including call establishment and call control. The terminal end-user interface is any commercially available web-browser or similar interface.

The call flow is similar to the H.323 terminal calling another H.323 terminal described in the case described above, except that a Gateway 4 component is introduced between the gatekeeper 4 and the called terminal 9. The gateway transcodes H.323 messages, including voice, video, data and control, into H.320 messages and vice versa. If the H.320 terminal 9 initiates a call to an H.323 terminal [1], the initiating dial-up route is executed by the gateway and then the gatekeeper takes over the call control and the call is in an earlier case. Proceed as described below.

c) Case 3: H.323 terminal to H.324 terminal

A call initiating H.323 terminal 1 initiates a call to H.324 terminal 10 through the MCI switching network. Together with the gateway, the gatekeeper is included to control the session, including call establishment and call control. The terminal end-user interface is a web browser or similar interface.

The call flow is similar to an H.323 terminal that calls another H.323 terminal as described in the previous case except that a Gateway 4 component is introduced between the gatekeeper 4 and the called terminal 9.

The gateway 4 transcodes the H.323 message including voice, video, data and control into an H.324 message and reverses it.

When the H.324 terminal 10 initiates a call to H.323 terminal 1, an initiation dial-up routine is executed by the gateway and then the gatekeeper takes over the call control and the call as described in the preceding case. The call proceeds.

2. Multi-point video-conference call

In the case of multipoint video-conference, all terminals exchange initiation call signaling and setup messages with the gatekeeper 4 and then via gatekeeper 4 to the multipoint controller for the actual conference including H.245 control channel messaging. Connected.

Here are some things to consider when setting up a meeting:

After exchanging the start admission control message, the user is provided with a web page with information about the meeting format and a dynamic list of participants.

Later participants are provided with a web page with meeting information and are required to enter confirmation information.

All users are connected to the multipoint controller [4] via the gatekeeper [4].

The multipoint controller [4] distributes information among the various participants.

E. Conclusion

The video-conferencing structure is a holistic solution to multimedia communications including any combination including real-time voice, video and data or point-to-point telephony.

The structure defines the interaction with other systems using the ITU Recommendations.

Other services, including directory services and video mail services, also form part of the overall structure.

XV. Image accumulation and delivery structure

The video accumulation and delivery structure describes an on-demand video content delivery system. The content may include only video and audio or voice. The input signal source for the content is from the current video-conference facility or from any video / audio signal source. The input video is stored in the digital library in various standard formats such as ITU H.320, ITU H.324, ITU H.263 or MPEG and delivered to the client in the required format. Delivery is done at various speeds to the client on the Internet or on a dial-up line including ISDN and with a single store for each different format.

A. Features

The image storage and delivery structure is designed to have a rich set of features and functions, including:

Delivery of custom audio and video;

Support of various compression and transmission standards, including ITU H.320, ITU H.324, MPEG, and ITU H.263 on both Internet Protocol (IP) and Real Time Transport Protocol (RTP);

Support for content delivery over the Internet by dial-up ISDN lines and low speed (28.8 kbps) analog telephone lines;

• support for a single source of content, multiple storage and delivery formats, and multiple transmission speeds; And

Support for managing and archiving content in multiple formats;

B. Structure

19 illustrates an image accumulation and delivery structure according to a preferred embodiment.

C. Components

The image accumulation and delivery structure is fully described by the following components.

Content creation and transcoding.

Content management and delivery.

Content search and display.

1 Content Creation and Transcoding

Input signal sources include analog video, video from a multi-point control unit (MCU) and other video signal sources 1a and 1b. Input content is ITU H.261, ITU H.263, ITU H.320, ITU H.263, ITU H.324, MPEG, and also H.263 via RTP and H.263 via Internet Protocols 2 and 3 It is converted to standard formats such as those that support it. Input can be initially coded in H.263, optionally transcoded into a variety of other formats, and stored in two. The transcoded content is stored on different servers, and the server for each content type serving a variety of clients supports different formats 5a, 5b, 5c, 5d and 5f, respectively.

2 Content Management and Delivery

Content is stored on a variety of servers, each of which supports a specific format, which is managed by a digital library consisting of:

-Index server for index management and content archiving 4

Object Servers 5a, 5b, 5c, 5d, 5e and 5f for content storage

Proxy Client, which interacts with other clients requesting content and as a front end to the index and object servers.

Content delivery is by:

-Internet

Dial-up ISDN line

-Dial-up analog phone line in 28.8kbps, and

The content format is either an MPEG flow, an H.32O flow, an H.324 flow, or an H.263 flow carried over IP or RTP.

3. Content Search and Display

Content retrieval is done by the following clients that support various formats.

MPEG client-7a;

ITU H.263 client-7b supporting RTP;

-ITU H.263 client-7c supporting IP;

ITU H.320 client-7d; And

-ITU H.324 Client-7e

Content is retrieved by various clients and displayed on the local display upon request.

The client supports VCRs such as features such as fast-forward, re-wind, and the like.

D overview

Analog video from various signal sources and H.320 video from the MCU are received as input and transcoded into the required various formats such as ITU H.324, ITU H.261, ITU H.263 or MPEG and for each format Stored on various object servers provided. The object server is in turn managed by the index server and called together in the digital library. Any request from the client for content is received by the index server, which in turn is serviced by the object server via the Proxy client.

The index server or library server responds to requests from the proxy client and the store and updates and retrieves objects such as H.261, H.263 or MPEG multimedia information on the object server. The servers then supervise the object server to pass the search information back to the surrogate client. The index server has complete index information of all the various objects stored on the object server and also has the information of the object server where the information is located. The index information available on the index server may be accessed by the surrogate client to search for multimedia content from various object servers. Security and access control are also part of the index server functionality.

The object server constitutes an essential component of the digital library, which acts as a storage device for multimedia content containing video-conference information from the conference facility and provides physical storage. The multimedia content is stored in a standard format that can be retrieved by the surrogate client upon request. Each object server is provided for a specific format of multimedia content, such as H.261, H.263, MPEG, etc. The organization and index information of the multimedia content including information about a specific object server provided for the multimedia format is managed by the index server. The object server delivers the multimedia content stored to the surrogate client at the same time as receiving the specific command from the index server.

The surrogate client is the front end of the digital library and is accessed by all clients over the Internet for custom multimedia content. The proxy client is a World Wide Web (WWW) server and delivers a page to the client when accessed. The client interacts with the surrogate client and thereby interacts with the digital library through the WWW page. The client requests multimedia content by interacting with the WWW page. The surrogate client receives a request from the client via the WWW page and processes the request. The surrogate client then communicates with the index server for an object query as requested by the client. The index server then instructs the object server to communicate with one of the object servers provided in the requested multimedia format and to deliver the requested multimedia content to the surrogate client based on index information that may be used at the index server. do. The surrogate client receives the multimedia content from the object server and forwards it to the client making the request.

The client connects to the server via either a dial-up connection on the ISDN line or an analog line at 28.8 Kbps or the Internet, depending on the video format and client capabilities requested. The H.320 client is accepted by the ISDN line and the H.324 client requests service on an analog phone at 28.8 Kbps. An MPEG client or an H.263 client using RTP or an H.263 client using IP requests services over the Internet. Potentials for querying and displaying multimedia content, such as WWW browsers, are integrated as part of the client and provide an easy-to-use interface for end users.

A request for an image from the client is received by a surrogate client that routes the request to a path index server, which in turn processes the request and communicates with a particular object server in addition to indexing the content for delivery. do. The object server delivers the requested content to the client via the Internet. In the case of a dial-up link, the content is passed back on the pre-established link.

In sum, the video accumulation and delivery structure describes a comprehensive system for video and audio or on-demand voice generation, transcoding, storage, storage management and delivery. The transmission of video and voice or voice is over the Internet or by ISDN or analog telephone dial-up lines. Content, including video and audio, or voice, is delivered at various data rates from each storage location, each serving a variety of delivery speeds.

XVI. Video operator

A. Hardware Structure

96 shows system hardware that allows a video operator to participate in a video conference or video call and provides multiple services to the video caller. Services provided include: a response to an input video call or a dial call to a customer site; Maintain video conference schedules and call Bandwidth an Demand Interoperability Group ("BONDING") or Telecommunication Union-Telecommunication Standardization Sector ("ITU-T") Standard H.320 Multi-rate Bearer Service (MRBS) Integrated Services Digital Network ("ISDN ") Access to a system for connecting a caller using the call to a video conference or video call; Monitor, view of any video conference or video call. And recording; Playback of previously recorded video conferences or video calls; And providing answers or assistance to inquiries from the video conference during the video conference or video call.

The system hardware includes video operator terminal 40001, call server 40002, multimedia hub ("MM Hub") 40003, wide area network hub ("WAN Hubs") 40004, multipoint conferencing unit ("MCU") 40005, BONDING server 40006, client It consists of a terminal 40007 and a switched network (“MCI”) 40008.

In one embodiment, the video operator terminal 40001 is a Pentium-class personal computer with a hard disk drive having a processing speed of 90 MHz or higher, 32 MB RAM and at least 1.0 GB storage space. The operating system according to the embodiment is Window 95 of Microsoft Corporation. Special features include the Incite Multimedia Communications Program ("MCP") software, an H.320 video coder / decoder ("codec") card (for example, Zydacron's Z240 codec) for audio and video compression, and isochronous Ethernet (" isoEthernet ") network interface card. Incite's MCP manages isoEthernet network cards to create 96 ISDN B-channel equivalents for isochronous channels for the transmission of video signals.

The call server 40002 in the above embodiment is a Pentium-class personal computer with a hard disk drive having a processing speed of 90 MHz or higher, 32 MB RAM and at least 1.0 GB storage space. The operating system is Microsoft's Windows NT server. Special features include an Incite Call Server service and an Ethernet network interface card.

Another embodiment of the system is suitable for any MM hub 40003 modem and any WAN hub 40004 modem. In one embodiment, the MM hub 40003 is an Incite Multimedia hub and the WAN hub is an Incite WAN hub. The MM hub 40003 is a personal computer or WAN hub 4004 or other such as video operator terminal 40001 and BONDING server 40006 through multiple ports supporting bandwidth configured as 96 full-duplex B-channels on an isoEthernet interface. Local area network ("LAN") hub that connects to the serial MM hub. The MM hub 40003 can also tolerate up to 10 Mbps of Ethernet data via an Ethernet interface, such as the Ethernet interface from the call server 40002. The WAN hub 40004 acts as an interface between dedicated or public switched networks such as MM hub 40003 and MCI 40008, allowing video conferencing to extend beyond a LAN or WAN including the MM hub 40003 and WAN hub 40004. .

Other embodiments of the system are suitable for MCU 40005 devices of various manufacturers. The MCU 400O5's function is to allow video conferencing callers to use a variety of different devices to communicate with each other in a single video conference, possibly over a different network based digital network. For example, one embodiment employs a Video Server Multimedia Conferencing Server (“MCS”), which mixes voice and allows each video conferencing caller to simultaneously differently to allow any video conferencing caller to listen to the complete video conferencing discussion. Process the video so that all callers can see it.

In one embodiment, the BONDING server 40006 is a Pentium-class personal computer with a hard disk drive having a processing speed of 90 MHz or higher, 32 MB RAM and at least 1.0 GB storage space. In the above embodiment, the operating system is Microsoft's Window 95. Unique features include Incite BONDING server software, digital signal processor ("DSP") cards (such as Texas Instruments' "TMS320C80" DSP), and isoEthernet network interface cards. Where client terminal 40007 makes a BONDING or Aggregated video call, the BONDING server 40006 converts the call into a multi-rate ISDN call used within a video operator platform.

In a preferred embodiment, the client terminal is a Pentium-class personal computer with a hard disk drive with a throughput of 90 MHz or higher, 32 MB RAM and at least 1.0 GB storage space. The operating system is Microsoft's Window 95 in the above embodiment. Client terminal 40007 is equipped with audio and video equipment that conforms to ITU-T standard H.320.

In this embodiment, the switched network is the integrated services digital internet ("ISDN") provided by the MCI 40008.

The video operator terminal 40001 is connected to the MM hub 40003 via an isoethernet interface with a bandwidth of 96 full-duplex B-channels, which allows each video operator to manage up to eight video conferencing clients. Adopt a client terminal 40007. The MM hub 40003 is connected to the WAN hub 40004 through a similar isoEthernet local area network (“LAN”) connection. One WAN hub 40004 is connected to the MCU 40005 through the MCI 40008 by a multi-rate ISDN interface. Another WAN hub 40004 is connected to MCI 40008 by multi-rate ISDN interface and MCI is connected to each client terminal 40007 by BONDING or multi-rate ISDN interface. In a three way connection, the MCU 40005, the call server 40002 and the MM hub 40003 are interconnected via an Ethernet wide area network (“WAN”) 40009. The MM hub 40003 is also connected to the BONDING server 40006 via an isoEthernet interface with a bandwidth of 248 B-channels in full " iso " mode.

B Video Operator Console

FIG. 97 shows one embodiment of a system that enables a video operator to manage video conferencing calls, which includes external systems and interfaces 40108 through video operator console systems 40101 and 40117.

The video operator console system 40101 is comprised of a graphical user interface (“GUI”) 40102, a software system 40103, and a media console system 40107. The GUI 40102 interacts with both the software system 40103 and the media control system 40107 to enable the video operator to perform all the functions of the video operator invention from the video operator terminal [40001 in FIG. 96] using the video console system 40101. Works.

The software system 40103 implements the following systems: a schedule system 40104 for managing a schedule of the video operator; Recording and reproducing system 40105 for recording audio and video input from any call and reproducing audio and video input via any call; Calling system interface 40106 that acts as an application program interface with the Incite MCP application to manage individual calls by executing exchange functions such as dial and hold.

The scheduling system 40104 is connected to the Video Operator Shared Data base 40111 via an open database connectivity ("ODBC") interface 40108, which in turn is the video conferencing scheduling system ("VRS") via the interface between VOSD and VRS 40114. 40115). The VRS 40115 submits a video conference schedule meeting rule and site rule to the video Operator Shared Database 40111 via the interface 40114 according to general principles or upon request by a database agent system in the video Operator Shared Database 40111. The video operator common database 40111 is in a preferred embodiment located on a different computer than the computer comprising the video operator console 40101, which stores all meeting and site information and is therefore required for any video conference call. You can search for conference and site organization. In alternative embodiments of the external system associated with the internal scheduling system 40104, the video operator shared database 40111 and the VRS 40115 may be integrated into a single system.

The recording and playback system 40105 is a dynamic data exchange ("DDE"), object linking and embedding ("OLE"), or dynamic link library with an image operator storage and playback system 40112 located locally at the video operator terminal (40007 in FIG. 96). ("DLL") communicates via interface 40109. The video operator and playback system consists of a unidirectional recording device 40116 compliant with ITU-T standard H.320 and a unidirectional playback device 40117 compliant with ITU-T standard H.320. The conference call is recorded by sending digitized audio and video signals from the video operator console 40101 to the H.320 recorder 40116. The conference call is reproduced by retrieving the previously recorded conference call from the disk storage device and transmitting audio and video signals from the H.320 playback device 40117 to the video operator console.

The paging system interface system 40106 communicates with the Incite MCP application 40113 via the DDE interface 40110 to manage switching functions such as dial hold.

Media control system 40107 allows the GUI 40102 to communicate directly with external components to manage GUI 40102 images of audio and video. In the embodiment shown in FIG. 401, the media control system 40107 communicates with the Incite MCP application 40113 through the DDE interface 40110. The Incite MCP application 40113 provides all the necessary call setup and multimedia features, such as video window placement and voice control, to the internal media control system 40107 and the GUI 40102 via the DDE interface 40110 via the DDE interface 40110.

FIG. 98 shows a second embodiment of a system for enabling a video operator to manage video conferencing calls, which includes an external system and interface 40203 via video operator console systems 40101 and 40117. Include. In the above embodiment, however, the software system 40103 is suitable not only for the "MCS" 40215 MCU of the video server but also for MCU applications of other manufacturers. Accordingly, FIG. 98 shows the internal software system MCU control 40201, the external software system MCU control system 40208, the MCU itself 40214 and 40215 and the interfaces 40206, 40210 and 40211 between them. In addition, since the Incite MCP 40113 application as well as the "other programs with call control interface" 40216 can provide the call setup and multimedia features required in the above embodiments, the external call control system 40209 can be used to relay DDE, OLE or DLL interface 40207, Like 40212 and 40213 are required. The embodiment also includes an image accumulation and delivery system 40204 and its DDE, OLE or DLL interface 40203. Eventually, the second embodiment adds the internal software system call monitor 40202.

As in the first embodiment, the video operator console system 40101 includes a GUI 40102 and a software system 40103. However, in addition to the scheduling system 40104, the recording and reproducing system 40105, and the calling system interface, the software of the second embodiment includes the MCU control 40201 and the call monitor 40202.

The scheduling system 40104 and associated external systems 40108, 40111, 40114 and 40115 are identical to those of the first embodiment shown in FIG. 97 and described above.

The internal MCU control 40201 communicates with an external MCU control system 40208 through a DDE, OLE or DLL interface 40206 to manage resources and features specific to various other MCU systems. The video server MCS via the MCU control system 40208 Conference Talk interface 40211. It communicates with any other MCU vendor's MCU 40214 via the 4025 or via another vendor-specific interface 40210.

The recording and reproducing system 40105 communicates with the storage and retrieval system 40205 and the image accumulation and delivery system 40204 through the DDE, OLE or DLL interfaces 40109 and 40203. The storage and retrieval system 40205 and the image accumulation and delivery system 40204 communicate with the call control system 40209 via another DDE, OLE or DLL interface 40207. The call control system 40209 communicates with a unidirectional H.320 recorder 40116 and a unidirectional H.320 playback device 40117 via another DDE, OLE or DLL interface 40212. The conference call is a video operator for digitized audio and video signals. It is recorded by sending from console 40101 to H.320 recorder 40116 via storage and retrieval system 40205 and call control system 40209. Conference calls are retrieved by retrieving previously recorded conference calls from disk storage and transmitting the audio and video signals from the H.320 playback device 40117 to the video operator console 40101 via the call control system 40209 and storage and retrieval system 40205. do. The image accumulation and delivery system 40204 communicates between the recording and reproducing system 40105 and the call control system 40209 and operates in a manner similar to the storage and retrieval system 40205.

The call monitor 40202 checks call and connection status by electrically polling the call system interface 40106 within the video operator console software system 40103. The call system interface 40106 communicates with the call control system 40209 via a DDE, OLE or DLL interface 40207 to manage call data including exchange functions such as dial, hold, and the video operator console 40101 internal data structure and the The call control system translates between 40209 data. The call control system in turn manages either the Incite MCP 40113 or another program 40216 having a call control interface.

Media control system 40107 communicates with the call control system 40209 through a DDE, OLE or DLL interface, which communicates with the Incite MCP application 40113 or another program 40216 with a call control interface via the DDE interface 40110. The Incite MCP application 40113 provides both the necessary call setup features and multimedia features, such as video window placement and voice control, directly to the internal media control system 40102 via the DDE interface 40110 or via the call control system 40209. If another program 40216 with a call control interface is used to provide call setup and multimedia features, they communicate with the media control system 40107 through the call control system 40209.

C video conference call flow

FIG. 99 shows how a video conferencing call initiated by a video operator is connected through the system shown in FIG. 96. In the first step shown in call flow path 40301, the video operator initiates a call from video operator terminal 40001 to BONDING server 40006 via MM hub 40003, where the BONDING server 40006 converts the call into a BONDING call. In the second step shown in call flow path 40302, the BONDING server 40006 sends the BONDING call once again via MM hub 40003, through WAN hub 40004, and through MCI 40008 to client terminal 40007. The above steps are repeated for each client terminal 40007 to participate in the video conference. In a third step, shown in call flow path 40303, the video operator initiates a call from video operator terminal 40001 to the MCU 40005 via the MM hub 40003, through the WAN hub 40004, and through the MCI 40008. In the fourth step, shown as call flow path 40304, the video operator uses video operator terminal 40001 to bridge the connection to client terminals 40007 and MCU 40005. Each time the video operator calls the conference call client at client terminal 40007, the ANI of the MCU for a particular conference site is handed over in the Calling Party Field to identify each client participating in the conference call with the correct conference site. When the MCU is called, the ANI of the client is passed over. The MCU can then identify the correct conference site for each call.

In an alternate embodiment, the client makes a BONDING call from client terminal 40007 through MCI 40005, through WAN hub 40004, through MM hub 40003, through BONDING server 40006, and once again through MM hub 40003 to video operator terminal 40001. To start. The video operator then places a call to the MCU as shown in call flow 40303 and finally bridges two calls as shown in call flow path 40304. To determine the correct conference site for the client-initiated call, the ANI of the initiating client is passed to the MCU when the connection is made by the video operator.

When a conference call is in progress, the video operator checks each call from the video operator terminal 40001. The video operator's functions include checking which call is still connected, reconnecting a disconnected call, adding a new client to the conference or joining the conference to inform the client about the conference status.

All calls are disconnected to end the meeting, and the video operator sharing database (40214 of FIG. 98) reflects the updated meeting schedule.

D. Video Operator Software System

1 Class Hierarchy

100 shows a class hierarchy for an image operator software system class. In one embodiment using the Visual C ⁺⁺ programming language, the Voobject 40401 class extends from the Visual C ⁺⁺ base class cobject. Voobject 40401 is a superclass of all classes of objects of the internal software system for the console system of the image operator, so all objects of the internal software system inherit attributes from Voobject 40401.

Vooperator 40402 is an assembly class associated with one VOSchedule 40403 Part-1 Class Object and one VOUserpreferences 40404 Part-2 Class object, so exactly one VOschedule 40403 object and exactly one VOUserPreference 40404 object are associated with each VOOperator 40402 object. have. VOSchedule 40403 is in turn an assembly class associated with zero or more VOSchedulable 40405 Part-1 Class objects, so any number of VOschedulable 40405 objects can be associated with each VOSchedule 40403 object.

VOSchedulable 40405 is a superclass for VOConference 40406 Subclass-1 and VOPlayback Session 40407 Subclass-2, so the VOConference 40406 object and VOPlaybackSession 40407 object inherit their attributes from the V0Schedulable 40405 object. VOConference 40406 is an assembly class associated with two or more VOConnection 40412 Part-1 Class objects and zero or one VOPlaybackCall 40415 Part-2 Class objects, so that at least two VOConnection 40412 objects and possibly one VOPlaybackCall 40415 object, each VOConference 40406 is related to the object. The VOPlaybackSession 40407 is an assembly class associated with one VOPlaybackCall 40415 Part-1 class object, so exactly one VOPlaybackCall 40415 object is associated with each VOPlaybackSession 40407 object.

VOCallObjMgr 40408 is an assembly class for zero or more VOCall 40410 part-1 class objects, so any number of VOCall 40410 objects can be associated with each VOCallObjMgr 40480 object. Similarly, VOConnObjMgr 40409 is an assembly class for zero or more VOConnection 40412 part-1 class objects, so any number of VOConnection 40412 objects can be associated with each VOConnObjMgr 40409 object. VOConnection 40412 is an assembly class for two VOCall 40410 part-1 class objects, so exactly two VOCall 40410 objects are associated with each VOConnection 40412 object. VOCall 40410 is a superclass for VOPalybackCall 40415 subclass-1 and therefore the VOPalybackCall 40415 object inherits its attributes from the VOCall 40410 object. VOCall 40410 is also an assembly class associated with two VOSite 40413 part-1 class objects, so exactly two VOSite 40413 objects are associated with each VOCall 40410 object. Finally, the VOCall 40410 class object uses the VORecorder 40411 class object.

VOSite 40413 is a superclass for VOMcuPortSite 40417 subclass-1, VOParticipantSite 40418 subclass-2, and VOOperatorSite 40419 subclass-3, so the VOMcuPortSite 40417 object, the VOParticipantSite 40481 object, and the VOOperatorSite 40419 object inherit their attributes from the VOSite object.

VOPlaybackCall 40415 is an assembly class associated with one VOMovie 40416, so exactly one VOMovie 40416 object is associated with each VOPlaybackCall 40415 object. The VOPlaybackCall 40415 class object also uses the VOPlay 40414 class object.

The VOMessage 40420 object has no relationship except to inherit the attributes of VOObject 40401, the superclass of all objects in the internal software system.

2. Class and Object Details

a) VOObject

All internal software system classes are inherited from the following base classes:

The base class extends from the visual C ++ base class CObject.

Class VOObject

Base class CObject

Integer form public

Friend Class-

(1) data type

enum senderType_e {SENDER_INTERNAL, SENDER_SCHEDUL,

SENDER_CONFERENCE, SENDER_CONNECTION, SENDER_CALL,

SENDER_TIMER};

enum messageType_e {MSG_DEBUG, MDG_ERROR, MSG_WARNING, MSG

_APPLICATION_ERROR, MSG_STATE_UPDATE};

Delivery type flag: DELIVER_MESSAGE_QUEUE, DELIVER_LOG_FILE,

DELIVER_MODAL_DIALOG, DELIVER_MODELESS_DIALOG,

DELIVER_CONSOLEOUTPUT

(2) properties

(3) method

(a) Post Message

virtual Postmessage (messageType_e type, int errCode, CString info = '' '', int

delivery = (DELIVERY_MSG_QUEUE ｜ DELIVER_LOG_FILE),

senderType_e senderType = SENDER_INTERNAL, void ^* sender = NULL);

(i) parameters

Message type as specified in the Type data type section

errCode Error or warning as specified in the application resource

Info Special textual information passed as part of the message.

Delivery Desired message delivery method. The transfer options are shown in the data type section above. The default mode of delivery is stored in the class member variable m_delivery, which must be initialized only with both DELIVER_MESSAGE_QUEUE and DELIVER_LOG_FILE.

Message sender type as specified in the senderType data type section.

Sender message, a pointer to the object sending the above.

(ii) description

Use this feature to generate error, warning, debug, log, and notification messages. It will create a VOMessage object, which will then execute the appropriate action described by the delivery flag.

(b) GetErrorString

virtual CString GetErrorString (int errorCode);

Return Value: Returns a CString with the error string corresponding to the passed error code.

errorCode parameter: the error code for which you want the error string. Error strings are stored as resources.

The above function is called to obtain a textual description corresponding to the error code.

b) Core Classes

(1) class list

site

Participant site

MCU port site

Video Operator Site

call

Play call

Movie

Calling object manager

connect

Connection object manager

message

Video operator

(2) class commentary

(a) site

This is the base class from which classes such as the participant site and the MCU port site class can be derived. Its primary purpose is to function as a data structure containing appropriate information about who or what is participating in the call.

Class VOSite

Base class VOObject

Inheritance Type publc

Friend Classes-

(i) data type

enum Bandwidth_e {MULTIRATE, BONDING, AGGREGATED, HO};

(ii) attributes

(b) Participant Site

Inherited from VOSite base class.

All customers and conference participants will have their information stored in the VO shared database.

Class VOParticipantsite

Base Class VOsite

Inheritance Type public

Friend Classes-

property

(c) mcu port site

Inherited from VOSite base class.

All meetings take place on mcu. Each participant site needs to be connected to a logical "port" on the mcu.

Class VOMCUportsite

Base class VOSite

Factorial type public

Friend Class-

property

(d) Video Operator Site

Inherited from VOSite base class.

Every call will have a video operator site as one of the sites on a point-to-point call. The structure contains the actual ani of the image operator.

Class VOoperatorsite

Base class VOSite

Succession type common use

Friend Class-

property

(e) call

The call is defined as a full duplex h.320 flow between two sites. In every call the video operator site may be one of the sites. The combined pair of calls is called a connection.

Class VOCall

Base class VOObject

Succession type common use

Friend Class-

(i) data type

enum statecall_e {ERROR, INACTIVE, INCOMING, DIALING, ACTIVE, DISCONNECTED, HELD, lastcallstates};

enum callOperation_e {ERROR, DIAL, ANSWER, HOLD, PICKUP, DISCONNECT, HANGUP, lastCallOperations}

(ii) attributes

(ii) method

Disconnection (); Indicates when the other end of the line hangs up or when the line becomes unavailable. The member variable m_expectHangup must be FALSE. Otherwise, the Call Object's Hangup () operation will be called.

Reset (); Reset the call state to inactive.

RecordingStart (); Start recording the H.320 input pipe for the call.

RecordingStop (); End recording for the call.

setState (callOperation_e operation);

Operation parameter: indicates an executed operation that will result in a state change.

Operations that affect the GCNF state should call setState after the operation executes. The function will change the calling state by referring to the current state and operation in the state-transition table. The VOMessage object will be created as a kind of status-update and the GUI and any other components that read the application queue will therefore be notified of the status update.

(f) Replay Call

Inherited from VOCall base class.

In the case of a special call, the video operator audio and video output is replaced by the h.320 flow from the playback of a movie by the video operator storage and playback external component.

Class VOplaycall

Base class VOCall

Succession type common use

Friend Class-

(i) properties

(ii) method

PlaybackStart (); Start playing

PlaybackStop (); End playback

(g) movie

The movie is a record of h.320 calls. For phase 1, the video operator storage and playback system manages files and h.320 data for recording and playback of movies as well as storage and retrieval.

Class VOMovie

Base class OObject

Succession type common use

Friend Class-

property

(h) calling object manager

By having the call object manager execute the construction and destruction of the call object, all call lists on the device of the image operator can be maintained. This includes calls that are not part of any conference or playback session, including incoming calls and general purpose dial out calls. Operations that affect the call but do not create or destroy the call can be executed by the call object itself.

Class VOCallObjManager

Base class VOObject

Factorial type public

Friend Class-

(i) properties

(ii) method

Dial ();

Dial (VOCall ^* pCalling);

pcall parameter: If not empty, the pointer will be used for the call object. The pointer is required when creating or reusing a call object that is in an inactive or disconnected state.

Dial executes dial out. The number to dial in is in the m_psitecall member structure.

Answer ();

Answer (VOCall ^* pIncoming);

pIncoming parameter: If not empty, the pointer will be used for the calling object. The pointer is required when creating or reusing a call object that is in an inactive or disconnected state.

The response responds to the incoming call.

Hangup (VOCall ^* pCall);

pCall parameter: pointer to the call

The hangup hangs up the call indicated by pcall.

Hold (VOCall ^* pCall);

pCall parameter: pointer to the call

Hold puts the indicated call on hold.

VOCall ^* CallCreate ();

VOCall ^* CallCreate creates a call object.

VOPlaybackCall ^* PlaybackCallCreate ();

VOPlaybackCall ^* PlaybackCallCreate () creates a playback call object.

VOCall ^* GetCallPtr (ID_t idCall);

idCall parameter: Call id.

VOCall ^* GetCallPtr holds a pointer to the call identified by idCall.

(i) connection

The connection is identified as a pair of call objects that maintain a combined state, and each call has a video operator site as a common point for the binding to be performed.

Class VOConnection

Base Class VOObject

Inheritance Type public

Friend-

(i) data type

enum StateConnection_e {ERROR, UNJOINED, JOINED, BROKEN, lastConnectionStates};

enum ConnectionOperation_e {ERROR, JOIN, UNJOIN, BREAK, RESET, lastConnectionOperation};

(ii) attributes

(iii) method

Join (); Combine participant and mcu port calls.

Unjoin (); Unjoin participants and mcu port sites.

SetParticipant Call (VOCall ^* participant Call);

participantCall parameter: pointer to the calling object

setparticipantcall sets the call to be a participant call. This is useful for managing unknown incoming calls or for replacing last minute call sites.

SetMCUPortCall (VOCall ^* mcuPortCall);

mcuPortCall parameter: pointer to the call

setmcuportcall sets the call to be an mcu port call. This is useful for managing unknown incoming calls or for last minute call site substitution.

DoparticipantCall (); Call the participant site and set this to Participant Call.

DoMCUPortCall (); Invoke the mcu port site and set this to the mcu port call.

setState (ConnectionOperation_e operation);

Operation parameter: the executed operation that will result in a change of state.

Operations that affect the connection state must call the setstate function after the operation is executed. The function must change the state of the connection with reference to the operation of the current state and state-transition table. The vom object will be created of type STATUS_UPDATE and sent to the application queue. GUIs and other components that read application queues will therefore be notified of status updates.

Protected Break (); Called when the join connection is unjoined. If the member variable m_expectbreak is false, then one of the calls must abruptly disconnect. Otherwise, the connection'unjoin () operation will be called.

protected Reset (); Set the connection status to UNJOINED.

(j) connection object manager

Similar to the calling object manager, a list of all connections of operations on the device of the video operator should be maintained. All operations that result in the creation and deletion of a connection must use the connection object manager.

Class VOConnectionObjMgr

Base Class VOObject

Inheritance Type public

Friend Classes-

(i) properties

(ii) method

VOConnection ^* Create ();

Return value: pointer to the connection object.

VOConnection ^* Create creates a new connection and adds it to the list.

Remove (VOConnection ^* oldConnection);

Old Connection Parameters: Connection Objects to be Removed

Return value: Returns true if the operation is successful.

Remove deletes the connection object and removes it from the list.

VOConnection ^* GetConnectionPtr (ID_t idConnection);

Return value: pointer to the connection object.

idconnection parameter: the parameter of the connection

VOconnection ^* getconnectionptr returns a pointer to the connection object identified by id.

(k) messages

All one-way communication from the Internet system to the image operator application, i. E. The rest of the image user interface, is transmitted as a message placed in the application queue. The ability to create and notify a message resides in the base class VOObject, from which all Internet system software is inherited. All runtime error and debug information is placed in the message object and notified to the application queue so that the appropriate object processes the information according to the type and severity of the information. Therefore, all class functions that do not return a particular type will notify you if something goes wrong (memory failure) and debug information displayed by the GUI or logged to a file.

Class VOMessage

Base Class VOObject

Inheritance Type Public

Friend Classes-

(i) data type

enum senderType_e {INTERNAL, SCHEDULE, CONFERENCE, CONNECTION, CALL, TIMER};

enum messageType_e {DEBUG, ERROR, WARNING, APPLICATION_ERROR, STATE_UPDATE};

Delivery type flags: DELIVER_MESSAGE_QUEUE, DELIVER_LOG_FILE, DELIVER_MODAL_DIALOG, DELIVER_MODELESS_DIALOG, DELIVER_CONSOLEOUTPUT

(ii) attributes

(iii) method

Post (); Notify the message to the application message queue.

Private static appendLog ();

Return value: trueffm returns if the operation is successful.

This method is called when the flag for DELIVER_LOG_FILE is set by VOObject :: postmessage ().

(l) Video Operator

Generally there will only be one video operator per device. Each video operator has a list of customer participant sites that are scheduled and managed. The calling object manager and the connection object manager are also part of the video operator.

Class VOOperator

Base Class VOObject

Inheritance Type public

Friend-

(i) properties

(ii) method

protected ScheduleStart (); Initiate a schedule for the video schedule.

protected CallObjMgrStart (); Start the calling object manager.

protected ConnectionObjMgrStart (); Start the connection object manager.

protected CallSystemInterfaceStart (); Start the calling system manager.

(m) user first

The video operator console application has a set of default application preferences that can be modified and stored. The values of these variables are obtained from the following signal sources in increasing preference order: hard-coded default values, stored vo.ini files, command-line invoke arguments, gui entries, and stored actions as vo.ini files. Correct time.

Class VOUserPreferences

Base Class VOObject

Inheritance Type public

Friend-

(i) properties

(ii) method

SavePrefs (); All values are stored as vo.ini.

LoadPrefs (); Load all values into vo.ini.

(n) mcu

Every mcu port site corresponds to a specific mcu. This class is used only for mcu port site storage. For phase 2 mcu specific operations and interfaces can be performed here.

Class VOMCU

Base Class VOObject

Inheritance Type public

Friend classes-

(i) properties

(ii) method

VOMCUPortSite ^* GetPortPtr (ID_t idPort)

Return value: pointer to the mcu port site object.

idport parameter: id of the mcu port site

VOMCUPortSite ^* GetPortPtr returns a pointer to the mcu port site object identified by id.

VOMCUPortSite ^* CreatePort ();

Return value: pointer to the new mcu port site object.

VOMCUPortSite ^* CreatePort () returns a pointer to the newly created mcu port site identified by id.

(3) State variable transition diagram for core class

FIG. 101 is a state transition diagram illustrating a state change that may occur in an m_state variable (“state variable”) of a VOCall object. The state variable starts 40501 in an inactive 40502 state.

When the VOCall object receives a dial 40503 input when the VOCall object is in an inactive 40502 state, the state variable changes to the dialing 40504 state. In the dialing 40504 state, the state variable changes to an inactive 40502 state upon receiving a 40505 input during a call or to an active 40507 state upon receiving a response 40506 input. In the active 40507 state, the state variable changes to the held 40510 state upon receipt of the pending 40509 input, or changes to the disconnected 40515 state upon receipt of the disconnected 40514 input, or to the inactive 40502 state upon receipt of the hang-up 40508 input. In the held 40510 state, the state variable changes to the active 40507 state upon receipt of the pickup 40511 input, or changes to the disconnected 40515 state upon receipt of the disconnected 40513 input, or to the inactive 40502 state upon receipt of the hangup 40512 input. In disconnected 40515 state, the state variable changes to inactive 40502 state upon receipt of reset 40516 input.

When the incoming call 40517 is received while the VOCall object is in the inactive 40502 state, the state variable is changed to the incoming 40518 state. In incoming 40518 state, the state variable is changed to inactive 40502 upon receipt of reject 40520 or to active 40507 state upon receipt of response 40519 input.

FIG. 102 is a state transition diagram illustrating a state change that may occur in an m_state variable (“state variable”) of the VOconnection object. The state variable starts 40601 in a separated 40602 state. In a split 40602 state, the state variable is changed to combine 40604 upon receipt of a combined 40603 input. In the combined 40604 state, the state variable is changed to split 40602 upon receipt of a split 40605 input or changed to broken 40607 upon receipt of a break 40606 input. In the broken 40607 state, the state variable changes to the combined 40604 state upon receipt of the combined 40608 input.

(c) Scheduling System Class

(1) class list

Replay session

conference

schedule

Scheduleable

(2) class description

(a) Replay Session

Like a meeting, a replay session needs to be planned. Calls are made using the participant site and the video operator site. The video storage and playback external components will play the planned and preselected movie that replaces the av output with the participant site. No mcu is used in the playback session and only one participant site is included in one embodiment.

Class VOPlaybackSession

Base Class VOSchedulable

Inheritance public

Type

Friend Classes-

(i) data type

enum StatePlaybackSession_e {ERROR, INACTIVE, SETUP, ACTIVE, ENDING, FINISHED, lastPBSessionStates};

enum playbackSessionOperation_e {ERROR, PREPARE, START, CLOSE, FINISH, lastPBSessionOperations};

(ii) attributes

(iii) method

public boolean Setup ();

Return value: Returns true if the operation is successful.

The public bull setup () sets up the playback call by calling the participant and initializes the VOplayer object. The function can be called by the scheduler.

Public boolean Start ();

Return value: Returns true if the operation is successful.

Public dismissal initiates the player to activate the play call. The function can be called by the scheduler.

Public boolean Close ();

Return value: Returns true if the operation is successful.

The public stop will send a message to the video operator and possibly to a participant who is a playback session that will end soon.

Public boolean Finish ();

Return value: Returns true if the operation is successful.

Common fire termination terminates the player and hangup the playback call. The function can be called by the scheduler.

public StatePlaybackSession_e StateGet ();

Return value: Returns the state of the playback session.

use the public stateplaybacksession_e stateget; Find out the status of the playback session.

protected boolean StateSet (playbackSessionOperation_e operation);

Return value: Returns true if the operation is successful.

Operation parameter: the executed operation that will result in a change of state.

An operation affecting the state of the playback session invokes the main protected boolean stateset function in which the operation will be executed. The function will change the state of the playback session by referring to the current state and operation of the state-transition table. The VOmessage object will be created with a status-update type and sent to the application queue. Therefore, gui and any component that reads the application queue will be notified of status updates.

(b) meeting

The main function of the video operator is to manage the conference. The schedule system creates a conference object, which in turn generates a list of connections (or participant-mcu portsite call pairs). In the special case of a movie being played back to a conference, a special call is made to the mcu port and the movie is played to mcu in a similar manner to the playback session. The progress requires a special mcu port site that can be used and should be planned before the start of the meeting.

Class VOConference

Base Class VOSchedulable

Inheritance Type public

Friend classes

(i) data type

enum conferenceMode_e {CONTINUOUS_PRESENCE, VOICE_ACTIVATED, LECTURE, DIRECTOR_CONTROL};

enum StateConference_e {ERROR, INACTIVE, SETUP, ACTIVE, ENDING, FINISHED, lastConferencesStates};

enum conferenceOperation_e {ERROR, PREPARE, START, CLOSE, FINISH, lastConferenceOperations};

(ii) attributes

(iii) method

public boolean Setup ();

Return value: Returns true if the operation is successful.

The employment bull setup sets up each connection (and replay call if necessary) of the contact list by calling each appropriate participant site and mcu port site and executes the join operation to create the connection. The function can be called by the scheduler.

Public boolean Start ();

Return value: Returns true if the operation is successful.

The public launch initiates the meeting. The function can be called by the scheduler.

Public boolean End ();

Return value: Returns true if the operation is successful.

The public boolean End initiates tearing down the connection at the meeting or issues a warning indicating that the meeting will end soon. The function can be called by the scheduler.

Public boolean Finish ();

Return value: Returns true if the operation is successful.

The public fire end terminates the meeting and hangs up all calls in the meeting. The function can be called by the scheduler.

public StateConnference_e StateGet ();

Return value: Returns the conference status.

use the public stateconferance_e stateget functions to find the state of a meeting

protected boolean StateSet (conferenceOperation_e operation);

Return value: Returns true if the operation is successful.

Operation parameter: the executed operation that will result in a change of state.

Operations that affect the conference state should invoke the non-protected stateset function after the operation is executed. The function will change the state of the conference by referring to the current state and operation of the state-transition table. The VOmessage object will be created with a state-update type and sent to the application queue. Gui and any other component that reads the application queue will therefore be informed of status updates.

(c) schedule

The scheduling system maintains a list of conference and playback sessions. Each meeting and playback session is created at a specific time interval before its start time. The schedule in memory and the schedule stored in the video operator shared database for the current video operator must always occur in synchronization.

Class VOConference

Base Class VOSchedulable

Inheritance Type public

Friend classes

(i) attributes

(ii) method

SynchWithDb (); It is synchronized with the VO shared database for scheduling.

AddSchedulable (VOSchedulable ^* pSchedulable);

pschedulable parameter: A pointer to the schedule object to add to the list.

addschedule adds a schedule object to the list.

DeleteSchedulable (ID_taSchedulable);

aschedulable parameter: a planable object to be removed from the list

deleteschedulable deletes a schedulable object and removes it from the list.

(d) schedulable

Items and objects planned in phase 1 are conference and playback sessions. This class allows us to create a schedule for any type of event.

Class VOSchedulable

Base class VOObject

Factorial type public

Friend Class-

(i) properties

(ii) method

public SetAlarm (Ctime time, LPTIMECALLBACK fune);

time parameter: the time for the triggered alarm

func parameter: a pointer to the callback function when the alarm is triggered

Return value: Returns true if the operation is successful.

The public setalarm causes the alarm to be triggered at a specific time. When the alert is triggered, the callback will be called. This is useful for time-dependent events such as 15 minutes before the start of the meeting, 5 minutes before the end of the meeting, and 30 minutes after the meeting ends.

public KillAlarm ();

Return value: Returns true if the operation is successful.

The public killalarm kills the last alarm set by setalarm (). This may be used in case of stopping a meeting or the like.

(3) State variable table diagram for the schedule system class

103 shows a state transition diagram illustrating state changes that may occur in the m_state variable (“state variable”) of the VOconference object. The state variable is initiated in an inactive 40702 state. In the non-active 40702 state, the state variable changes to the connection setup 40704 state upon receipt of the "703 minutes before the scheduled time" 40703 input. In the connectionsetup 40704 state, the state variable changes to an active 40706 state upon receipt of a startconference 40705 input. In the active 40706 state, upon receiving the extendconference 40707 input, the active 40706 state remains active or the closeconference (propertermination) 40708 input changes to the ending 40707 state upon receipt. In the ending 40707 state, upon receiving the finish 40710 input, the state changes to the finished 40711 state.

d) recording and playback classes

(1) class list

Recorder

player

(2) class details

(a) recorder

The recorder communicates with any external component that performs the actual movie creation and recording of the call's input pipe. The external component is known as a video operator storage and playback system.

Class VORecorder

Base class VOObject

Factorial type public

Friend Class-

(i) data type

enum StateRecorder_e {ERROR, IDLE, RECORDING, PAUSED, FINISHED, lastRecorderStates};

enum recorderOperation_e {ERROR, BEGIN, PAUSE, RESUME, STOP, lastRecorderOpsP}

(ii) attributes

(iii) method

InitMovie (); Initialize the VOspsms record. This instructs the vsop to prepare the record.

start (); vsop starts recording.

stop (); vsop ends recording.

setState (recorder-Operation_e operation);

Operation parameter: the executed operation that will result in a change of state.

Operations that affect the state of the recorder should call the setstate function after the operation is executed. The function will change the state of the recorder by referring to the current state and operation in the state-transition table. The VOmessage object will be created with a status_update type and sent to the application queue. Gui and any other component that reads the application queue will therefore be informed of status updates.

(b) players

The player communicates with any external component that performs the actual playback of the movie as the output pipe of the call. For phase 1, the external components are known as image operator storage and playback systems.

Class VOPlayer

Base class VOObject

Factorial type public

Friend Class-

(i) data type

enum StatePlayrer_e {ERROR, IDLE, PLAYING, PAUSED, FINISHED, nPlayerStates};

enum playerOperation_e {ERROR, BEGIN, PAUSE, RESUME, STOP, RESET, nplayerOps}

(ii) attributes

(iii) movie

public InitMovie ();

Return value: Returns true if the operation is successful.

The public initmovie VOsp initiates playback. This instructs the VOsp to prepare for playback.

public Start ();

Return value: Returns true if the operation is successful.

The shared start VOsp starts playback.

public Stop ();

Return value: Returns true if the operation is successful.

Public end VOsp terminates playback.

setstate (playerOperation_e operation);

Return value: Returns true if the operation is successful.

Operation Parameters: The executed operation that will result in a state change.

Operations that affect the player's state should call the setstate function after the operation is executed. The function changes the player's state by referring to the current state and operation in the state transition table. The VOmessage object will be created of type stasus_update and sent to the application queue. Gui and any other component that reads the application queue will therefore be informed of status updates.

(3) State transition diagrams for recording and playback classes

104 shows a state transition diagram illustrating state changes that may occur in the m_state variable of the VOrecorder object. At idle 40802, the state variable changes to the recording 40804 state upon receipt of the begin recording 40803 input. In the write 40804 state, the state variable changes to the paused 40806 state upon receipt of pause 40805 or to the finished 40801 state upon receipt of the stop 40808 input. In the paused 40806 state, the state variable changes to the recording 40804 state upon receipt of a resume 40804 input or to finished 40810 upon receipt of a stop input.

105 shows a state transition diagram showing state changes that may occur in the m_state variable of the VOplayer object. The state variable initiates 40910 in an idle 40920 state. In the idle 40902 state, the state variable changes to the playing 40904 state upon receiving the begin playing 40903 input. In the playing 40904 state, the state variable changes to a paused 40906 state upon receiving a pause 40905 input or to a finished 40901 state upon receiving a stop 40908 input. In the state paused 40906, the state variable changes to the playing 40904 state upon receipt of the resume 40907 input or to the finished 40910 state upon receipt of the stop 40909 input. In the finished 40910 state, the state variable changes to the playing 40904 state upon receipt of the replay 40911 input.

(e) Calling system interface class description

The call control system will manage all calls that the video operator can manage. The call includes incoming and outgoing h.320 call management and low level operations on the call, such as recording and playback. The video operator application uses a call system interface to communicate with a call control system external component that manages all calls in a uniform manner. This allows the video operator to manage calls that require other external programs, addition of special codecs to the device, or even call management on remote devices.

Class VOCallSys

Base class VOObject

Factorial type public

Friend Class-

(1) data type

enum Bandwidth_e {MULTIRATE, BONDING, AGGREGATED, HO}

Q.931 UserInfo for a call using BONDING:

0x00 0x01 0x07 0x44 0x79 0x00 0x00

0 1 7 447-9000

Bonded, 1 unmber, 7 digits long, 447-9000

Q.931 UserInfo for Aggregation:

0x01 0x02 0x07 0x44 0x79 0x00 0x00 0xFF 0x01

1 2 7 447-9000

Aggregated, 2 numbers. 7 digits long, 447-9000, 447-9001

(2) properties

(3) method

public Dial (Bandwidth_e calltype, CString destination);

public Dial (Bandwidth_e calltype, CString destination, CString origination);

Return value: Returns true if the operation is successful.

Call type parameter: specifies the type of call to be made.

Destination parameters: Details the destination number to be dialed.

Source parameter: Details the source number used instead of the actual number of the operator's console.

Public dialing dials out.

public Answer (ID_t call);

Invocation parameters: the invocation id of the invocation waiting to be answered

The public response responds to the incoming call.

public Hangup (ID_t call);

Return value: Returns true if the operation is successful.

Call parameters: the call id of the call to hang up

The public hangup hangs up the call.

public Hold (ID_t call);

Return value: Returns true if the operation is successful.

Invocation parameters: invocation id of the held invocation

Public hold puts the call on hold.

public Join (ID_t call1, ID_call2);

Return value: Returns true if the operation is successful.

Call1 parameter: Call id of the call.

Call2 parameter: the call id of the call.

Public join joins two calls.

(ID_t connection);

Return value: Returns true if the operation is successful.

Connection parameters: id of the connection to detach.

Public separation isolates a particular connection.

public StateCall_e CallStatus (ID_t call);

Return value: Returns the call state.

Connection parameters: id of the connection to be detached

The public statecall_ecallstatus reports the status of a particular call.

publicStateConnection_eJoinStatus (ID_tconnection);

Return value: Returns the connection status.

Connection parameters: ID of the connection to be separated

Public stateconnection_ejoinstatus reports the state of a particular association.

protected LaunchMCP ();

Return value: Returns true if the operation is successful.

Protected launchmcp launches incite's mcp application.

E. Video User Interface Classes

1. Class Hierarchy

106 shows a class hierarchy for a Video Operator Picture User Interface ("GUI") class. In general, the video conferencing operator will implement all the features of the video conferencing operator system described herein by interacting with the video operator console gui ("console gui"). The main components of the console gui are menu items for the main console window, the schedule and connection list window, the conference and connection window, the message area, voice and video control, timely informational dialogs and rarely executed actions. The mcu operations and features cannot be executed in the video operator console gui, thus allowing another embodiment of the video operator system to employ different mcu model borrowing. The vendor-specific mcu operation will be executed by the vendor's software that accompanies the mcu operation. In one embodiment employing the mcs of the video server, the mcs workstation software can be used to implement features such as conference end time extension, voice and video blocking, conference director control, and the like. The software may be executed in parallel with the image operator gui.

The gui described in object-oriented programming terms has a main application object that creates and maintains all windows therein. The main window is VOmainframe 41109 generated by VOconsoleapp 41008. The main frame window generates VOschedulewnd 41016, VOalertwnd 41015, VOconferencevw 41014, and VOvideowatch 41013. The VOschedulewnd and VOalertwnd are dockable windows, meaning they are attached to one side of their parent window. In this case, the tdrl parent window is the VOmainframe 41109 window. The dockable window can also be separated from the boundary by dragging the window away. In such a situation, the window will run like a regular tool window.

The function of each class of object is summarized as follows. VOconsoleapp 41008 is the main application class and VOmainframe 41009 is the main window that contains all the other windows. VOschedulewnd 41016 is a window in which error messages and alarms are displayed. VOchildframe 41010 is a frame window for multiple document interface ("mdi") windows. VOchildframe 41010 will run as the mainframe window for each view, VOconference 41018 derived from VOchildframe 41010 is the frame window for the conference view, and VOconferencevw 41014 is the window for displaying conference information. VOconferencedoc 41012 is a document class that corresponds to VOconferencevw 41014. Derived from VOchildframe 41010, VOvideowatchframe 41017 is the frame window for video visual views, and VOvideowatchvw 41013 is the window displaying video flow and control to make calls. VOvideowatchdoc 41011 is a document class that corresponds to videowatchview.

In one embodiment using visual c ++ as a programming language, cwind 41001 is a superclass of cmdiframewnd 41005 subclass-1, cmdichildwnd 41006 subclass-2, cfromview 41007 subclass-3, and cdialogbar 41002 subclass-4, Thus, the cmdiframewnd 41005 class object, the cmdichildwnd 41006 class object, the cfromview 41007 class object, and the cdialogbar 41002 class object inherit attributes from the cwnd 41001 class. cmdiframewnd 41005 is the superclass for VOMainframe 41009 subclass-1; CMDIChildWND 41006 is a superclass for VOCHILDFrme 41010 subclass-1; CFromView 41007 is a superclass for both VOVideowatchVw 41013 subclass-1 and VOConferenceVw 41014 subclass-2; CDialogBar 410O2 is a superclass for both VOALERTWnd 41O15 subclass-1 and VOScheduleWnd 41016 subclass-2. VOCHILDFrme 4101O is a superclass for both VOVideoWatchFrame 41017 subclass-1 and VOConferenceFrame 41018 subclass-2. CWinApp 41003 is a superclass for VOConsoleApp 41008 subclass-1 and CDocument 41004 is a superclass for both VOVideoWatchDoc 41011 subclass-1 and VOConferenceDoc 41012 subclass-2.

VOConsoleApp 41008 is an assembly class associated with one VOMainframe 41009 part-1 class object, so exactly one VOMainframe 41009 object is associated with each VOConsoleApp 41008 object. VOMainframe 41009 is an assembly class associated with one VOVideoWatchFrame 41017 part-1 class object, one VOConferenceFrame 41018 part-2 class object, one VOALERTWnd 41015 part-3 class object, and one VOScheduleWnd 41016 part-4 class object, Therefore, exactly one VOVideoWatchFrame 41017 object, exactly one VOConferenceFrame 41018 object, exactly one VOALERTWnd 41015 object, and exactly one VOScheduleWnd 41016 object are related to each VOMainframe 41009 object.

VOVideoWatchFrame 41017 is an assembly class associated with one VOVideoWatchDoc 41011 Part-1 class object and a VOVideowatchVw 41013 Part-2 class object, so exactly one VOVideoWatchDoc 41011 object and exactly one VOVideowatchVw 41013 object are associated with each VOVideoWatchFrame 41017 object. As described above, each VOVideoWatchDoc 41011 object extended from CDocument 41004 uses a VOVideowatchVw 41013 object extended from CFromView 41007 class object.

Similarly, VOConferenceFrame 41018 is an assembly class associated with one VOConferenceDoc 41012 Part-1 class object and one VOConferenceVw 41014 Part-2 class object, so that exactly one VOConferenceDoc 41012 object and exactly one VOConferenceVw 41014 object are associated with each VOConferenceFrame 41018 Is associated with the object. VOConferenceDoc 41012 uses VOConferenceVw 41014.

2. Class and Object Details

a) user interface classes

(1) class list

VOConsoleApp main application class

VOMainFrame Main window with all other windows

VOScheduleWnd A window displaying the operator's schedule

VOOutputWnd Window displaying error messages and alarms

VOChildFrame Frame window for mdi windows. This works like the main frame for each view.

VOConferenceFrame The main window for a conference view. This is derived from the VOchildframe.

VOConferenceVw Window to Display Conference Information

VOConferenceDoc The document class corresponding to VOconferencevw.

VOVideoWatchFrame Frame window for video visual view. This is derived from the VOchildframe.

VOVideoWatchVw A window that displays video flow and controls for making calls.

VOVideoWatchDoc Document class corresponding to video visual view.

(2) class details

(a) VOConsoleApp

Class VOConsoleapp

Base class CWinApp

Factorial type public

Friend Class-

(i) properties

(ii) method

Retcode CreateVideoOperator (CString login, CString password);

Return value: If successful, returns a nonzero number, otherwise returns zero.

Login parameter: Login id for the operator

Password parameter: the operator's password.

The retcode creativevideooperator function is called for the first time during application startup.

Retcode InitializeCallSystemComponents ();

Return value: if successful, returns a non-zero number; otherwise, returns zero.

The retcode initializecallsystemcomponents function is called for the first time during application launch after the image operator is created, which makes a local copy of the pointers to the VOCallsysteminterface, VOCallogjmgr and VOconnectionobjmgr objects initiated by the internal software system.

void OnGetVOMessage (VOMsg VOMsg);

VOmsg parameter: message object passed by internal software system

The void OnGetVOMessage function is called when an application receives a message from an internal software system to redirect the message to the appropriate window. In the first run, the message will be delivered to a VOmainframe, which translates the message. Depending on the type of message, the message may be displayed in VOoutputwnd, displayed in a message box, or passed to the VOconferencevw and VOvideowatch windows.

(b) VOMainFrame

Class VOMainFrame

Base class CFrameWnd

Factorial public

Friend Class-

(i) properties

(ii) method

Retcode synchWithDb ();

Return value: if successful, returns a non-zero number; otherwise, returns zero.

Login parameter: Login id for the operator

Password parameter: the operator's password

If the schedule has changed and needs to happen in sync with the database, the retcode synchwithdb function is called.

Retcode DisplayMessage (VOMsg VOMsg);

Return value: if successful, returns a non-zero number; otherwise, returns zero.

vomsg parameter: a vomsg object received from an internal software system

The retcode displaymessage function displays the contents of the vomsg object in the output window. Based on the severity, an alarm box is also displayed.

void OnConferenceStatusChanged (VOConference ^* pConference);

pconference parameter: a pointer to the conference object whose state has changed

void OnConferenceStatusChanged function is called when a specific conference changes.

(c) VOschedulewnd

Class VOScheduleWnd

Base class CDialogBar

Factorial type public

Friend Class-

(i) properties

(ii) method

Retcode Display Scheme (BOOL filter = 0);

Return value: if successful, returns a non-zero number; otherwise, returns zero.

Filter Parameter: The filter applied to the display of the schedule. Filter + 0 displays the entire schedule. Filter = 1 only displays active conference and replay calls.

The retcode displayschedule function is called to display a list of conference and playback calls in the schedule window.

Retcode DisplayConfSites (VOConference ^* pConference);

Return value: if successful, returns a non-zero number; otherwise, returns zero.

pconference parameter: The site should be displayed in the site list box of the schedule window for the conference object, a pointer to the conference object.

The retcode displayconfsites function is called to display a list of sites in the Site List box of the Schedule window.

Retcode OnClickScheduledItem ();

Return value: Returns a nonzero number if the selection is different from the previous selection. Otherwise, it returns 0.

The retcode onclickscheduleditem function is called when the user clicks on an item in the schedule list box. The launch run displays the corresponding site at the conference or site and the movie details in the playback call.

Retcode OnDblClickScheduledItem ();

Return value: Returns a nonzero number if the conference window is opened. Otherwise, it returns 0.

The retcode ondblclickscheleduditem function is called when the user double-clicks an item in the schedule list box. The first run creates a new VOconference vw for the planned item.

Retcode OnClickSite ();

Return value: Returns a nonzero number if the selection is different from the previous selection. Otherwise, it returns 0.

(d) VOoutputwnd

Class VOOutputWnd

Base class CDialogBar

Factorial type public

Friend Class-

(i) properties

(ii) method

Retcode DisplayMessage (CString info, VOMsg ^* pVoMsg = NULL);

Return Values: Returns a nonzero number if successful. Otherwise, it returns 0.

info parameter: additional information to be displayed

pVOmsg parameter: a pointer to the VOmsg object

retcode displaymessage displays the message text in the output window.

If pvomsg = null, only the above information is displayed.

(e) VOconference vw

Class VOConferenceVw

Base class CFormView

Factorial type public

Friend Class-

(i) properties

(ii) constructor (s)

protected VOConferneceVw ();

VOConference Vw (VOConference ^* pConference);

VOConferenceVw (VOPlaybackSession ^* pPbSession);

pconference parameter: The view is to be created for a conference object, a pointer to the conference object.

pPbsession parameter: The view is to be created for a playback session object, the pointer to the playback session object.

The conference view is used to display information about any conference or planned playback session. The view is created only by the main frame when the user double-clicks a conference / playback session in the schedule window.

(iii) method

(VOConference ^* pConference);

pconference parameter: a pointer to the conference object whose state is to be changed.

void onconferencestatuschanged is called when the conference status changes to allow the ui to update properly.

void OnPbSessionStatuschanged (VOPlaybackSession ^* pPbSession);

ppbsession parameter: A pointer to the playback session object whose state is to be changed.

void onpbsessionstatuschanged is called when the state of the playback session changes to allow the ui to update properly.

void OnConnStatusChanged (VOConnection ^* pConnection)

pConnection parameter: A pointer to the connection object whose state changes.

void onconnectionstatuschanged is called when the state of the connection changes to allow the ui to update properly.

void OnCallStatusChanged (VOCall ^* pCall);

pCall parameter: A pointer to the playback session object whose state is to be changed.

void oncallstatuschanged is called when the state of the current conference / playback session changes to allow the ui to update properly.

void OnPbCallStatusChagned (VOPbCall ^* pPbCall);

ppbcall Parameters: A pointer to the playback session object whose state is to be changed.

void onpbcallstatuschanged is called when the state of the playback session changes to allow the ui to update properly.

(VOConnection ^* pConnection);

pConnection parameter: A pointer to the connection object whose state changes.

void displayconnectionstatus is called to display the status of the connection.

void displayCallStatus (VOCall ^* pCall);

pcall parameter: a pointer to the call object whose state is to be changed.

void displaycallstaus is called to display the status of the call (participant or mcu).

void DisplayRecordingStatus (); If any call of the conference is being recorded, it is called to display the recording status.

void displayWatchStatus (); called to display an indication of which call is being checked in the current conference or playback session.

void displayPlaybackstatus (); called to display the playback session.

Retcode OnDialSite ();

Return value: A nonzero number is returned if the operation was initiated successfully, otherwise a zero is returned.

retcode ondialsite is called when the participant's dial button is clicked. This will dial-in the participant of the selected connection.

Retcode OnDiaIMC ();

Return value: A nonzero number is returned if the operation was initiated successfully, otherwise a zero is returned.

retcode ondialmcu is called when the dial button on the mcu side is clicked. This will dial call the mcu port assigned to the selected participant.

Retcode OnHangupSite ();

Return value: A nonzero number is returned if the operation was initiated successfully, otherwise a zero is returned.

retcode onhangupsite hangs the call to the participant.

Retcode OnHangupMCU ();

Return value: A nonzero number is returned if the operation was initiated successfully, otherwise a zero is returned.

retcode onhangupmcu hangs the call to mcu.

Retcode OnHoldSite ();

Return value: A nonzero number is returned if the operation was initiated successfully, otherwise a zero is returned.

The retcode Onholdsite feature places the participant on hold (if the call is active).

Retcode OnHoldMCU ();

Return value: A nonzero number is returned if the operation was initiated successfully, otherwise a zero is returned.

The retcode Onholdmcu function puts the mcu on hold (if the call is active).

Retcode OnWatchSite ();

Return value: If successful, returns a nonzero number, otherwise returns zero.

The retcode Onwatchsite function will check the current participant. The video flow corresponding to the participant will be displayed in the video visual window.

Retcode OnWatchMCU ();

Return value: If successful, returns a nonzero number, otherwise returns zero.

retcode Onwatchmcu initiates checking the mcu leg corresponding to the participant at the meeting. The video flow is displayed in the video visual window.

Retcode OnRecordMCU ();

Return value: A nonzero number is returned if the operation was initiated successfully, otherwise a zero is returned.

retcode Onrecordmcu starts recording the mcu flow. If recording is already in progress the function will stop / end recording.

Retcode OnRecordSite ();

Return value: A nonzero number is returned if the operation was initiated successfully, otherwise a zero is returned.

retcode Onrecordsite initiates recording of the flow corresponding to the selected participant. If recording is already in progress, the recording will be stopped / ended.

Retcode MakeAutoConnection ();

Return value: A nonzero number is returned if the operation was initiated successfully, otherwise a zero is returned.

retcode makeautoconnection is called to automatically connect participants and mcu and joins them on success.

Retcode MakeAutoDisconnection ();

Return value: A nonzero number is returned if the operation was initiated successfully, otherwise a zero is returned.

retcode makeautodisconnection is called to automatically disconnect and disconnect calls to participants and mcu.

Rctcode ConnectAll ();

Return value: A nonzero number is returned if the operation was initiated successfully, otherwise a zero is returned.

retcode connectall is called to make all connections automatically one by one.

Retcode DisconnectAll ();

Return value: A nonzero number is returned if the operation was initiated successfully, otherwise a zero is returned.

retcode disconnectall is called to automatically disconnect all conference connections.

(f) VOVideoWatchVw

Class VOMainFrame

Base class CFrameWnd

Factorial type public

Friend Class-

(i) properties

(ii) construction (s)

VOVideoWatchVw ();

(iii) method

void OnDial (); Dial the number in the destination edit box.

void OnTransfer (); Send the current call to a number. This initially displays a dialog where the user enters the number top where the call is sent.

void 0nAnswer (); Called when the response button is clicked.

void OnForward (); Called when the forward button is clicked. All calls will be forwarded with the provided forwarding signal.

void OnMute (); Called when a silent button is clicked. Turn on or off silent.

void OnHngup (); Called when the action button is clicked. Hang up the current call.

void OnHold (); Called when the hold button is clicked. Put the current call on hold.

void OnPrickup (); Called when the capture button is clicked. Catch pending calls.

void OnPrivacy (); Called when the privacy button is clicked. Turn privacy on or off.

void OnPlayMovie (); Called when the action button is clicked. This will display a dialog with a list of selected movies. Once the movie is selected the movie will be activated.

void OnRecordCall (); Called when the record button is clicked.

void OnJoinToConference (); called when the join confbutton is clicked. This will display an active conference and site list or playback session. The operator will select the site corresponding to the current call and the call will be joined to the conference.

void WatchVideo (BOOL selection);

Return value: if successful, returns a non-zero number; otherwise, returns zero.

Optional Parameters: Details what to see.

Optional: VDOWATCH_CONFERENCE displays images from the site / mcu selected for viewing.

Optional: VDOWATCH_SELF displays the output of the video operator's camera.

Optional: VDOWATCH_CALL displays the video from the call selected from the list box provided in the video time window or, if possible, the video from the incoming call.

Call the void watchvideo function to select the video flow to watch.

void OnDisplay Callswindow (); Called when the 'call' button is clicked.

void OnSelfView (); Called when the 'selfview' check box is checked or unchecked. When selfview is checked, the camera operator's camera output is displayed in a separate small window.

void OnLocalVolume (); Called when the local volume slide bar position changes. This will adjust the local volume.

void OnRemoteVolume (); Called when the remote volume slidebar position changes. This will control the remote volume signal.

b) Media control class commentary

(1) vomediacontrol

Class VOMediaControl

Base class VOObject

Factorial type public

Friend Class-

(a) properties

(b) constructor (s)

VOMediaControl ();

(c) method

public void SetVolume (short rightVolume, shorleftVolume);

Right volume parameter: an integer between 0 and 1000.

Left volume parameter: an integer between 0 and 1000.

public void setvolume sets the volume control.

public short GetVolume (short channel);

Return value: Returns the volume for the specific channel.

Channel parameters: Set channel = PORT_CHANNEL_RIGHT for the right volume setting and channel = PORT_CHANNEL_LEFT for the left volume setting.

public short getvolume returns the current volume for the specified channel.

public void SetSeIfView (long flags);

flags parameter: Set the amount of state for self view. Valid flags are as follows:

SELFVIEW_ON Displays the self view;

SELFVIEW_OFF Hide self view; And

SELFVIEW_MIRRORED Manages the self view.

public void setselfview sets the amount of self-view state.

public long GetSelfview ();

Return value: Restores the Self View setting.

The public long getselfview function returns a self-view setting that can be used to find out if a self-view is visible, hidden, or running.

public void SetselfViewSize (short size);

Size parameter: One of the predefined sizes for self view.

public void setselfviewsize sets the size of the self-view window. Valid values are FULL_CIF, HALF_CIF, and QUARTER_CIF.

public short GetSelfViewsize ();

Return value: Returns the current self view size.

The public short getselfviewsize function returns the current self view window size. The value is one of the predefined size values. See setselfviewsize for a description of the size.

public void SetAutoGain (BOOL autoGain = TRUE);

autogain parameter: Must be true to enable auto gain, false to disable it.

public void The setautogain function enables or disables auto gain depending on the auto gain value.

public BOOL GetAutoGain ();

Return value: Restores the current auto gain setting.

The public bool getautogain function returns the current auto gain setting. True if auto gain is in progress, falserk otherwise.

pubilc void SetEchoCancellation (bool bCancel);

bcancel parameter: can be canceled if bcancel is true; If false, cancellation is impossible.

public void setechocancellation enables or disables echo cancellation.

public BOOL GetEchoCancellation ();

Return value: Returns the current echo cancel status.

public bool getechocancellation gets the current state of the current echo cancellation.

public BOOL GetechoCancellation

public short GetVideoMode (short mode = MODE_RX);

Return value: Restores the video mode.

Mode parameter: Indicates the receive or transmit mode.

public short getvideomode obtains the voice mode for reception or transmission depending on the mode value. Mode = MODE_RX for reception and mode = MODE_TX for transmission.

public short GetAudioMode (short mode = MODE_RX);

Return value: Restores the voice mode.

Mode parameter: Indicates the receive or transmit mode.

public short getaudiomode obtains the voice mode for reception or transmission depending on the mode value. Mode = MODE_RX for reception and mode = MODE_TX for transmission.

public void SetVideoWnd (HWND hWnd);

hwnd parameter: Pointer to the window where the image is displayed.

public void The setvideownd function displays the image in the window identified by hwnd.

public HWND GetVideo Wnd ();

Return value: Returns the window handle in which the image is displayed. If no window has been set, null is returned.

The public hwnd getvideownd function is called to retrieve the window handle on which the image is being displayed.

public void MakeeVideoWndResizeable (BOOL bResize = TRUE);

bresize parameter: If bresize is true, the video window can be resized;

If false, resizing is not possible.

The public void makevideowndresezeable function allows the video window to be resized when bresize = true. To make the window fixed size, bresize is set to false.

public BOOL IsVideoWndResizeable ();

Return value: Returns true if the video window can be resized; otherwise it returns false.

Call public bool isvideowndresizeable to determine if the video window is resizable.

F. Video Operator Shared Database

Database Schema

107 shows the database schema for the video operator shared database (see 40214 of FIG. 98). In one embodiment, the database includes the following table. The meeting 41104 lists details about the planned meeting and the participant 41105 lists the meeting participants and the CON_PARTCIPANT 41108 contains the keys from the meeting 41104 and the participant 41105 table, which are used to determine the participants of any given meeting. MCU 41102 includes the characteristics of other MCUs from various providers, and MCUPORT 41106 contains the MCU identification number from MCU 41102 as well as the port of the MCU used by participants to access the conference. VOPERATOR lists the image operator attributes; VOTYPES lists all types used to define conferences or participants: and VOTYPE VALUES 41107 lists the values for each defined type.

Each video operator record in the VDO_OPERATOR 41101 table contains a unique identification number in its ID field that assigns each video operator to a specific meeting outlined in the meeting 41104 table, which may appear in the Operator ID field of the meeting 41104 table. have. Each conference record in the conference 41104 table in turn contains a unique identification number in its ID field, which may appear in the confID field of the CONF_PARTICIPANT 41108 table. Similarly, each participant record in the participant 41105 table includes a unique identification number in its ID field, which may appear in the participant ID field of the CONF_PARTICIPANT 41108 table. Finally, each MCU record in the MCU 41102 table contains a unique identification number in its ID field that identifies the set of MCU ports associated with the MCU, which may appear in the mcuID feed of the MCUPORT 41106 table. Each MCU port record in the MCUPORT 41106 table may in turn contain a unique identification number in its ID field, which may appear in the mcuPortID field of the CONF_PARTICIPANT 41108 table. CONF_PARTICIPANT 41108 The confID, participant ID, and mcuPortID values in the table are used as cross-reference keys to define a particular conference as a given conference profile, participant set, and MCU port.

Each VOType record in the VOTYPE 41103 table also includes a unique identification number in its ID field that identifies the numerical set associated with the VOType, which may appear in the typeID field of the VOTYPEVALUE 41107 table.

G. Video Operator Console Image User Interface Window

1. Main console window

FIG. 108 shows an embodiment of the main console window 41201 as shown in the video operator terminal [1 of FIG. 96], which shows the possible arrangement of the schedule window 41201, the conference window 41203, the video visual window 41204 and the console output window 41205. Show the layout. The main console window 41201 allows the video operator to manage video conferencing.

2. Schedule Window

109 shows one embodiment of a schedule window 41202, which displays all conferences 41305 and playback sessions 41306 coordinated by the current video operator for the next eight hours. In one embodiment, the list is updated at the same time as the application launch and has an interval of 15 minutes and the meeting ends every hour.

The schedule window may have two scrolled text areas-one for the meeting 41301 and the other for the site 41302 participating in the selected meeting. When the meeting name is double-clicked, the appropriate meeting window (4123 in FIGS. 108, 110) will appear.

3. Conference window

110 illustrates an embodiment of a conference window 41203, which is displayed when an operator selects a conference or playback session in a schedule window 41202. The display of the conference window 41203 depends on whether the conference or playback session is selected from the schedule window 41202. Only one conference window is displayed at a time. When a new conference window is opened, the current window is hidden. Even when the conference window is hidden, the conference and connection status are still checked. 110 shows conference session 41401. The conference window 41203 displays a list of conference participants 41415 and radio buttons that selectively activate individual connections, including call setup, viewing, playback, and recording.

Meeting information and meeting type such as duration, start time, end time, playback and recording status are displayed at the bottom of the window. When the operator double-clicks inside a meeting window 41203 where there is no execution associated with the clicking location, a status box (41701 in FIG. 113) is displayed in the meeting settings.

The meeting ends by pressing the End Meeting button. This will disconnect all calls related to the conference.

The conference window 41203 displays their connection state 41417 including any free MCU port slots reserved for connection in the conference and connection 41421 that is not yet joined.

Each connection listing includes 41418-41420, including radio button 41422, participant site name 41423, and status. Both call states and associations are checked and displayed with the site name in the conference window 41203. Status boxes 41418-41420 are colored boxes, with different colors indicating different call states (eg, no call, call in progress, active call, or disconnected call active call).

The conference window 41203 installs a button to click 41417 which defines the order in which the participant site is connected to the MCU port site and routed through the video operator. Another feature that can be used from this part of the window is to monitor the video input from the call, record the video input from either call, and make a regular video call to the participant site or MCU.

The color of arrow 41424 indicates the state of each call. The color of the arrow is also replicated to the status lights 41418-41420 in the contact list.

If there is a playback connection 41425 associated with the conference, only one call is needed between the MCU ports. The regular participant site call setup interface may not be accessible and joint control 41405 may be a start and stop switch for playback.

The free MCU port can only be reached when the MCU port call for a defined connection is idle (or disconnected). This allows the operator to join the conference as if they were a participant. This is accomplished by selecting a connection with a free MCU port call. When connected, the operator can inform the remaining participants that the operator is attempting to contact or recover the connection.

There are some functional limitations that may be reflected in the conference window 41203. The conference window 41203 should not allow access to functions that cannot be executed, for example

The image operator can only view one call at a time.

The video operator can record any call at any time on the software unidirectional decoder.

• Playback connection selection changes the call setup button accordingly.

The video operator can only join the meeting when the MCU port call is idle.

The video operator can only talk to the participant site when the participant is disconnected.

In short, a simple connection using the conference window proceeds as follows. By pressing the call button near the participant site box 41402, the operator calls Adam (or, optionally, Adam may call the operator) and the operator then places the call on hold 41407. By pressing the call button near MCU port site box 41403, the operator calls the MCU and then places the call on hold 41408. By pressing the combine button 41405 the two calls are combined. According to another embodiment, the above may be an automatic process rather than a manual process. Adam and the MCU are now connected as H.320 video calls. All three arrows 41424 will be green.

4. Video

FIG. 111 shows an embodiment of a video visual window 41204, which displays H.320 input from a call of a selected conference connection or a separate incoming or outgoing call. The visual time window 41204 also has media controllers such as control 41512 and voice control 41509-41510 for making regular calls.

The visual time window is a display for unidirectional H.320 decode of the video output of the selected call. By default, the MCU call of the first active site will be displayed. The appropriate view button must be pressed in the conference window to view any other call. Image and audio control for the window, such as volume control 41509-41510, picture size 41511, etc., is managed from an image control panel.

When the operator decides to make a regular H.320 video call to a site or available slot in an active conference, the video visual window 41204 is used to view the video. The small self-view image window should appear close when the operator selects the self view button 41506.

5. Console Output Window

112 shows an embodiment of the console output window 41205 displaying all error messages and alerts 41601. The window can scroll so that the image operator can see all the errors that occur in the current session. The above messages are also logged to a text file for future reference.

6. Status dialog box

113 shows state quantity dialog 41701. Dialog boxes are transitional windows that are displayed only temporarily. The window is generally used to enter data or display information that requires immediate attention. This can be an informal dialog box that displays the status of a particular meeting or site. Only one such window can be open at any time. When the user focuses on another conference window or connection window, the same dialog box is updated with the appropriate amount of status. 113 shows a state quantity associated with a particular site, including site coordinator 41702, site telephone number 41703, time 41704, connection type 41705, and terminal type 41706. The close button 41707 closes the state quantity dialog 41701.

XVII. WORLD WIDE WEB (WWW) BROWSER CAPABILITIES

A. User Interface

The visual user interface is designed so that only a single IP from the workstation to the server is required. The single IP connection supports both Internet connection between WWW browser and WWW site and message connection between PC client and Universal Inbox (ie Message Center). The PC client interface is integrated into the WWW browser interface so that both components can reside on the same workstation without sharing between two applications and share a single IP connection.

WWW browser access is supported from any commercially available WWW browser interface:

Microsoft Internet Explorer;

Netsscape Navigator (1.2,2.X); or

Spyglass Mosaic.

The WWW browser interface is also optimized to support Windows 95; However, Windows 3.1 and Windows 3.11 are similarly supported.

The WWW browser interface detects display characteristics of the user's workstation and adopts a presentation that supports the display settings of the workstation. The presentation is optimized around a 640x480 pixel display but can also take advantage of the enhanced resolution and display quality of an 800x600 (or higher) monitor.

In order to improve performance, the user may select a 'miniature picture' or 'front picture' presentation. The WWW browser can detect whether the user has selected a 'miniature image' or a 'front image' and can only transmit the appropriate image file.

B. Performance

The response time for downloading information from the WWW site or personal homepage to the user's workstation or terminal meets the following benchmark.

Workstation configuration:

Processor: 486DX-33 MHz;

Memory: 12 MB;

-Monitor: VGA, Super VGA or XGA;

Access: dial-up;

Windows 95;

Presentation options; Full Graphics; And

-Weekly devices: voice card, voice player software, 14.4Kbs modem

After the screen or page is downloaded from the WWW site to the workstation, it is placed ahead of time on the first required field or an updatable field.

C. Personal Homepage

The system provides the subscriber with the ability to set up a personal home page that provides a means of delivery for a person meeting with the subscriber or a scheduled meeting with the subscriber. A person accessing a subscriber's personal homepage is referred to as a guest and a user with a personal homepage is referred to as a subscriber.

Guest-access to your personal homepage will support the following features:

Create and send a text based pager via network MCI paging;

Create and send email messages to email (MCI mail or Internet MCI) accounts; And

Access to subscriber's calendar to plan meetings

Messages made through the subscriber's personal homepage are directed to the subscriber's network MCI or SkyTel Pager or MCI email account.

Guest configured email is:

The email header will show the subscriber's name, not the subscriber's email address:

We will provide fields in the email header for the following:

Sender Name (field required)

The sender's email address (optional field), and

-Topic (optional field).

The guest 'requests' the selection on the subscriber's personal home page.

The requested selection on the subscriber's personal home page will begin first with "(R)".

Approved appointments will begin first with "(A)".

Subscribers are responsible for regularly checking their calendars and approving "(A)" or clearing the requested elections and initiating any subsequent subsequent communications to the requesting party. Approved selection will be initiated by "(A)".

Security requirements

Calendar access from the personal homepage is designed to support two phases of security:

No Pin Access:

-Times Only, or

Times &Events;

Pin Access:

-Times Only, or

-Times & Events.

1. Memory requirement

The system accumulates and maintains past and future selections in the following ways:

Current month in addition to last six months of series calendar choice

The current month in addition to the next 12 months of future calendar selection.

Subscribers are given the option to download monthly selections of content planned to be overwritten in the database. The calendar information to be downloaded to the subscriber is in comma demarcation or DBF format and can be imported into Microsoft Schedule +, ACT or Asend.

2.On Screen Help Text

On Screen Help Text provides guest and subscriber icon access to handle specific "Help" instructions operating within the personal home page. The Help Text should provide information describing:

A method of sending a text based pager message from the personal homepage to the subscriber via the network MCI;

• sending an email message to the subscriber from the personal homepage to the MCI email account;

How to access and update the subscriber's calendar;

How to locate a user's personal home page; And

How to arrange your own personal home page through MCI.

3. Personal home page directory

The above gives the guest the ability to access the personal home page directory through the current MCI home page. The directory may be configured for a particular personal home page address by specifying in detail the guest's last name (required), first name (optional), organization (optional), state (optional), and / or Zip code (optional). Allows to retrieve all set personal page accounts. Results from personal home page directory searches return the following information: last name, first name, middle initial, organization, city, state, and Zip code. Cities in the search field, although not required, are provided in the search results.

Another way a guest can be located on a personal home page is through a WWW browser. Many WWW browsers have a search function for 'net directories'. The user's home page is listed in a directory of Internet addresses provided by the WWW browser. The advantage of guiding your search from the MCI home page is that only the personal home page is indexed (and searched). Guiding a search through the WWW browser menu option cannot limit the search to a personal home page and therefore will guide the search through an extensive list of URS. The guest also has the ability to enter a special URL (ie an open location) for the personal home page rather than performing a search. This is especially important for those subscribers who have their personal home pages not listed in the directory.

4. Control Bar

The control bar appears at the bottom of the personal home page. A control bar appears after the guest selects a personal home page from the MCI home page. The control bar provides the following features for guest access:

Help Text

MCI Home Page

Personal Home Page directory

Feedback

5. Home page

The home page is the entry point for the subscriber to practice profile management from the WWW browser and to perform a message retrieval. The home page is designed to provide the user with easy access to the message center or profile management.

6. Security Requirements

Access to the message center or profile management is limited to authorized users. Users are prompted to enter their user ID and password before accessing the message center or profile management. After three failed attempts, the user is denied access to the message center or profile management and a warning message advises the subscriber to contact the MCI Customer Support Group. The count is deactivated until the representative MCI Customer Support recovers the count. When the count is restored, the subscriber is required to update his password.

Successful logon to the message center allows the user to access profile management without requiring another (ie, identical) user ID and password. The same also applies to users who have successfully accessed profile management-they are allowed to access the message center without requiring another (ie identical) user ID and password.

The password is valid for one month. Users are prompted to renew their password if the password expires. Renewing the password requires the user to enter a new password and an expired password twice.

7. OnScreen Help Text

Enhance icon access to field subscribers with specific "Help" instructions that operate within the home page. The help text above provides information describing:

How to access the message center;

A method of accessing profile management;

How to access the MCI home page;

A method of accessing a personal home page;

A method of sending (ie generating or delivering) a message via a message center;

A method of filing a message via a message center;

how to update the directlineMCI profile;

A method of updating the information service profile;

-How to update their personal home page;

-Providing feedback on the home page; And

-How to sort the user guide.

Control bar

The control bar is displayed at the bottom of the home page. The control bar gives the guest access to the following features:

Help Text;

-MCI Home Page;

-Personal homepage directory; And

-feedback

8. Profile Management

In addition to the on-screen help text and control bar described above, the profile management screen shows a title bar. The title bar provides subscribers with easy access to profile management components and quick access to the message center. Access to the profile management component is provided through the use of tabs, including:

directlineMCI;

-Information services;

A personal home page;

List management; And

Message processing

The directlineMCU tab includes additional tabs for the following basic components of directlineMCI:

-Voicemail;

-Fax mail;

Paging

The directlineMCI Profile Management System provides a Profile Management page, which is the starting point for processing account profile information to:

Create a new directlineMCI profile and assign a name to it;

-Update the current directlineMCI profile.

Supports logic based on the rules for creating and updating directlineMCI profiles (for example, selecting only one call routing option, such as voicemail, will affect all affected, such as override routing to paging and paging notifications). Cause an update made to one screen ripple through the screen);

allow directlineMCI number;

-Allow and define override routing numbers;

-Permit and define FollowMe routing; And

define the RNA parameters for each number in the directlineMCI FollowMe routing sequence;

Allows and specifies the final routing (formerly called alternate routing) to:

-Voicemail and pager,

-Only voicemail,

-Only pagers, and

-Last message;

-Recall menu routing if two or more call routing options (FollowMe, voicemail, faxmail or pager) are allowed;

-Allow voicemail;

-Allow fax mail;

Permit paging;

-Specify default numbers for faxmail delivery;

Activate paging notification for voicemail;

-Enable paging notification for faxmail;

Specify a schedule to enable / disable other directlineMCI profiles;

-Provide the guest with the option to classify voicemail for urgent delivery;

Configure and configure time zones for all message types that can be used to identify the time a message was received;

Specify call screening parameters for:

-Name and ANI.

-Only ANI, and

-Name only; And

-Permit or disallow parks and pages.

9. Managing Information Service Profiles

Information service profile management provides subscribers with the ability to select the information source and content dependent delivery frequency, information source, and delivery mechanism (voice mail, pager, email). In particular, the subscriber has the ability to configure and arrange any source of information such as:

-Stock quotes and economic news; And

-Headline news.

Stock quotes and economic news provide subscribers with:

-Transaction news headlines;

-Stock quote (within 10 minutes)

-Stock market reports (hourly, AM / PM or COB);

Precious metal reports (hourly, AM / PM or COB); And

-Product report (hourly, AM / PM or COB).

Transactional news headlines are delivered via email once a day. Reports (stock markets, currencies and bonds, precious metals and commodities) are delivered at specific intervals by the subscriber. The hourly report requires that the e-mail message be time stamped 10 minutes after the time. The AM / PM report requires one email message to be sent in the morning (11:10 AM Eastern Time) and one email message to be sent in the evening (5:10 PM Eastern). The time is sent at 5:10 pm.

The content of the stock market report includes:

-Stock or mutual fund quote symbol;

-Quotes for opening stocks or mutual funds;

-Stock or mutual fund closing quotes;

-The last recorded bid quote for the stock or mutual fund;

-The last recorded ask quote of a stock or mutual fund;

-52-week high for stocks or mutual funds; And

-52-week low for stock or mutual funds.

Stock quotes and economic news also give subscribers the ability to select from a list of available stocks and mutual funds and define the criteria by which pages based on voicemail or text are presented. The above definable criteria are referred to as 'trigger points' and can be any or all of the following situations:

-Equity or mutual funds hit 52-week highs;

-Equity or mutual funds hit 52-week lows;

-Equity or mutual funds are at their peak as defined by the user;

-Equity or mutual funds have reached the minimum specified by the user.

After the trigger point situation is met, a message (pager based on voicemail or text) is sent to the subscriber within one minute. Voicemail messages are directed to the subscriber's mailbox as defined in the user's directlineMCI account. The information content for stock quotes and economic news is new information of 10 minutes or less.

10. Personal home page profile management

Personal home page profile management provides subscribers with the ability to customize their personal home pages and define how the guest can communicate with them (pager based on email or text). Profile management also allows subscribers to control guest access to their calendars. In particular, the subscriber may do the following:

-Setting and maintaining greeting messages;

-Setting and maintaining contact information;

Setting and maintaining a personal calendar;

-Allow or disallow guest access to paging, email or calendar;

Controlling guest access to the calendar by defining a PIN for standard or privileged access;

-Incorporate a submitted image of an authorized subscriber, such as a personal photo or group logo, at a pre-defined location on the personal home page.

Simultaneously with the generation of the personal home page, the contact information is located in the subscriber's forwarding address information. The subscriber has the ability to update what the address information contains in the contact information.

11. List Management

List management gives subscribers the ability to create and update lists. Profile management provides the ability to define lists that can be accessed through the message center for message distribution. According to one embodiment, list management is centralized and thus the fax broadcast list management capability is integrated into the directlineMCI list management capability to provide a single database of lists. According to an alternative embodiment, the two list management systems are separated so that a user can access any one database in the list.

The list is provided through an interface similar to an address book on a PC client that allows subscribers to add and delete list names. An e-mail address, fax mail address (ie ANI), voice mail address (ie ANI) and pager number are associated with each individual name. When a message is located in a message center inbox (ie universal inbox) the address book is updated with the source address of the associated message type.

When a subscriber selects a distributed list, the subscriber is prompted to choose a name, type and distinguished name of the list. All generated lists can be used in alphabetical order by name. The type of list (voice, fax, e-mail, page) is accompanied by the list name. In addition, the list distinguished name may be composed of alphabet characters.

The subscriber is then reminded of the recipient name and address to generate a distribution list. The subscriber can access the address book for recipient information. The subscriber is not limited to writing the same address type in his list; When the list is generated in fax type, the subscriber may include ANI, email, and paging address in the list. The subscriber can manage his distribution list along with the ability to create, review, delete, edit (add and delete recipients) and rename.

When the user chooses to modify the list via the WWW browser interface, he is prompted to select an address type (voice, fax, paging, email) and a list of the user's distributed list must be provided for that address type. The user can also enter a list name where the list is located. The user can modify the list by creating, reviewing, editing (adding or deleting recipients), deleting and renaming commands.

Each time a subscriber modifies the list through recipient addition, deletion or address change, he can make the modification a global change. For example, the user changes the voice mailbox address for Mr. Brown in one list. He can make the above a global change that changes the address for Mr. Brown in all distribution lists. When the subscriber can create and modify distribution lists via ARUs and VRUs in addition to PCs, enhanced list maintenance capability is supported through the WWW browser interface.

The subscriber may search and sort by name or other address field. For example, a user can use the * DOLE * command within the search function to search all lists containing * DOLE *. The user can also search the list using any address field. For example, a user can search based on recipient number, 'to' name or zip code. The user can sort the list by list name, identifier and type or any address field.

In addition to the retrieval capability, the distributed list software enables the user to copy and create sub-lists from the current Busan List record. The user can import or export recipient data from an external database structure.

There is also the ability to share lists among users and upload lists to hosts.

12. Global message processing

Global message processing provides the subscriber with the ability to specify the type of messages that may appear in a "universal inbox" or accessed via a message center. The following message types can be selected:

directlineMCI voicemail;

directlineMCI faxmail;

networkMCI and Sky Paging; And

Email from an MCI email account (ie MCI Mail or internetMCI)

If the subscriber is not registered for a particular service then the option will be grayed out and thus cannot be selected within global message processing. Any update of global message processing results in a real time update to the message center. One example is that the subscriber can choose to allow voice messages to appear in the message center. The message center automatically retrieves all voicemail message objects present in the voicemail database.

D. Message Center

The message center functions as a "universal inbox" for retrieval and processing of message objects. The "universal inbox" consists of a folder containing messages sent to the user. Access to the message center is supported from the WWW browser, but the content contained in the "Universal Inbox" represents the following message types:

Voicemail: sent to the user's directlineMCI account;

E-mail: sent to the user's MCI e-mail (ie MCI mail or internetMCI) account;

-Fax mail: sent to your directlineMCI account; And

Paging: The user's networkMCI paging account (or SkyTel paging account).

In addition to the On-Screen Help Text and control bars described in the previous section, the message center screen displays a title bar. The quotient bar provides subscribers with easy access to message center functions and provides quick access to profile management. Message center features supported through the title bar include:

File: lists the user's defined folder and allows the user to select a folder;

Create: construct a new email message;

Delivery: the voicemail is delivered as email attachments;

Search: provides the ability to search based on message type, sender name or address, subject or date / time; And

-Save: Allows the user to save the message to a folder on the universal inbox, a file on the workstation, or a diskette.

When composing or delivering a message through the message center, the user has the ability to send the message by either email or faxmail. The only limitation is that the voicemail can only be delivered as a voicemail or email attachment. All other message types can be interchanged so that an email can be delivered to a fax machine or a pager message can be delivered as an email text message. Messages sent as faxmail messages are created in G3 format and support distribution to lists as fax broadcasts.

The presentation layout of the message center is consistent with the presentation layout of the PC client and therefore they have the same look and feel. The message center is designed to represent a message header frame and a message preview frame, similar to the presentation supported by nMB v3.x. The user will have the ability to dynamically resize the message header frame and the message preview frame to some dimension. The message header frame will display the next envelope information.

Message type (email, voice, fax, page);

-Sender name, ANI, email address;

-subject;

Date / time; And

-Message size.

The message preview frame displays instructions on how to execute the first line of the email message body, the first line of the first page of the faxmail message, the pager message, and the voicemail message. Execution of voicemail messages through the WWW browser is supported as a flow voice capability and therefore the subscriber is not required to download the voice to the subscriber's workstation before its operation. The flow voice is initiated after the user selects (one left mouse click) on the voicemail header of the message header frame. The display of the faxmail message is initiated after the user has selected (one left mouse click) on the faxmail header of the message header frame.

The message center also allows the subscriber to use a distribution list created in profile management. The distribution list supports the transmission of messages between different message types.

In addition to basic message retrieval and message distribution, the message center supports the creation and maintenance of message folders (or directories) within the universal inbox. Initially, users are restricted to the following folders:

-Draft: retain all stored messages that have not been sent;

Inbox: Holds all messages received by the "Universal Inbox", which is the default folder that appears when a user accesses the Message Center.

Send: hold all sent messages; And

-Trash bin: Retain all messages marked for deletion for 7 days. The subscriber will eventually be able to create (and rename) a folder (and a folder within the folder).

1. Storage requirement

Initially, the user is allocated a limited amount of storage for directlineMCI voicemail and directlineMCI faxmail. Pager recall messages and email messages are limited based on the date / time stamp of the received message rather than the amount of storage space consumed. Eventually storage requirements are implemented based on common units of measure. This facilitates the user to recognize when messages are deleted from the database and when guests are prevented from accumulating messages in their "Universal Inbox". To support this, the storage requirements for messages held in the inbox are as follows:

directlineMCI voicemail: 60 minutes;

-directlineMCI faxmail: 50 pages;

-networkMCI page: 99 hours; And

Email: 6 months.

The subscriber is given the option to download messages intended to be overwritten in the database except for messages held in the trash folder.

E. PC Client Capabilities

1. User Interface

The PC client interface supports subscribers who wish to operate in an accumulation and delivery environment. The user wants to download a message that is processed or stored locally. The PC client is not designed to support profile management and the PC client interface only presents a message (voicemail, faxmail, email, text-page). Access to profile management capabilities can only be used through the ARU interface or the WWW browser interface. The PC client interface is integrated with the WWW browser interface so that both components can reside on the same workstation and share a single IP connection. The PC client interface is optimized to support Windows 95. Windows 3.1 is similarly supported.

The visual user interface is designed to present a message header window and a message preview window similar to the presentation supported by nMB v3.x and supported by the WWW browser. The user has the ability to dynamically resize the height of the message header window and the message preview window. The message header window displays the following envelope information:

Message type (email, voice, fax, page);

Sender's name, ANI, email address;

- subject;

Date / time; And

-Message size.

The message preview displays instructions on how to display the first line of an email message or pager message body or a faxmail message or to execute a voicemail message. Execution of voicemail messages from a PC client requires a voice card provided on the PC. The display of the faxmail message invokes the faxmail reader in the PC client.

The message center allows users to use the distribution list created in profile management. The distribution list allows message transmission between different message types.

2. Security

User confirmation between the PC client and the server is negotiated during the dial-up logon session. Security is supported so the user ID and password are imprinted on the information passed between the PC client and server when setting up the interface. Subscribers are not required to enter their user ID and password manually. The update to the password is also communicated with the PC client.

3. Message Search

Message retrieval provides subscribers with the ability to selectively search for voicemail, faxmail, pages and email located in the "Universal Inbox". Message types displayed or executed from a PC client include:

directlineMCI voicemail;

directlineMCI faxmail;

networkMCI paging; And

E-mails from MCI e-mail accounts;

The PC client initiates a single communication session to retrieve all message types from the "Universal Inbox". The single communication session can access an upstream database including voicemail, faxmail, email and pages.

The PC client can also perform an optional message retrieval so that the user can do the following:

-Search all messages;

Searching the full text (or body) for the selected message header;

To search for messages based on editable search criteria:

-Priority message;

-Email message;

Pager messages;

-Faxmail messages (complete or header only);

-Voicemail messages (complete or header only);

Sender name, address or ANI;

Date / time stamp on the message; And

-Message size.

The heading only faxmail message from "Universal Inbox" is held in "Universal Inbox" until the message body is retrieved. Voicemail messages are retained in the "Universal Inbox" until the subscriber accesses and deletes the "Universal Inbox" through the WWW browser (ie, message center) or the ARU. Messages retrieved from "Universal Inbox" are moved to the Desktop folder.

The PC client can also support background and scheduled polling so that the user can execute message processing (create, edit, forward, save, etc.) when the PC client is searching for the message.

4. Message Handling

Message processing has the ability for subscribers to execute many standard messaging client actions, including:

Composition (generation) of e-mail, faxmail or pager messages;

Delivery of all message types;

- Save;

- edit;

- delete;

- Dispersion;

Attach;

-Search; And

-Display or execute the message.

F. Order Entry Requirements

Additional interface options are provided for directlineMCI or networkMCI Business customers to implement profile management and message management functions. Accounts are automatically provided to both directlineMCI and networkMCI Business customers to access features and functions that can be used through different interface types. The ability to provide accounts to networkMCI Business customers is also supported. However, accounts are not available to all networkMCI Business customers. Order entries are flexible enough to generate as many accounts for networkMCI Business customers as needed.

Order entries are designed so that access to additional interface types and services provided by the system is automatically provided to directlineMCI or networkMCI Business customers. For example, customers who order directlineMCI (or networkMCI Business) are provided with an account to access the home page for Profile Management or Message Center. Checks are made to prevent the deployment of two accounts (one from directlineMCI and one from networkMCI Business) in the customer. To achieve this, an integration between two order entry procedures is established.

Integrated access to order entries requires a single interface. The interface incorporates order entry capability so that the order entry appears to be located in one order entry system and does not require an order entry manager to establish an independent logon session in a multiple order entry system. The integrated order entry interface supports the same order entry methodology for all services and can obtain information from the required order entry system. The interface also supports the ability to view services related to the user's current task.

The specific conditions of the integrated order entry interface system are as follows:

Automatic provisioning defining MCI email (MCI mail or internetMCI) accounts;

automatic provisioning defining networkMCI paging accounts (or SkyTel paging accounts);

-automatic provisioning of directline MCI accounts;

Automatic provisioning to enable fax broadcast capability;

The ability to manually enter MCI email account, networkMCI paging account or directlineMCI account information;

-Ability to enable or disable access to inbound information services; And

-Ability to enable or disable access to foreign information services.

This capability gives the order entry manager the flexibility to add a user based on existing MCI service (email, paging, directlineMCI) account information. Alternatively, the order manager may add a user when describing the underlying service in detail.

The order entry system provides customer account and service information required for the downflow charging system. The system also tracks the initial customer order and all subsequent updates in order to allow the MCI to interfere with sending duplicate platform software (ie, PC client) and documents (ie, user guide). The order entry process also allows the administrator to obtain the following information:

Recording of customer delivery and names;

Support of US and Canadian addresses, and

-P. O. provision of the ability to disrupt transmission to boxes;

-Record the customer's billing address, telephone number and contact name;

-Recording of the order date and all subsequent updates;

A record of the name, number and zone of the Account Representative that submitted the order;

-Record and obtain the user's directlineMCI number;

Recording and obtaining the user's networkMCI paging PIN;

-Record and obtain the user's MCI email account ID;

Generation of a run report electrically sent to the run house; And

-Number of incoming orders;

an order number for generating a networkMCI paging (or SkyTel paging) account;

An order number for generating the MCI email account; And

-directline The order number that generates the MCI account.

Personal home pages can be ordered for customers. The customer delivery information recorded during the order entry is default address information provided further from the user's personal home page. The order entry process can also support the installation and charging of special images.

There is the ability to change the current features / functions 'on' and 'off' for a particular picture. Features that can be managed by the user are identified within the order entry system. The feature is then activated for management within the user's directory account.

Real-time access capability exists between the order entry system and the user's directory account. The account provides a location space for all services, product features / functions, and account information of the user regardless of whether the user is a managed user. The item which is not identified as the managed user cannot be accessed through the user's interface.

1. Preparation and Achievement

Access requirements are defined in the items of inbound access to the system and outbound access from the system. Inbound access includes how a user or caller can access the system. According to a preferred embodiment, foreign access includes how the user is handled by the system. The Internet is supported for both domestic and foreign processing.

The following components may provide inbound access;

directlineMCI: 800 / 8XX;

MCIMail: 800 / 8XX, email address;

networkMCI paging: 800 / 8XX; And

networkMCI mail: 800 / 8XX, POP3 email address.

The following components are identified for foreign access:

-directlineMCI: dial 1;

Fax broadcast: 800 / 8XX, local;

MCI Mail: 800 / 8XX, email address; And

networkMCI mail: 800 / 8XX, POP3 email address.

G. Currency System

Calls are supported according to current MCI procedures.

H. Pricing

Initially the feature is priced according to the current pricing structure defined for the underlying component. In addition, taxation and discounting capabilities are supported for the basic components as they are currently supported. Discounts are also supported for customers who have subscribed to multiple services.

I. Charge

The billing system is:

-support charging for directline MCI enhanced services (voice mail, fax mail, both);

-Support charging for the highest and lowest rates;

Support discounts for multiple services (directlineMCI, networkMCI business, networkMCI paging, networMCI cellular) that change based on the number of services;

supports the ability to suppress networkMCI cellular charging for directline MCI calls (sending and receiving);

-Supports charges for monthly fees that are sensitive to direct MCI usage;

-Support sales promotion in the form of free time based on directline MCI usage;

-Support charging for personal home pages;

Support the ability to suppress charges on personal home pages; And

-Support SCA pricing.

According to one embodiment, the billing system supports the current billing process that exists for each basic component. According to an alternative embodiment, charging provides a firm invoice delivery that includes all the basic components. In addition to sending invoices, direct charging is now supported for all of the basic components that support direct charging.

XVIII. DIRECTLINEMCI

The description of the structure of the system modified for use of the directlineMCI system is as follows. The document addresses the general data and call flows in the directlineMCI platform and details the network and hardware architecture required to support the flows. The charging flow of downflow systems is handled at a very high level. Order entry (OE) flow in upstream systems is handled at a very high level. Any part of the directlineMCI structure reuses the current component (eg voice response unit (ARU)). This part of the new directlineMCI structure is covered in more detail.

A. Overview

In addition to billing, order entry, and alerts, the directlineMCI system consists of three main components shown in Figure 43:

Voice Response Unit (ARU) 502

-VFP (Voice Fax Platform) 504

Data Distribution Service (DDS) 506

The subsections below describe each major component at a high level. 43 shows a high level of relationship between main system components.

1. Voice Response Unit (ARU) 502

ARU 502 handles the first domestic outbound call to directlineMCI. Some features (such as find me / follow me) are implemented entirely on the ARU. Inbound faxes are tone-detected by the ARU and extended to VFP 504. The menuing provided by the ARU is used to request access to the voicemail / faxmail feature, in which case the call also extends to the VFP.

2. Voice Fax Platform (VFP) 504

The VFP provides menuing for voicemail / faxmail features as well as foreign fax and voice delivery and pager notification. The VFP is also a central data store for on-demand subscriber prompts that are activated and recorded by the ARU.

3. Data Distribution Services (DDS)

The DDS is a repository for OE Profiles and Billing Details Records (BDRs). OE profiles accumulate in the DDS, which causes the profile to be distributed to all appropriate systems. DDS 506 collects the BDR and transports the BDR to the downflow billing system.

B. Rationale

The requirement for directlineMCI is to integrate the various service components into a single service accessed by a single 800 number. The number of service components is pre-deployed on the ISN ARU platform. Services that do not appear on the ARU are mailbox services and fax services. The ARU 502 of the system 500 integrates a voicemail / faxmail platform purchased from Texas Instruments (TI). Portions of the software are ported to run on DEC Alpha machines for performance, reliability and scalability. Another requirement for directlineMCI implementation is the integration of mainstream (current MCI) charging and order entry systems. The DDS provides domestic and foreign interfaces between the directline MCI and the main flow order entry system.

C. Details

43 shows the relationship between the main system components. The 0E system 508 generates a subscriber profile that is downloaded to the SRU 502 and Voice Fax Platform (VFP) 504 via the DDS 506. The BDR generated by the ARU 502 and the VFP 504 is supplied to the billing system 510 via the DDS. The ARU 502 handles all inbound calls. If a fax tone is detected or a voicemail / faxmail feature is required, the call extends from ARU 502 to VFP 504. For mailbox status (eg "You have three messages") the aru 502 queries the VFP 504 for status and triggers a prompt.

The subscriber's order production prompt is stored in the VFP 504. When the ARU activates an on-demand prompt or records a new prompt, the prompt is accessed on the VFP 504. Alerts from ARU 502 and VFP 504 are sent to a Local Support Element (LSE).

1. Call Flow Structure

The call flow structure for directlineMCI is shown in FIG. 44. The upper part of the figure shows the network 522 connectivity used to carry the call. The lower part of the figure shows the calling direction for various call types. The subsections below provide a description accompanying the drawings.

2. Network Connectivity

All inbound ISN calls are received at an automatic call spreader (ACD) connected to the MCI network 522. An access control point (ACP) receives inbound calls from an Integrated Services Network Application Processor (ISNAP) 526, which is a control / data interface to the ACD 524. The network voice system (NAS) operates and records voice to ACD via the T1 interface under the control of ACP. In the United States, digital multiplexing systems use the first level of multi-transmission, known as T1, to provide 24 digitized voice channels over four-line cables (a pair of lines that 'send' a signal, a pair of lines that receive a signal). It is adopted where it combines. The conventional bit format on a T1 carrier is known as DS1 (i.e., first level multi-digital digital service or digital signal format), where DS1 is a sequence in which each frame has 24 PCM voice channels (or DS0 channels) of 8 bits each. Frame is made up. Each frame has additional frame bits for control purposes, totaling 193 bits per frame. The T1 rate is 8000 frames per second or 1.544 megabits per second. The frames are aggregated for T1 transmission using a technique known as time division multiplexing (TDM), where each DSO channel is assigned 24 sequential time slots within the frame, each time slot being an 8-bit word. It includes.

Transport over a network of local, regional, and long-distance service providers involves sophisticated call processing through various switches and hierarchies of multiple carriers. At the pinnacle of conventional high-speed transmission is the simultaneous optical network (SONET), which uses fiber optic media and can transmit in the gigabit (greater than 1 billion bits per second) range. After delivery over the network, the high level multiple carriers are demultiplexed back to individual DSO lines, decoded and connected to individual subscriber phones.

Typically multiple signals are multiplexed over a single line. For example, DS3 transmission is typically carried by coaxial cable and combines 28 DS1 signals at 44.736 Mbps. The low-level OC3 fiber carrier in the fiber layer combines three DS3 signals at 155.52 Mbps, providing capacity for the 2016 individual voice channels of a single fiber-optic cable. SONET transmission carried by optical fiber can have very high data rates.

NSA / ACP binding is referred to as ARU 502. If the ARU 5092 determines that the call should be extended to the VFP 504, the ARU 502 dials the VFP 504. The VFP media server is connected to MCI network 522 via T1. Data transfer from the ARU 502 to the VFP is accomplished via dual tone multiple frequencies on each call.

3. Call flow

The calling scenario of FIG. 44 is described in detail below. At the start of any inbound call the ARU 502 executes application selection to determine whether the call has already been received and the call is a directlincMCI call.

a) domestic fax:

Inbound fax calls are forwarded to aru 502. The aru performs paxton detection and extends the call to the VFP 504. Account numbers and schemes are passed to the VFP using DTMF signaling.

b) domestic voice, ARU only:

Inbound voice calls are made in either subscriber or guest mode, with only those features using ARU 502 being accessed. The ARU determines the manner (subscriber or guest). In subscriber mode, the ARU consults the VFP 504 to determine the message number. No additional network access is made.

c) domestic / foreign voice, ARU only:

The call is made to ARU 502 and either pager notification or find me / follow me features are accessed. The aru 502 is dialed via an acd 524 to an external number.

d) inbound voice, vfp features:

The call is made to aru 502 and the call extends to vfp 504. The account number and scheme are sent to vfp via dtmf. The guest method is as follows:

1. Accumulate voicemail.

2. Accumulate fax mail.

3. Collect fax mail.

The subscriber method is as follows:

1. Receive and send mail.

2. Maintain the broadcast list.

3. Modify the mailbox name record.

The vfp 504 continues to prompt the user during the vfp session.

e) fax / voice / pager to foreign countries, vfp only:

The vfp directly dials over the mci network 522 for fax or voice delivery or pager notification.

f) resend / withdraw

When a domestic subscriber call is connected to vfp 504, the user can return to the highest level of the aru 502 directlinemcu menu by pressing the pound key for two seconds. Network 522 takes the call back from vfp 504 and resends the call to aru 502.

4. Data Flow Structure

45 depicts the main data flow of the directlinemci structure 520: The 0E record (customer profile) is input in the upflow system and downloaded in 530 to the dds main frame 532. The dds mainframe downloads the OE record to a network information distributed service (nids) server 534 on aru / acp and vfp / execution servers. The download is via an ISN token ring network 538. On execution server 536 the OE record is stored in a local execution server database (not shown).

The BDR is truncated by both execution server 536 and acp 540. The BDR is stored in an operator network center (onc) server 542 and uploaded to dds mainframe 532. Upload from the onc server 542 to the dds mainframe is via the ISN token ring network 538.

The aru 502 prompts the subscriber with their voicemail / faxmail message number. The subscriber's message number is obtained from vfp 504 by acp 540 via ISNAP Ethernet 544. Note that the acp 540 can exist at any of the ISN sites.

User-recorded ad hoc powered by NAS 546 is stored on vfp 504 and activated over network as soon as NAS 546 requests it. NFS protocol 548 is used over ISNAP local area network (lan) 544 and wide area network (wan) 550.

D. Detailed structure of voice fax platform (vfp) 504

1. Overview

Figure 46 shows the hardware components of the voice fax portion 504 of the directlinemci system for the first embodiment. The main components of the system are as follows:

TI Multiserver 400 Media Server 560.

Server 536 running DEC 8200.

Cabletron MMAC + hub 562.

AlphaStation 200 Console Manager and Terminal Server 564.

Bay Network 5000 Hub 566.

According to another embodiment, the Cabletron hub may be removed from the configuration deployment and the Bay network hub may carry all network calls.

2. Theoretical Basis

The TI multiserver 4000 560 is selected by mci for the voicemail / faxmail portion of directlinemci. The multiserver 4000 is a fairly slow 68040 device on a fairly slow nubus backplane. The 68040 / nubus device is used by TI as both media servers (dsp for TI interface, voice and fax) and also for execution servers (database and object storage). Although the hardware is suitable for media server use, it is not suitable as an execution server for servicing hundreds or thousands of gigabytes of voice and fax data and thousands of media server ports. In addition, there is no clustering (for performance or affordability) that can be used for the media server hardware. Thus the execution server portion of the TI implementation is ported by the MCI to operate on the DEC Alpha 8200 cluster 536 described below. The clustering provides for both failover and loadsharing (and thus scalability) quantum.

Similarly, gigabytes that must be moved from the high speed 8200 platform must be moved over the network to the TI media server. Cabletron hub 562 with both Fiber Distributed Data Interface (FDDI) and switched 10bT connectivity provides the backbone for implementation. Each media server 560 is attached to a spare pair of switched Ethernet ports.

Since each port is a switched port, each media server has a dedicated 10 Mb bandwidth to the hub. Each 8200 server 536 needs a large network pipe to service many small 1OMb Ethernet pipes. In a first embodiment, the FDDI interface 568 may be used. However, call projections require that the required call exceed the FDDI capacity for several hours, and therefore in a preferred embodiment will use a high speed networking technology such as ATM. The hub 562 is completely redundant.

Alpha Station 200 Workstation 514 is required for operation support. The Alpha Station 20O provides console management to each driectline MCI VFP 504 component through DEC's Polycenter Console Manager. The Alpha Station 20O also runs DEC Polycenter Performance Analyzer software. The performance analyzer software collects and analyzes data from the 8200 for tuning purposes.

3. Details

47 shows a production installation of VFP 504 at a production site. Note the relationship between FIG. 47 and FIG. 46. The DEC Alpha 8200 536 is in a failover configuration. The central rack is a shared disk array.

The TI MultiSub 4000 560 is essentially a complex of four separate media servers in a single cabinet. The figures following this figure show each powder (one of the four media servers of the multi server 4000) as a separator. Four each 16FGD TI is connected to each powder.

Alpha Station 200 Workstation 564 and Terminal Server are used to provide console and system management. The Cabletron Hub 562 provides a network between the server 560 and the running server 536.

Bay network hub 566 provides a network between the VFP 504 and the network router 569.

a) internal hardware network

48 shows the VFP internal hardware / network structure;

General note of FIGS. 47-49;

The left DEC 8200 device 536 is shown with both the ATM and FDDI connections 570 shown. The DEC 8200 is shown with the Ethernet connection 572 shown. In a practical deployment, both organizations have both the ATM, FDDI, Token Ring, and Ethernet connections 570 and 572 shown.

Since each 8200 536 is only half the network connectivity, the Cabletron hub 562 shows fewer connections to the ports than they actually occur. It is also shown that only one of the four media servers 560 is connected to the Ethernet port. In practice, there is one transceiver and two Ethernet connections for each media server.

Bay hub 566 is not shown in FIG. 48. The Bay hub 566 is shown in FIG. 49, directlineMCI VFP External LAN Network Connectivity.

Starting from the top of FIG. 48 of DEC 8200 536;

The phase unit includes three 4GB drives 574 for operating system, swap, and the like. System CD drive 576 is also located here.

The unit is controlled by interface 578 from the main system 579 to the Single-Ended Small Computer Systems Interface (SCSI) (" SES " in the drawing).

The tape stacker 580 is a 140GB tape unit with a single drive and 10 tape stacks. The unit is controlled by the Fast-Wide SCSI ("FWS" in this figure) interface 582 from the main system 579.

The main system unit 579 utilizes three five slots available. Slot 1 has a main CPU card 584. The card has one 300MHz CPU and can be updated with two CPUs. Slot 2 has 512 memory cards 586. The card can be updated to 2GB and another memory can be added. The maximum system memory is 4GB.

Slots 3 and 4 are empty but can be used for additional CPU, memory, or I / O boards. Slot 5 has a primary I / O card 588. The card has eight I / O interfaces:

One Fast-wide SCSI interface 582 controls the tape stacker.

Two fast-wide SCSI interfaces 590-592 are not used.

The single-ended SCSI interface 578 controls the local system drive.

The fddi interface 594 is connected to one hub.

PCI Slot 596 connects to PCI Expansion Classic 598.

One port is a 10baseT Ethernet card 600 that is connected to the corresponding card from another 8200 536 via a dedicated thinnet Ethernet. The network is required for one system failover heartbeats.

One embodiment utilizes 1/9 available slots in PCI / ISA Extended Classic 598. Slots 1 and 2 have disk adapters 602. Each disk adapter 602 is connected to a RAID disk controller 604 having another disk controller 604 (on the rest of the devices) chained, which in turn is connected to the disk controller 504 on the device. Thus each 8200 device 536 has two disk controllers 604 attached to each disk adapter 602. The device 536 is primary clustering because each device can control all of the disks located in FIG. 48 under PCI Classic 598. Slot 3 has a prestoserve board 606. The board 606 is a network file server (NFS) accelerator.

Slot 4 has an FDDI board 608. The fddi connection is made of a hub unlike the FDDI connection made from the main slot 5.

Slots 5 and 6 have an ATM board 610. The ATM board 610 has a 10baseT Ethernet card 612 which is connected to the corresponding card at the remaining 8200 536 via dedicated thinnet Ethernet. The network is required for one system failover heartbeats. Slot 10 is empty.

The two units under the PCI classic are redundant arrays of inexpensive disks (raid) disk controllers 604. Each disk controller 604 resides in a SCSI chain with two disk controllers 604 in the middle and a disk adapter 602 (one for each device) at each end. Thus there are two concatenations, each concatenated with two disk controllers 604 and two disk adapters 602. This is the connectivity to the main system 579. Each disk controller 604 supports six single-ended SCSI concatenations. In the above configuration, each of the two chains has one disk controller having two ses connections and one disk controller having three connections. Each chain has five sets 614 (or "drawers") of disk drives shown in the central rack. Note the redundant power supply from the drawer to the raid disk controller.

cabletron mmac + hub 562 (FIG. 47) consists of redundant pairs. Both the 8200 536 and TI Media Server 560 connections to both hubs 562 and the two hubs 562 are also interconnected. Starting from the left side of the hub: fddi concentrator card 616 provides eight port fddi rings. Each 8200 has one connection to each fddi card 616 on each hub 562. The 24-port Ethernet card 618 provides connectivity to the TI Media Server 560. Each media server 560 connects to one Ethernet port 618 on each hub. Each hub has eight free slots 620 that can be used for additional fddi, ATM, or Ethernet extensions.

There are four TI Media Servers 560 mounted in a single rack called the "Multiserve 4000". Each media server in the rack is identical. Starting from the upper unit and then advancing to the right in the main slot to the right: The upper unit 622 is a drawer that includes two 1 GB disk drivers and a removable / hot-insertable tape drive. There are two tape drives that can be shared between four media servers. The seven boards on the left, labeled "DSP xxx," are TI mpb boards that support six input and seven output channels, respectively. The board 624 is grouped into three sets. There is a right group of three boards, a middle group of three boards, and one group on the left. Each group has one TI. The TI ends at the interface labeled "TIM". The interface is a basic T1 interface. The T1 channel can be shared by a set of boards delimited by the base / slave boards and concatenated by a bridge module. The rightmost board 626 is the main CPU / IO board. The board supports SCSI interface 628 for the disk drawer, Ethernet connection 630 for the special transceiver 632, and provides a serial port for the console (not shown).

The transceiver 632 on the right side of the cpu / io board is connected to an Ethernet port at each of the two primary hubs 562. The transceiver detects when the Ethernet connection fails and routes the call to the remaining ports.

b) external hardware / network access

49 shows hardware and network connections from vfp 504 to the external network. In Figure 49 note the following:

Each 8200 536 is connected on the ISN token ring 640 through a bay hub for dds access via SNA and BDR access via IP. Terminal Server 642 pairs have access to the console ports of each device and hub. dec AlphaStation 200 564 runs Console Manager software to access the port connected to Terminal Server 642. The decnis router is present on both the fddi ring 568 (FIG. 46) connected between the bay hub 566 and the two dec 8200 536.

The bay hub 566 connects the vfp system 504 to the external network through the seven routers 644 shown.

E. Detailed Structure of Speech Dispersion

1. Overview

Voice distribution, as part of the architecture, refers to where NAS 546 (FIG. 45) reads and writes the subscriber's ad hoc prompt via lan or wan to / from vfp 504 using the protocol.

2. Theoretical Basis

According to one embodiment, voice distribution is performed by placing servers at each ISN site and replicating data from each server to each other through a complex deployment process.

The "large object management" (lom) project defines a network-based approach. The approach was decided to use directlinemci vfp 504 as a network based central object storage for NAS 546 to read and write customer prompts.

50 is a diagram illustrating a network structure for supporting voice distributed call according to an embodiment. 52A shows data management zone 5105 of the present invention. The data management area (DMZ) is a firewall between the Internet dial-in platform (although not the real Internet itself) and the ISN production network. The purpose of the DMZ is to provide dial-in access to data to isn customers while maintaining security for the isn network as well as the privacy and integrity of the customer data in the production ISN network.

The DMZ allows the customer to periodically receive the generated data, such as the dds data supplied from the mail frame. Such data is extracted from the database and placed in a user account directory on a secure file transfer protocol (ftp) host for subsequent retrieval by the customer.

Data access for the customer is via a dedicated port at the dial-in gateway, which is owned, operated and maintained by the Internet provider. Dial-in user verification is accomplished by using a one-time password via a security identification card, as described in more detail below. The card is distributed and managed by an Internet provider personal.

The DMZ provides a protective subnet firewall that uses packet filtering routers to protect calls from external unsecured and internal dedicated networks. Only selected packets are allowed through the router and other packets are removed. The use of multiple firewalling techniques ensures that any failure or error point in the DMZ configuration does not endanger the ISN production network.

The DMZ 5105 is intended to comply with several security standards. First, individuals who are not authorized employees cannot be allowed access to the internal production network. Therefore, IP connectivity through the gateway is not allowed. Second, access and use of the DMZ service is restricted to authorized and authorized users for specific purposes. Therefore, all other facilities and services normally found in general purpose devices are unavailable. Third, the use of DMZ services and facilities should be carefully examined to detect problems encountered by identified users and to detect potential fraud.

The central portion of the DMZ is a DMZ Bastion host 5110. The Bastion host 5110 runs an FTP server daemon that implements the modified FTP protocol, described further below. Bastion host 5110 is a highly secure device used as an external interface. The Bastion 5110 allows only limited access from the outside. The Bastion 5110 typically acts as an application-level gateway to the internal host of the ISN 5115, which provides access to the internal host through a surrogate service. In general, the critical information is not placed on the Bastion host 5110 and thus no access to the critical data is made without additional integrity compromises in the ISN 5115 even if the host is compromised.

Bastion host 5110 is connected to both internal and external users as shown in FIG. 52A. The Bastion host 5115 can be a UNX-based computer, such as the IBM RS / 6000 Model 580 running the AIX operating system.

The internal user is the user connected to ISN Production Token Ring 5115. Token ring 5115 is connected to an internal packet filter 5120, such as the Cisco Model 4500 Modular Router. The packet filter 5120 is connected to the token ring LAN 5125, which in turn is connected to the bastion host 5110. Token Ring LAN 5125 is a dedicated token ring that is isolated from all components other than the bastion host 5110 and the internal packet filter 5120, except that token ring LAN 5125 is permitted by packet filter 5120 by the token ring LAN 5126. Any access to the bastion host 5110 is blocked.

External users are connected through an external packet filter 5130, such as the Cisco Model 4500 Modular Router. Packet filter 5130 is connected to bastion host 5110 via isolated Ethernet LAN segment 5135. Ethernet LAN segment 5135 is a dedicated segment that is isolated from all components other than bastion host 5110 and external packet filter 5130. Due to the configuration arrangement, the bastion host except that any user goes through internal packet filter 5120 or external packet filter 5130. Can't access 5110

52A depicts the DMZ 5105 in relation to dial-in environment 5205. In a dial-in environment 5205, a public switched telephone network (PSTN) 5220 is connected through the use of a customer PC 5210 modem 5215. Modem bank 5230 allocates a modem to answer an incoming call from PSTN 5220. Modem Bank 5230 consists of a set of high-speed modems, such as the U.S Robotics V.34 Kbps modem. Incoming call is confirmed by confirmation server 5235. The verification server 5235 can be run using the same server as the Radius / Keystone server running on Sun Sparcstation Model 20.

The bastion host 5110 is located within the firewall but is logically located outside of both ISN 5115 and gateway site 5205.

Following confirmation, the selected modem 5233 is connected to an incoming call router 5240 using a point-to-point protocol (PPP). PPP is a protocol that provides a standard way of transporting multi-protocol datagrams over a point-to-point link. The link is configured to provide full-duplex simultaneous bi-directional operation and deliver packets in order. PPP provides a general solution for easy connection of a wide variety of hosts, bridges, and routers. PPP is described in detail in RFC 1661: The Point-to-Point Protocol (PPP), W. Simpson, Ed. (1994) ("RFC 1661"). As such, the disclosure of the PPP is incorporated by reference.

Incoming call router 5240 selectively routes incoming requests to DMZ 5105's external packet filter 5130 via a communication link such as TI line 5250, which TI line 5250 receives an external packet filter through a channel service unit (not shown). Connected to 5130. Incoming call router 5240 can be implemented using, for example, a Cisco 7000 series multiprotocol router. Incoming call router 5240 is optionally connected to the Internet 5280. However, the Luther 5240 is configured to block calls from the Internet 5280 to the outer packet filter 5130 and to block calls from the outer packet filter 5130 to the Internet 5280 and thus do not allow access from the Internet 5280 to the DMZ.

Bastion host 5110 runs the File Transfer Protocol (FTP) server, which runs a modified FTP protocol based on the wu-ftpd FTP daemon, from Washington University. Except as described herein, the FTP protocol complies with RFC 765. File Transfer Protocol, by J. Postel (June 1980) ("RFC 765"), whereby the disclosure of the FTP protocol is specified by reference. RFC 765 describes a known protocol for file transfer using a telnet connection based on TCP / IP, wherein the server responds to a user-initiated command to send or receive a file or supply status information on the connection. The DMZ FTP implementation excludes send commands (used to send files from remote users to the FTP server) and any other FTP commands to transfer files to an FTP host. A limited subset of commands are supported, including the get (or recv) help, ls, and quit commands.

The get command is used to transfer files from host server 5110 to remote user 5210. The recv command is synonymous with get. The help command provides a concise online document to the commands supported by the host server 5110. The ls command provides a list of files in the server's current directory or directories specified by the user. The quit command terminates the FTP session. The cd command specifying the directory named as the current directory and the pwd command displaying the name of the current directory can optionally be executed.

Disallowing send or other commands to send files to the server prevents potential intruders from sending "Trojan horse" type computer programs that can be used to compromise system security. As an added benefit, one-way data flows prevent users from inadvertently deleting or overwriting files located on the bastion server.

When the FTP daemon initiates a user session, the FTP daemon uses the UNIX Chroot (2) service to describe the root of the user's directory tree in detail as the root of the file system that the user sees. This restricts users from viewing UNIX system directories such as / etc and / bin and other users' directories, but allows users to view and access files in their own directory tree as desired. To ensure a more secure environment, the FTP daemon runs at a user level user-id ("uid) rather than as root and allows access only to authorized users who communicate from a predetermined set of IP addresses known to be authorized. Standard, non-confirmed accounts of anonymous, and guest are possible suppressed.

For additional security on the Bastion server 5110, many daemons that are normally initiated by the UNIX Internet server process inetd are disabled. Disabled daemons are not required for Bastion server operations or are known to have security exposures. The daemon includes rcp, rlogin, rlogind, rsh, rshd, tftp and tftpd. The daemon is disabled by deleting or commenting its entry in the AIX / etc /inetd.conf file. The / etc /inted.conf file provides a list of servers called by inetd when receiving Internet requests over sockets. Deletion or commenting of the corresponding entry prevents the daemon from running in response to the received request.

For additional security, do not allow multiple daemons and installations to run by changing their associated file licenses to mark multiple daemons and installations as inoperable (for example with file mode 000). . This is accomplished by a DMZ Utility Disabler (DUD) routine that is executed at boot time. The DUD routines are represented by the above-mentioned files (rcp, rlogin, rlogin, rsh, rshd, tftp and tftpd) as well as a number of other daemons and facilities not normally invoked by inetd. The daemon and facility set includes sendmail, gated, routed, fingerd, rexecd, uncpd, bootpd and talkd. The DUD also makes it impossible for telnet and ftp clients to prevent an intruder from executing the client's access to the internal host in the event of a break-in. The telnet and ftp clients may be marked as temporarily executable during system maintenance activities.

Bastion host 5110 has IP forwarding disabled. This ensures that it cannot pass through the DMZ isolation subnet 5115 by using Bastion host 5110 as a router.

The limited level of ftp service provided by Bastion Server 5110 provides secure ftp sessions, but makes it difficult to perform typical system maintenance. To perform system maintenance, maintenance personnel must be connected to the bastion host 5110 from an internal host within ISN 5115 using a telnet client. Bastion's FTP client program then changes from being unable to run using the AIX chmod command (eg, 000) to being able to run (eg, 400). Maintenance personnel can then run an ftp client program that connects to the desired host on ISN 5115. Therefore, during the above procedure, transfer control is made from within Bastion host 5110 via an FTP client program running inside the host rather than from a client outside the host. At the end of the maintenance session, the FTP session is terminated and executed once again to return the ftp client program to a state where the chmod command cannot be executed (eg OOO), after which the ISN-initiated telnet session can be terminated. .

To provide logging, the Bastion server 5110 executes TCP daemon wrappers, such as the TCP wrappers from Wieste Venema. The TCP wapper tells inetd to run a wrapper program smaller than the named daemon. The wrapper program logs the client host name and address, performs some additional checking, and then executes the desired server program for inetd. After the end of the server program, the wrapper is deleted from the memory. The wrapper program does not interact with the client user or client process and with the server application. This provides two main advantages. First, the wrapper is application-independent, so the same program protects many kinds of network services. Secondly, the lack of interaction is not visible from outside the wrapper.

The wrapper program runs only when the initial contact between the client and server is established. Therefore, after the wrapper executes its logging function, there is no additional overhead in the client-server session. The wrapper program sends their logging information to the syslog daemon, syslogd. The array of wrapper logs is a syslog configuration batch file, typically / etc / syslog. determined by conf.

Dial-in access is provided through the dial-in environment 5105. The use of verification server 5235 provides for user verification to prevent access from users who are not authorized to access the DMZ. The implemented verification scheme uses a one-time password design. All internal system and network elements are protected using a one-time password generator token card, such as a SecurID security identification token card produced by Security Dynamics using an internally developed verification client / server mechanism called keyston. The keystone client is installed on each element that receives a confirmation request from the user. The request is then securely submitted to a keystone server deployed throughout the network.

Each user is assigned a credit card size security identification card with a liquid crystal display in front. The display displays a pseudo-randomly sequenced six-digit number that changes every 60 seconds. In order for an employee to gain access to the keystone protection system, the user must enter their personally assigned PIN number prior to the number currently displayed on the security identification card. Such confirmation prevents unauthorized access employing "sniff" or the use of Trojan horse programs designed to capture passwords from users or programs that attempt to intercept passwords.

Confirmation information collected by the Keystone client is encrypted between the RSA and DES encryption keys and sent to one of a number of Keystone servers. The Keystone server then evaluates the information to verify the user's PIN and access code that should be displayed on the user's card at that time. After the system verifies both factors for the correctly entered user, the authorized user is provided access to the system or the requested resource.

To ensure security from entry points in the external network, no external gateway device has a general access account and all provide controlled access. Each gateway device ensures that all gateway services generate logging information, and each gateway device maintains an audit trail of connections to the gateway. All external gateway devices have both disconnected non-essential services.

The acknowledgment server 5235 is programmed to serve as a front end to all remote access dialups and to disallow pass-through. All network verification mechanisms prepare for the logging of failed access attempts. Preferably, the log generated is reviewed daily by a selected person.

53 depicts a flowchart showing a fax tone detection methodology. In step 5305 the Paxton detection system assigns a null linked-list; That is, a linked list with no entries. In step 5310 the paxton detection system starts the asynchronous routine auCheckForFaxAsync 5315. The auCheckForFaxAsync routine 5315 is an asynchronous program that is executed concurrently with the main line program, rather than returning control to the calling program synchronously. The auCheckForFax routine evaluates the tone of the incoming call to see if the call was sent by the facsimile device and generates an auCheckForFax response 5318 when and when the facsimile tone is detected.

After starting the auCheckForFaxAsync routine 5315, control proceeds to step 5320. In step 5320 the paxton detection system adds an entry to the linked list assigned in step 5305. The added entry represents a unique identifier associated with the message being processed. In step 5330, the Paxton Detection System starts the asynchronous routine auPlayFileAsync 5335. The auPlayFileAsync routine 5335 is an asynchronous program that is executed simultaneously with the main line program, rather than returning control to the calling program synchronously. The auPlayFileAsync routine 5335 accesses a prestored and digitally recorded sound file and operates the file to the calling caller. The sound file activated can be used to instruct the calling caller as to the sequence of key presses that can be used to execute a particular function, for example to record a message, for example to retrieve a list of previously recorded messages and the like.

In step 5340 the paxton detection system starts the asynchronous routine auInputDataAsync 5340. The auInputDataAsync routine 5340 is an asynchronous program that runs concurrently with the main line program rather than returning control to the calling program synchronously. The auInputDataAsync routine 5340 monitors outgoing calls to detect key presses by the user, which is intended to invoke routines that perform tasks associated with a particular key press sequence.

As described, the auCheckForFaxAsync routine 5315 is executed concurrently with the main program, generating auCheckForFax response 5318 when and when a facsimile is detected. In step 5350 the Paxton Detection System checks to see if an auCheckForFax response 5318 response has been received. If a response is received, this indicates that the outgoing call is a facsimile transmission and the facsimile detection system extends the incoming call to voice / fax processor (VFP) 5380. If no auCheckForFax response 5318 is received within a predetermined time (eg 7 seconds), the facsimile detection system concludes that the caller of the call is not a facsimile device and terminates the auCheckForFaxAsync routine 5315. In some implementations, it may be desirable to run the inspection through an asynchronous interruption processing process. In such an implementation, a run-time routine may be set to obtain control when an auCheckForFax response 5318 event occurs. The run-time routine may be executed using, for example, a C ⁺⁺ catch structure that defines an exception handler to handle the auCheckForFax response 5318 event.

Following the determination of step 5350, the paxton detection system in step 5360 waits for a subsequent incoming call.

54A through 54E depict flow diagrams illustrating a VFP completion process for fax and voice mailboxes. As depicted in Figure 54A, the VFP Completion routine at step 5401 retrieves the database for the record corresponding to the addressed mailbox. In step 5405 the VFP completion routine searches to see whether the mailbox record was successfully retrieved. If no mailbox record is found, then at step 5407 the VFP completion routine generates a VCS alert indicating that the desired mailbox record was not found. The VFP completion processor will not be able to test the attributes of the mailbox address because no mailbox record was found. However, control proceeds to step 5409 regardless of whether a mailbox record has been found. In step 5409, the VFP completion processor examines the contents of the mailbox record, if present, to determine whether the addressed mailbox is full. If the addressed mailbox is full, at step 5410 the VFP completion routine displays an error message indicating that the addressed mailbox is full and no further messages can be stored and step 5412 is reached.

In step 5414 the VFP completion processor obtains the mode of the VFP call. The mode is derived from the dial string supplied by the calling caller and stored in the enCurrentNum field of the pstCallState structure. The dial string has the following format:

{

char number [10]; / * 10-digit 8xx number by user * /

char asterik; / * constant '*' * /

char mode; / * 1-byte mode * /

char octothorp; / * constant '#' * /

}

The mode has the following values:

1 guest voicemail

Guest Fax with 2 Voice Annotations

Guest fax without 3 voice commentary

4 User Voice / Fax Search

5 Maintain user list

6 User record in mail box

In step 5416, the VFP completion processor retrieves a route number associated with the routed mailbox from the database. In step 5418, the route number is transmitted to the SIS layer.

As depicted in FIG. 5413, continued with step 5420. In step 5420, the VFP completion processor initializes a response supervision flag used to determine whether the VFP allows call transmission. In step 5422, the VFP completion processor calls SisCollectCall to process the call. If the call is successful, step 5424 causes the SisCollectCall invocation of step 5422 to be repeated up to a predetermined number of retries.

In step 5426 the VFP completion processor obtains a predetermined timer expiration value from the otto.cfg file. The timer expiration value is set to an amount of time, and if no response is received during the time, the VFP completion processor may conclude that the VFP is currently unreachable.

In step 5428 the VFP completion processor sets a timer according to the value from step 5426. In step 543O the VFP completion processor checks to see if a response supervision occurred prior to the expiration of the timer set in step 5424. If so, then control proceeds to step 5430 to transfer control to the VFP. 54C depicts an operation for transferring control to the VFP in response to an assertive decision in step 5430. In step 5440 any pending timers set in step 5428 are canceled. In step 5442 the VFP completion processor calls the routine sisOnHoldTerm () to put the VFP on hold. In step 5444, the routine sisOffHoldOring () is called to release the VFP complete processor outgoing call.

In step 5446 the VFP completion processor activates the prestored and digitally recorded sound file, which instructs the calling caller to wait during the process of transmitting to the VFP. In step 5448, the VFP completion processor calls the routine sisOnHoldOring () to put the outgoing call on hold again. In step 5450, the VFP completion processor calls the routine sisOffHoldTerm to take the VFP out of hold. In step 5452 the VFP completion processor calls the auPlayDigits routine, which is the mailbox number addressed as a parameter. A string consisting of asterisk ('*') indicating field separation, octothorp ('#') indicating mode and end of command line is passed to the VFP completion processor.

In step 5454, timeout values Ack Timeout and interdigit delay values are obtained from the VFP completion processor otto.cfg file. The Ack timeout value is used to determine the amount of time before the VFP completion processor determines that no response will come soon from the VFP. The interdigit delay value is used to measure the time between transmitted voice signals representing the telephone keypad press. In step 5456 the VFP completion processor calls the InputData routine to get a response from the VFP.

Subsequent to steps 5440-5456 or following the negative determination in step 5430, control proceeds to step 5460 as shown in FIG. 54D. In step 5460, the VFP completion processor requests a response from the VFP. In step 5462, the VFP completion processor waits for a timer or VFP response set in step 5428 that has expired. If the VFP responds in step 5464, the VFP completion processor proceeds to step 5446.

Step 5446 examines the VFP complete system VFP response and creates an appropriate BDR term status record. The response indicates an acknowledgment from the TI platform. A response of '00' indicates success, and the VFP completion processor writes a BDR_STAT_NORMAL indicator. A '01' response indicates that the VFP did not receive a key for the addressed mail box, and the VFP completion processor writes a BDR_STAT_DLINE_TI_NO_DIGITS indicator. A '02' response indicates that the VFP was terminated while collecting the key, and the VFP completion processor writes a BDR_STAT_DLINE_TI_FORMAT indicator. A response of '03' indicates that the addressed mailbox is not found, and the VFP completion processor writes a BDR_STAT_DLINE_TI_MAILBOX indicator. If no response is received, the BDR_STAT_DLINE_TI_NO_RSP indicator is written. Following the BDR labeling, control proceeds to step 5480 as shown in FIG. 54E.

If no response is received from the VFP, the timer set in step 5428 expires and control passes to step 5468. In step 5468 the VFP completion processor issues a VCS alert indicating that the VFP did not respond. In step 5470, the VFP completion processor calls the routine sisReleaseTerm () to disconnect the call to the VFP. In step 5472 the VCS completion processor calls the routine sisOffHoldOrig to take the outgoing call out of hold. In step 5474, the VFP completion processor calls tiCancel Timers to cancel all outstanding timers that have not yet been cancelled. In step 5476 the VFP completion processor operates a pre-stored and digitally recorded sound file, which reports to the calling caller that the VFP completion processor could not access the VFP.

After either step 5476 or step 5466 (depending on the determination of step 5464), control proceeds to step 5480 as shown in FIG. 54E. In step 5480, the VFP completion processor checks to see if the calling caller is a subscribed user. If you are a subscribed user, control passes to step 5482. In step 5484 the VFP completion processor checks to see if the originating caller is a guest user. If it is a guest user, control passes to step 5482. Then at step 5482, the caller returns the calling caller to the menu from which the caller initiates the VFP request. If the calling caller is neither a subscribed user nor a guest, control passes to step 5486. In step 5486 it is assumed that the originating caller is a fax call, and then the call is disconnected.

55A and 55B depict the operation of the pager termination processor. In step 5510 the pager termination processor calls the GetCallback routine to obtain a telephone number that can be used to identify the caller and can be displayed on the paging device to identify the number being called back by the pager subscriber. The GetCallback routine is described in detail below with respect to FIG.

In step 5515 the pager termination processor checks to see if the phone number is returned by GetCallback. If no number is returned, in step 5520 the pager termination processor indicates that the call should be terminated and in step 5522 a menu is provided to the caller to select another service. If the number is not returned, the addressed pager PIN is obtained from the database in step 5530. The pager termination processor constructs a pager dial string consisting of the pager PIN retrieved in step 5530 and the callback number obtained in step 5510. In step 5532 the pager termination processor obtains the type of pager and routing information is obtained from the database. In step 5534, the pager termination processor examines the configuration batch file to obtain a pager parse string defining parameters in addition to the pager of the addressed type. In step 5536 the pager termination processor checks to see if the requested pager parse string was successfully retrieved. If not successful, the pager termination processor at step 5538 indicates that it cannot be executed by setting the BDR term status to BDR-STAT-PAGER-NOT-FOUND, and at step 5540 the caller selects another service. To give the menu.

If the pager parse string is successfully retrieved, the pager termination processor proceeds to step 5550 as shown in FIG. 55B. In step 5550 the pager termination processor calls a pager subsystem, which passes the route number, dial string and pager parsing string to the pager termination processor. In step 552 the pager exit processor checks the return code from the pager subsystem. If the page is successfully completed, in step 5554 the pager termination processor informs the caller of a digitally pre-recorded message, which informs the caller that the page was successfully sent. In step 5556, the enEndCallStatus field is updated to indicate completion of the pager call. In step 558 the transmission status is displayed as blank, indicating that there is no need to send the caller, and in step 5560 the pager termination processor provides a menu to allow the user to select another service or to terminate the call.

If the page did not complete successfully, the pager exit processor checks at step 5570 whether the caller was disconnected during the page attempt. If the caller is disconnected, in step 5575 the pager termination processor checks to see if the page was sent in preference to the disconnection. If the page was sent in spite of a break, the pager termination processor in step 5580 indicates a normal end to the page request in step 5580 and sets the status to completed in step 5582. In step 5584, the pager termination processor provides the user with a menu to allow selection of another service or termination of the call.

If the page has not been sent to the pager terminating processor, the pager terminating processor indicates at step 5586 that the page request has ended abnormally and indicates at step 5888 that the caller has disconnected. In step 5590, the pager incoming processor provides a menu to the user so that the user can select another service or terminate the call.

If the caller is disconnected, at step 5574 the pager incoming processor sets a code indicating the cause of the failure. The failure types are BDR_STRT_PAGER_ROUTE_NUM (for invalid route numbers), BDR_STAT_PAGER_CRIT_ERROR (for failures in outgoing calls), BDR_STAT_PAGER_TIMEOUT (for failure of pagers to acknowledge calls at predetermined timeout intervals), and BDR_STAT_PAGEHOLD_DIG (For failure of the pager subsystem to broadcast a digit corresponding to the pager address), and BDR_STST_PAGER_DISC (for early truncation of the paging system) and BDR_STAT_PAGER_NOT_FOUND (for a parse string).

In step 5152, the pager terminating processor notifies the BDR of the error code selected in step 5574. In step 5552, the pager incoming processor broadcasts a pre-recorded digital sound file indicating that the page cannot be sent, and in step 5595 the End Call Status field is updated to indicate pager call completion. In addition, at step 5597, the transmission status is indicated by a blank, indicating that the page does not need to be sent to the caller, and in step 5599, the pager destination processor provides a menu to the user so that the user selects another service or Allow the call to end.

56 shows a GetCallback routine called in step 5510 from the pager destination processor. In step 5610 the callback read routine obtains constants from the otto.cfg file that define the appropriate start and inter-digit delays. In addition, at step 5615, the callback read routine broadcasts a pre-recorded digital sound file to the caller, prompting the caller to enter a callback telephone number by pressing the appropriate keypad keys and then pressing the "#". do. In step 5620, the callback read routine reads the telephone number entered by the caller, and the received data is located in the BDR in step 5625. In step 5630, the callback read routine checks whether the entered telephone number is terminated by a character "#". At this time, if the telephone number input is completed, the callback read routine returns success at step 5535. If the telephone number input is not finished, the callback read routine checks whether the retry count has been exceeded at step 5640. . If the retry count has not been exceeded, execution is repeated from step 5615. If the retry count has been exceeded, the callback read routine at step 5650 indicates that the telephone number was not successfully received. The message is broadcast, and at step 5660 an error condition for the calling program is returned. The following is a user interface for user management of direct line (MCI) profile items accessed via ARU (DTMF) and customer service.

(Deactivate) Active Account

Find-Me Routing

Schedules

3-Number Sequence

First, Second and Third Numbers and Ring-No-Answer Timeouts

Pager On / Off

Override Routing

Final (Alternate) Routing

Caller Screening

Pager Notification of Voicemail Messages

Pager Notification of Faxmail Messages

Speed Dial Numbers

The following table is a list of fields that can be updated by a directline (MCI) customer via DTMF, and the list does not contain all the fields it serves, only the fields used by the dedicated line (MCI) application. do.

The user will access his leased line (MCI) via http: /www.mci.services.com/directline. Entering a valid Account ID and Passcode will provide the user's routing screen. The user can click Tab to move from one screen to another. If the user returns to the updated screen during the session, the screen will be displayed as when he last left, ie when any updates he provided are reflected in the data. If the user then terminates (logs off) or times out system use when launching his profile management screen, the displayed data will be from a new query to the 800PIN 1Call database. Updates made in the last 15 minutes may not have reached the NIDS databases supporting the web server, so the data may not reflect any recent updates.

The following items appear in the index frame and serve as links to related web servers. When the user clicks on one of the items, the relevant screen will be displayed in the text frame.

Call Routing

Guest Menu

Override Routing

Speed Dial Numbers

Voicemail

Faxmail

Call Screening

In addition, the LOGOFF button appears at the bottom of the index frame, and when the user clicks the button, the token (frame) ends immediately, and the user will return to the login screen.

F. Login Screen

57 shows a user login screen 700 for access to online profile management.

Dedicated Line (MCI) Number (702)

The account ID will be the 10-digit access number of the dedicated line (MCI) customer, that is, the format 8xx xxx xxxx. This number, chained to a PIN of "000", will be an accesskey of the 1Call database containing customer profile data. If the program flag (PIN flag 4) is set to "N", the user will not be able to log in successfully, and if the login attempt is made on the account, the Login Error screen will be displayed.

Passcode (704)

The passcode is the same as that used to access user options via the ARU interface and is a six-character string. No user input will appear in this field, and each character entered will be displayed as an asterisk ("*").

Status message

directline (MCI) Number: "Enter your private line (MCI) number."

Passcode: "Please enter your passcode"

G. Call Routing Screen

58 shows a co-routing screen 710 used to set or change a co-routing command of a user.

"Accept Calls" Area (712)

The user can select the appropriate radio button 174 or 716 to specify whether a call has been received in the area 712 on his account, which is the account available flag (in the customer's leased line record). Corresponding to the status flag, bit 3).

"Choose From Below" Area (718)

The user sets whether the guest caller should receive a guest menu or override routing process. This selection indicates whether the data in the guest menu or override routing screen is appropriate. The override call from the customer will appear as follows according to the user's choice.

"When I Can't Get It" Area 720

The user specifies the call handling of calls that he could not receive, and the alternate call in the customer record is updated as follows.

Status message

Depending on the user's choice, the following status messages are provided to the user for confirmation of each choice.

Do not Accept Calls: "Calls will not be received on your private line (MCI) number.

Accepts Calls: "Calls will be received on your private line (MCI) number."

Guest Menu: Let the caller choose how they want to contact you. "

No Menu-Override Routing: "Route the caller to a specific place of your choice"

Voicemail: "The caller will be asked to leave a voicemail."

Pager: "The caller will be urged to leave you a page."

Voicemail or Pager: "The caller can choose to leave you a voicemail or send you a page."

Closing Message: "The caller will be prompted to call again later."

H. Guest Menu Configuration Screen

When override routing is disabled, that is, when a guest menu is selected, the guest menu is provided to the guest caller. The user can configure his or her guest menu using the guest menu configuration screen 730 (FIG. 59) with the following contents.

"Find-Me Root" checkbox (732)

At this stage, find-me-rooting cannot be released. The checkbox will be checked based on the Find-Me flag (9-bit PIN flag and faded option). If the subscriber enters "leading 1" for the domestic phone number, the reading 1 is separated from the phone number and only NPA-Nxx-xxxx will be stored in the database. When programming its own three digit sequence numbers, the subscriber can select the number of rings from 1 to 6 that the system must allow before a ring-no-answer decision is made. The number of rings is stored in the database in seconds, and the formula for calculating the seconds will be 6 * Ring_Limit. If no value is entered, the default (default setting) is 3 rings or 18 seconds. When reading from the database, 0 to 8 seconds will translate to 1 ring. Seconds above 8 and up to 16 will be divided by 6 and divided into rounded results to determine the number of rings.

Updates to your records are as follows:

** Domestic / international terminals will be identified as described in Appendix A.

"Leave a Voicemail" check box (734)

At this stage, voicemail cannot be deleted and the checkbox will be checked based on the Vmail flag (3-bit PIN flag) and the "grayed out" option.

"Send a Fax" check box (736)

At this stage the fax cannot be deleted and the checkbox will be checked based on the fax terminal flag (13-bit PIN flag) and faded options.

"Send a Page" check box (738)

The user can toggle the box labeled Send me a page to specify whether the caller will be offered a paging option. The box corresponds directly to the pager on / off flag (13-bit status flag) in the customer's dedicated line record.

Status message

Find Me Routing: "Let the caller 'find you' wherever you are."

Schedule Routing: "Route the caller according to your schedule."

Three Number: "The caller can find you through three numbers."

1 ^st #, 2 ^nd #, 3 ^rd #: "Please enter your phone number."

1 ^st , 2 ^nd , 3 ^rd Ring Limit: "Enter the number of times you want to call this number."

Leave a Voicemail: The caller can leave you a voicemail. "

Send a Fax: "The caller can send you a fax."

Send a Page: "The caller can leave you a page."

I. Override Routing Screen

60 is an override routing screen 740 that allows the user to route all calls to the selected destination. When the user votes on the display of the guest menu 730 of Figure 59 and chooses to route all his calls to a specific destination, the override terminal in the customer record will be updated as follows.

When this option is initially selected from the profile screen, there will be no override routing setting in the user's customer record. When this screen is provided, the default setting will be voicemail if it is available, and it will be Find-Me if it is not available.

Status message

Find Me Routing: "Let the caller find you wherever you are."

Schedule Routing: "Route the caller according to your schedule."

Three Number: "The caller can find you through three numbers."

1 ^st #, 2 ^nd #, 3 ^rd #: "Please enter your phone number."

1 ^st , 2 ^nd , 3 ^rd Ring Limit: "Enter the number of calls for that number."

Voicemail: The caller will be prompted to just leave you a voicemail. "

Send a Page: The caller will be prompted to just leave you a page. "

Temporary Override Number: "The caller will just be routed to the number you choose."

Telephone Number Ring Limit: "Enter the number of calls for that number."

J. Speed Dial Screen

Speed dial number screen 744 is shown in FIG. The user can update the nine speed dial numbers via the web interface. Speed dial numbers 1 through 9 on the web page correspond to the same speed dial numbers on the subscriber's record. Domestic and international incoming will be identified as described below.

Status message

1-9: "Enter the speed dial number <1-9>"

62 shows a mailmail screen 750.

"Receive Voicemail Message" check box (752)

"Page me when I receive" checkbox

The "Please page me when I receive a new voicemail message" check box 754 corresponds directly to the Page on Vmail flag in the customer's private line record.

Status message

Receive fax: "Callers will be able to leave you voicemail."

Page me each time: "You will be paged when you receive a voicemail message."

63 shows a faxmail screen 760.

"My primary Fax number is" field (762)

"Receive Faxmail Messages" checkbox (764)

Profile management of this item appears as shown on the Fax Mail screen.

"Page me when I receive" checkbox (766)

This item is "Please page me when I receive a new voicemail message." It appears like checkbox 766. This box corresponds to the Page on Fax flag in the customer's line chart.

Status message

Receive Fax ...: "The callers will be able to send you a fax."

Page me each time ...: "You will be paged to you when you receive a fax."

64 shows a call screening screen 770. The user can select a screen of calls using either the caller name, the calling number or the caller's name and number, and the call screening status is updated in the customer's record as follows.

Status message

Allow me to screen ...: "If this feature is enabled you can screen your call."

Name only: "The caller's name will be provided to the called party."

Telephone number: "The caller's phone number will be provided to the called party."

Name and Telephone: "The caller's name and telephone number will be provided to the called party."

Figures 65-67 show supplemental screens 780, 782, and 784 for use with user profile management.

Login Error Screen (780)

This error screen is provided when a login attempt fails due to an invalid account number, passcode or invalid IP address, and is also displayed when the user's token is terminated and the user requests to log in again.

Update Success Screen (782)

This screen is provided when the update has been completed successfully. "Blank" means "have the routing options ...", "have the guest menu options ...", "have override routing ...", "have speed dial numbers ...", It's populated with 'have voicemail options ...', 'have faxmail options ...' and 'call screening options ...'.

Update Failed Screen (784)

This screen appears when a user enters one or more invalid called number (s) or renews his account with a blank first number, until the account is corrected or all numbers are successfully verified. Will not be updated.

Among the various screens of the user interface, profile options are "grayed out", indicating that the option is not available from the screen based on the following flag setting.

For some of the profile options described above, the verification check is performed as follows.

International numbers, except North American Dialing Plan (NADP) numbers, must begin with "011" or will not be received for programming.

976 Blocking will be implemented as follows.

The international blocking database is queried when using category NPA, type 002, and programmed NPA to find pattern matches, to ensure that the programmed number is not a blocked Information / Adult Services number. Will be. If a match is found, programming for that number will not be allowed.

Country Set blocking will be implemented as follows.

The country setting of the dedicated line (MCI) characteristic record will be checked against the country code of the programmed number. If the called country is blocked in the MCI country setting, programming for that number will not be allowed.

Programming Routing

Programming Speed Dial Numbers

FIG. 68 is a flowchart illustrating how a speed dial number input by a user is confirmed, and the same flowchart may be applied when a non-subscriber confirms an input by a guest on a guest screen when calling a user.

The inventors' integrated switching system and packet transmission network provide improved additional functions for users. A dedicated line (MCI) is a personal number of single number access with additional services including Find-Me function, voicemail, paging, fax storage and incoming service. The subscriber or user is required to have profile information entered into the customer record in the dedicated line (MCI) database on the ISN mainframe. Additional features of the product are as follows.

Personal Greeting: The user has the option to record a personal greeting to be played to his guest caller. When the user records a personal greeting, the default greeting "Welcome to leased line (MCI)" is replaced by the recorded greeting.

Guest Menu: The Guest Menu is defined by which add-ons the user has reserved. You will be given the option to call the caller, page the user, send a fax, or leave a voicemail message for a "fully loaded" account. 3-digit sequence for the Find-Me function: The system tries to reach the user by testing three numbers, namely the first number, the second number, and the third number. If no response is received at any of these numbers, the call is treated as specified in the alternate route.

Two-Level Schedule for the Find-Me Function: The system attempts to reach the user with two numbers using the current day / date / time information to query the user's schedule. The attempt is made several times in order from user's schedule 1 to schedule 2. If no response is received, alternate routing defines the handling.

Alternate routing allows the user to specify the handling of the guest caller who was trying to reach him, but is received at any of the numbers for which no response was attempted. Options for alternate routing include voicemail, pager, a voicemail or pager of the guest's choice, or termination messages that prompt the caller to call back later.

Override routing allows the user to disable the provision of a guest menu and prescribes a single treatment for all guest callers. Options include termination for phone number, user-defined find-me-sequence, voicemail or pager.

Default Routing is the handling of guest callers that do not respond after three attempts when the guest menu is provided. Default routing options include switching to the operator, terminating on the phone number, find me sequence or voicemail.

Call Screening allows the user to define whether the user wants to be notified before the call is made. Options do not include call screening, or have a caller, outgoing telephone number, or both name and number, identified by name.

The "Place a Call" option in the user's menu allows the user to make a call and charges to a dedicated line (MCI) account.

Voice / Faxmail: Voice and fax messages can be stored for later retrieval by the user, and the user can choose to be notified when new voice and / or fax messages are piled up in his mailbox.

Voice / Fax Platform (VFP) integrated into Intelligent Service Network (ISN) allows ISN applications to query their database and allow billing records to be excluded directly from the VFP. Among the changes to the initial leased line (MCI) product are the following:

Find-Me Rooting

Find-me-rooting goes through two options the subscriber can choose: three-digit sequence or two-level schedule options currently implemented. The schedule option is implemented such that the Schedule 1 translation of the subscriber is treated as the first incoming, and the Schedule 2 translation of the subscriber is treated as the second incoming. Find-me-Routing is described in more detail in the Call Flow diagram and the ARU Impact section.

Default routing

Default routing is a precautionary measure that an application has when the caller does not respond to a prompt from the guest menu. Options for default routing include phone number, voicemail, find-me-root and operator switching.

Voice / Fax Message Information

When the subscriber accesses the user menu and the mailbox is full, the application provides mailbox status information indicating the number of new voice or fax messages. The application sends a query to the VFP database to obtain this information.

Speed dial

The subscriber can now call the programmed speed dial number as well as the telephone number entered in real time. These nine speed dial numbers can be programmed by the user via DTMF.

K. ARU-Call Flow

69A-69I illustrate a software implementation of the above-described leased line (MCI) product, and a call flow diagram of an auto answering unit (ARU) to aid a better understanding of the invention.

269A shows a starting point for processing an ARU call. When a call is initiated, that call is considered a guest call. If the account to which the call is to be reached is not currently online, at step 69010 the ARU broadcasts a message indicating that the call cannot be accepted at the account and then blocks at step 69012. If the ARU detects a fax tone in the incoming call, then at step 69814, the ARU performs the ARU Xfer to Voice / Fax Geust Fax routine without performing an annotation routine. If no paxton is detected, the ARU performs an ARU Play Greeting routine, which will be described in FIG. 69L, at step 6690. The ARU then checks if the subscriber has specified an override for the incoming calls and, if so, performs an ARU Find Me routine specifying a parameter of "override" at step 69020. At this time, the ARU find fine routine is described later in Figs. 69E to 69F. If no override is specified, the ARU performs the ARU guest menu routine described in FIG. 69D at step 69822.

69B shows an ARU greeting broadcast routine. If a customer greeting is recorded, the ARU broadcasts the customer greeting at step 69030, and if not, the ARU plays a pre-recorded general greeting at step 69032.

69C shows an ARU Play Temp Greeting routine. If a temporary greeting is recorded, the ARU broadcasts a temporary greeting at step 69034, and if a customer greeting is recorded at step 69036. Otherwise, the ARU broadcasts a pre-recorded general greeting at step 69038.

69D shows an ARU Guest Menu routine. At step 69040, the ARU provides the caller with an audible menu. As an example, item "1" corresponds to a call request to a subscriber and item "2" corresponds to a request to leave a voicemail message for the subscriber. And item "3" corresponds to the request to send the fax to the subscriber, and item "4" corresponds to the request to send the page to the subscriber. In addition, the subscriber may enter his or the caller's passcode to access the ARU.

If the caller requests a call with the subscriber, the ARU checks schedule flags associated with the caller's profile. If the check indicates that the subscriber's profile indicates scheduled routing, then the ARU performs the fine me routines of FIGS. 69E-69F using "Sched1" as a parameter at step 69042. If the user's profile does not indicate scheduled routing, then the ARU performs ARU Find Me routing using "First" as a parameter at step 69044. The ARU fine mirroring will be described in detail in FIGS. 69E and 69F.

If the caller requests to leave a voice mail message, the ARU checks whether the subscriber's mailbox is full. If the mailbox is full, the recorded message is broadcast and the caller returns to the guest menu. However, if the mailbox is not full, an announcement is broadcast to the caller to wait while switching to the ARU voicemail routine at step 69046.

If the caller requests a fax transmission, the ARU checks if the subscriber's mailbox is full. If the checksum indicates that the mailbox is full, the recorded message will be broadcast and the caller will return to the guest menu. If the mailbox is not full, an announcement is broadcast to the caller to wait while switching to the voice / fax routine at step 69048. If the caller requires the subscriber to send a page, at step 69050, the ARU performs the ARU Send Page routine described in FIG. 69M. In addition, if the caller enters a valid passcode, the ARU performs an ARU User Call routine described in FIG. 69P at step 69052.

69E and 69F illustrate the operation of the ARU Find Me routine. As shown in step 69060, the ARU Find Me routine is set by the caller and uses a single parameter (Term_Slot) that is used when the ARU performs the ARU Find Me routine to select one of the alternatives. do. If Term_Slot is set to "Find Me", this indicates that the ARU intends to use the default method of determining the subscriber's current number. This value can be set, for example, for override or default processing. If the subscriber's profile contains schedule flags, the ARU performs an ARU Find Me routine using the parameter ("Sched1") as shown in step 69062, and if the subscriber's profile does not contain schedule flags. As shown in step 69061, an ARU find me routine is performed using the first telephone number in the subscriber's telephone number list.

If Term_Slot is set to "voice mail", the ARU sends a message to the caller indicating that the subscriber has requested to leave a voice mail message. If the subscriber's mailbox is not full, at step 69064, the ARU performs the ARU Xfer to Voice / Fax Geust Voice routine shown in FIG. 69K. If the routine fails, the routine returns, in which case the ARU broadcasts a message to the caller to call again later and then disconnects from the caller. On the other hand, if the subscriber's mailbox is full, the ARU sends a message to call back later because the mailbox is full and blocks the caller.

If Term_Slot is set to "pager", the ARU sends a message to the caller indicating that the subscriber has requested to leave a page, and then performs the ARU Page Send routine described in FIG. 69M. If routine execution fails, the routine returns, in which case the ARU broadcasts a message to the caller to call again later and then disconnects from the caller.

If Term_Slot is set to any POTS ("Plain Old Telephone Service") value (such as Sched 1, Sched 2, 1st, 2nd, 3rd), the POTS value is the incoming call using the standard telephone system. The ARU will use the planned Particular and the selected phone number, indicating that the subscriber is to be sent .. In step 69070, the ARU uses the ARU Name Recording Routine (ARU) to obtain a digitally recorded caller ID. ARU name recording routine is described in detail in Fig. 69H, where the ARU sends an appropriate message to the caller (eg, "Wait for access to you" on the first attempt, on the next attempt). "You are still connected to your side, please wait."

In step 69071 the ARU waits for the caller and calls the selected phone number. If the call is answered by an individual, the ARU performs the ARU Connect Call reutine shown in FIG. 69I. If on a call, in step 69074, the ARU performs the ARU Alternate Routing reutine of FIG. 69N. If the ARU detects the responding device, upon detection of the responding device, the ARU checks if the user has requested a subsequent alternate number. If not requested, the ARU connects the call, if requested, selects the next number in the calling order, and re-executes the ARU Find Me routine using the newly selected number.

However, if there is no live answer, busy signal, answering device answer, and Term_Slot is set to "Operator", then the ARU described in FIG. 69M is an ARU to switch the call to the operator. Run the Guest Xfer to MOTC routine. If not, the ARU chooses the next phone number, if any, and re-runs the ARU Find Miroutine with the new number. If there are no more numbers to check, at step 69084, the ARU performs the ARU alternate routing routine of FIG. 69N.

69G shows an ARU Record Name routine. This routine is used to record the caller's name if the subscriber specifies call screening by name or name and ANI. If the subscriber specifies call screening, the ARU checks if the caller's name was recorded in the previous pass. If the caller's name is not recorded at this time, the ARU prompts the caller to provide a name and records an audible response from the caller at step 69090. However, if the subscriber does not specify a form of call screening, the ARU name recording routine returns without recording the caller's name.

69H shows ARU Guest Xfer to MOTC routine. This routine broadcasts a pre-recorded message for the caller to wait and then diverts the call to the operator at step 69092. 69I shows an ARU call access routine. If the operator needs help to call, the ARU performs the ARU Xfer to MOTC routine of FIG. 83H. If the subscriber has not requested call screening, the call is connected to the subscriber, and if the subscriber has selected call screening, the ARU broadcasts a series of information messages to the caller.

The ARU sends a "call has arrived" and then sends a caller confirmation message depending on whether the option selected by the subscriber and the name of the caller were recorded. If no name is recorded, the confirmation message 69106 provides only the ANI where it was called. If the name has been recorded, the confirmation message includes the name as in step 69107 if the subscriber has requested screening by name, or if the subscriber has selected screening by name and ANI, as in step 69108. Includes all of them. After exporting the confirmation information to the subscriber, the ARU performs the ARU Gain Acceptance routine shown in FIG. 69J at step 69110.

69J shows the ARU gain acceptance routine invoked at step 69110. The ARU checks if the subscriber has a full mailbox available. If you have an available mailbox, the ARU will prompt you to indicate whether you will be called or received by voicemail. If the mailbox is full or unavailable, the ARU will call you. Prompts the subscriber to call the caller again later. At this time, if the subscriber indicates that it will receive the call (for example, by pressing "1"), the ARU connects the call at step 69124, otherwise the ARU Acknowledges the rejection with an appropriate information message (eg, depending on the conditions of the mailbox determined in step 69120, "the caller will be asked to leave a voice mail message" or "request the caller to call back later). Will be"). The ARU then blocks the subscriber and releases the caller's hold. The ARU sends a recording to the caller indicating that the subscriber is unreachable and urging the caller to leave a voice mail message. If the mailbox is not available, the connection with the caller is blocked, and if the mailbox is available, then at step 69128 the ARU performs the ARU Xfer to Voice / Fax Guest Voice routine of FIG. 69K. Following this routine, the ARU sends a message to the caller requesting that it be called again later and disconnects.

69K shows an ARU Xfer to Voice / Fax Guest Voice routine that connects a caller to the VFP to leave a voicemail message. The ARU attempts to shake hands with the VFP, and connects the call at step 69130 if the handshake is successful. If the handshake fails, the ARU broadcasts an error message at step 69132 and exits this routine. 69L illustrates an ARU Xfer to Voice / Fax Guest Fax w / or w / out Annotation routine that connects the caller to the VFP to send a fax. The ARU attempts to shake hands with the VFP, and if the handshake is successful, the ARU connects the call at step 69140. If the handshake fails, the ARU broadcasts an error message at step 69142 and exits the routine. Comes out. The routines of Figs. 68K and 69L are identical except for the contents of an error message to be broadcast to the caller and the request service of the VFP.

69M shows an ARU Send Page routine to initiate a call to a subscriber's paging service. In step 69150, the ARU prompts the caller to enter a phone number to be provided to the designated pager. This attempt is repeated three times until the callback number is received. If no callback number is received after three attempts, the ARU executes the ARU Guest Xfer to MOTC routine, which transfers the caller to the operator. This allows callers who do not have DTMF-enabled equipment to enter callbacks to provide the number to an operator who can enter the number instead. At step 69158, the ARU broadcasts a recording to the caller that may correct the wrong number entered or confirm that the correct number was entered. At step 69160, the ARU calls the subscriber's paging service using the data provided by the caller to indicate the number to be displayed on the pager as the paging service. If the call to the paging service is successful, the ARU sends a message indicating success at step 69164 and disconnects at step 69166. If the call to the paging service fails, at step 69162 the ARU returns after broadcasting a message indicating the failure, and in addition, the ARU may optionally provide additional options to the caller.

69N shows an ARU Alternate Routing routine. The ARU performs this routine to route calls that cannot be routed to the subscriber. If the subscriber indicates that such non-rooted calls will be routed to his or the caller's paging service, then at step 69170 the ARU broadcasts a recording of the subject that the caller can send the page. Then, in step 69172, the ARU executes the page transfer routine described in FIG. 69M. If the page transfer fails, the ARU broadcasts a message indicating the failure and at step 69174 disconnects the caller. If the subscriber indicates that the non-route calls will be routed to voicemail, at step 69173, the ARU broadcasts a recording of the subject that the caller can leave a voicemail message. If the subscriber's mailbox is not full, the ARU executes the ARU Xfer to Voice / Fax Guest Voice routine. At this time, if this routine returns, it means that the attempt to leave the voicemail failed, so the ARU broadcasts a message indicating the failure and blocks the caller at step 69184. However, if the mailbox is full, the ARU broadcasts a recording informing the caller of the condition and blocks the caller at step 69184. If the subscriber has indicated a "guest option", at step 69180 the ARU performs the ARU Alternate Routing Guest Option routine of FIG. 69O, otherwise the ARU does step 69182. Block the caller at

69O illustrates the ARU Alternate Routing Guest Option routine. This routine allows the guest to choose whether leaving a voicemail or sending a page is a subscriber and not reachable. In step 69190 the ARU provides the caller with a menu of available routing options. At this time, "1" leaves the voicemail and "2" sends the page.

If the caller requests a page transfer, the ARU executes the ARU Page Send routine of FIG. 69M at step 69200. At this time, if the page transfer fails, the ARU broadcasts a diagnostic recording to the caller and blocks the caller at step 69202.

When the caller wants to leave the voicemail, the ARU checks whether the subscriber's mailbox is full, and if not, executes the ARU Xfer to Voice / Fax Guest Voice routine of FIG. 69K. If the routine returns, it means that the attempt to leave the voicemail failed, and in that case or if the mailbox is full, the ARU broadcasts a pre-recorded message indicating that the voicemail could not be sent, and the step ( 69195) prompt the caller to indicate whether to send the page instead. At this time, if the caller selects the page transfer option, the ARU executes the ARU page transfer routine at step 69200 as if the caller first selected the option. If the ARU page transfer routine fails, then the ARU broadcasts a diagnostic message and blocks the caller at step 69202.

69P shows the main menu of an ARU User Call routine for handling calls from subscribers. This routine executes as step 69052 in the ARU guest menu routine, as shown in FIG. 69D when the caller enters a valid passcode. After the introductory welcome greeting is broadcast, the ARU checks if the subscriber's mailbox is full and, if the mailbox is full, broadcasts a message at step 69300 informing the subscriber of the condition. After broadcasting this alert or if the mailbox is not full, the ARU broadcasts a status recording in step 69302 that informs the subscriber of the number of new voicemail and fax messages stored for the subscriber. In step 69304, the ARU broadcasts a menu for the subscriber. In the illustrated example, item "1" corresponds to a call routing change request, item "2" corresponds to a mailing or retrieval request, item "3" corresponds to a call request, and item "4" corresponds to a management ( Administration) menu, item "0" corresponds to the request to switch to customer service.

If the subscriber selects the Change Call Routing option, in step 69310 the ARU performs the ARU Change Routing routine described in FIG. 69T, and if the subscriber selects the Send or Retrieve Mail option, the ARU waits for the subscriber. DAL then broadcasts the pre-recorded message and then performs the ARU Xfer to Voice / Fax Subscriber Send / Retrievre routine described in FIG. 69Q at step 69312. In addition, if the subscriber selects the call option, then at step 69314, the ARU provides the subscriber with a menu to query the type of call they wish to call. If the subscriber answers with an international or domestic phone number or with a preset speed dial number corresponding to the international or domestic phone number, then at step 69316 the ARU connects the call. If the subscriber requires the assistance of the operator, at step 69318 the ARU performs an ARU User Xfer to MOTC routine to divert the subscriber to the operator. If the subscriber cancels the call request, the ARU returns to step 69304. If the main menu is provided at step 69304, the ARU performs the Administration routine shown in FIG. 69P. If the subscriber requests customer service, then the ARU performs the ARU User Xfer to Customer Service routine described in FIG. 69H.

69Q illustrates an ARU Xfer to Voice / Fax Subscriber Send / Receive routine that connects a subscriber to a VFP for sending and retrieving voicemail messages. The ARU attempts to shake hands with the VFP. If the handshake succeeds, the ARU connects the call at step 69330, and if it fails, broadcasts an error message at step 69332 and exits the routine. 69R shows an ARU Xfer to Voice / Fax Subscriber Send / Receive routine that connects a subscriber to a VFP to manage a subscriber's classification list. The ARU tries to get a handshake of the VFP. If the handshake succeeds, the ARU connects the call at step 69340, otherwise broadcasts an error message at step 69342 and exits the routine.

69S shows an ARU Xfer to Voice / Fax Subscriber Record Name routine that connects a subscriber to the VFP to record a name to be used in a subscriber identity message generated at the VFP. The ARU attempts to shake hands with the VFP and, if the handshake succeeds, connects the call at step 69350. If the handshake fails, the ARU broadcasts an error message at step 69352 and then exits the routine. The routines of Figs. 69Q, 69R and 69S are similar except for the contents of the required message of the VFP and the error message to be broadcast to the subscriber.

69T shows an ARU Change Routing routine in which a subscriber modifies routing options associated with himself or the caller. In step 69390, the ARU provides a menu of options to the subscriber. If the subscriber selects the option for Find-Me-Routing, the ARU performs the ARU Find-Me Routing routine described in FIG. 69U. If the subscriber selects an option for override routing, then at step 694400 the ARU broadcasts a message indicating that the subscriber has set up override routing, and at step 69404 the subscriber can select a new menu. Provide a menu. If the subscriber selects the change option, the ARU performs the ARU program routine as step 69408 to set the override option as specified by providing the selected option with the parameters of the "override". If the subscriber selects the option "Cancel", the ARU returns to step 69390. If the subscriber selects "alternative routing" from the ARU Change Routing menu at step 69390, the ARU broadcasts a message indicating that the subscriber has set up alternate routing at step 69409, and step 69410 Provides a menu to the subscriber to select a new menu. If the subscriber selects a change option, the ARU provides the "alternative" parameters and the selected option, thereby providing a step to set the replacement option as specified. 69414) to execute the ARU program routine. If the subscriber selects the option "Cancel", the ARU returns to step 69390. If the subscriber selects "Cancel and Return" from the routing change menu of step 69390, then at step 69412 the ARU returns to the user menu of FIG. 69P. 69U shows an ARU Change Find-Me Routing routine. In step 69420, the ARU checks whether the subscriber's fine-rooting is due to a schedule. If not, the ARU at step 69422 broadcasts a message indicating that the routing has been set up to attempt three consecutive phone numbers, and at step 69424 the ARU 3-Number sequence described in FIG. 69V. Perform the Change 3-Number Sequence routine. If the subscriber's fine-me-rooting is due to a schedule, at step 69424 the ARU broadcasts a message that the subscriber's fine-meroute is currently set to a schedule, and at step 69428 the subscriber changes the scheduling menu. Schedule Routing menu) is provided. If the subscriber selects the option to change to the 3-Number sequence, then at step 69430 the ARU broadcasts a message that the routing is set to a 3-Number sequence, and at step 69432 the ARU Cahnge 3-number of FIG. 69V. Run the Sequence routine. If the subscriber selects the Save and Continue option, at step 69434 the ARU broadcasts a message indicating that the subscriber's Find-Mute routing is set to scheduled routing, and at step 69436 the ARU routing changes. (Change Routing) Run the routine. Further, step 69436 and the ARU routing change routine are performed even if the subscriber selects the "Cancel and Return" option.

69V shows an ARU 3-Number Change Routine that allows a subscriber to change the order and contents of the three alternative numbers used in the ARU Find-Me routines of FIGS. 69E and 69F. . At step 69440, the ARU provides a menu of options to the subscriber. If the subscriber selects the option to change one of the three telephone numbers, in step 69442 the ARU broadcasts a recorded message indicating the current setting for the number, and then in step 69444 the number and the number to be changed. A parameter indicating the POTS number to be changed is provided to the routine to execute the program routine and then return to step 69440. If the subscriber selects the option to review the current settings, at step 69446 the ARU broadcasts a series of messages indicating the settings for each of the three numbers and then returns to step 69440.

If the subscriber selects the option to change the schedule routing, the ARU checks in step 69450 whether the subscriber is suitable for schedule routing, and if appropriate, in step 69454, the feed-me-routing is placed on the subscriber's schedule. Broadcast a message indicating that it is set, and toggle schedule routing to enable schedule routing in step 69456. After toggling the settings, at step 69450 the ARU returns to the ARU Change Routing routine of FIG. 69T. If scheduling is not an option for this subscriber, then the ARU broadcasts a diagnostic message indicating that scheduling is not available and that the subscriber may contact Customer Service to obtain the option. Return to). If the subscriber selects the cancel and return option, the ARU returns to the ARU routing change routine of FIG. 79T.

69W shows an ARU Administration routine. In step 69460, the ARU provides a subscriber with a menu of options. For example, item "1" corresponds to a request to maintain a subscriber's broadcast or speed dial list, item "2" corresponds to a greeting recording request, and item "3" to enable or disable an add-on. It is a request. If the subscriber requires list maintenance, the ARU provides an option menu to the subscriber at step 69462. If the subscriber selects the option to maintain his or the caller's broadcast list, at step 69464 the ARU performs the ARU Xfer to Voice / Fax Subscriber Distribution Lists routine of FIG. 69R. After performing the routine, the ARU performs the ARU Lists routine of Figure 69W in step 694680. If the subscriber selects the option to maintain a speed dial list, the ARU in step 69470 determines that the ARU of Figure 69X. Perform the ARU Change Speed-Dial Number routine If the subscriber selects the option for cancellation and return, the ARU returns to step 69460.

In response to the menu provided at step 69460, if the subscriber selects a greeting recording option, at step 69474 the ARU provides the subscriber with a menu of options. For example, item "1" corresponds to a request to modify the subscriber's welcome message, and item "2" corresponds to a request to modify the name associated with the subscriber's mailbox. If the subscriber selects the Modify Welcome Message option, at step 69476 the ARU performs the ARU Play Greeting routine of FIG. 69B to broadcast the current welcome message, and at step 69478 the process of FIG. 69Y. Perform the ARU Change Greeting routine.

If the subscriber selects the option to change the mailbox name, the ARU broadcasts a wait request message to the subscriber, and in step 69480 performs the ARU Xfer to Voice / Fax Subscriber Mailbox Name routine already described in FIG. 69S. After that, the process returns to step 69474. If, in response to the menu provided at step 69474, the subscriber cancels the greeting modification request (eg, by pressing the star button), the ARU returns to step 69460.

If the subscriber selects the option to activate or deactivate the function in response to the menu provided at step 69460, then at step 69484 the ARU performs the ARU Feature Activation routine described in FIG. 69Z. If the subscriber cancels the greeting modification request (eg, by pressing the star button), the ARU returns to the ARU User Menu routine described in step 69304 of FIG. 69P.

69X shows an ARU Change Speed Dial Numbers routine. In step 69490 the ARU provides the subscriber with a menu of options corresponding to a particular speed dial number, for example, item "1" corresponds to the first speed dial number and item "2" corresponds to the second speed dial. A number "9" corresponds to the ninth dial speed number. Thus, if the subscriber selects one of these items, at step 6959 the ARU broadcasts a message indicating the setting of the selected speed dial. In step 6945, the ARU specifies "Spd_Dial_n" parameters to indicate the speed dial number to be programmed (where n is replaced by the digit corresponding to the number of the designated speed dial button), and the designated speed dial number is set. Perform the ARU program routine described in FIG. 69AA, specifying the POTS number to be. The ARU then returns to step 69490. If the subscriber selects the option (marked with an asterisk) to cancel the speed dial number change request, the ARU returns to step 69492 described in FIG. 69W.

69Y shows an ARU greeting change routine. In step 69500 the ARU provides a menu corresponding to the options available to the subscriber. For example, item "1" corresponds to a customer greeting recording request, and item "2" corresponds to the use of a standard system greeting. If the subscriber selects the option to record the customer greeting, at step 69502 the ARU provides a menu of options related to the desired greeting. For example, item "1" corresponds to a request to review the current contents of the customer greeting entered by the subscriber, and item "2" corresponds to a request to replace the currently recorded customer greeting with a new recorded customer greeting. do. A well sperm ("#") corresponds to a request to save the contents of the greeting, and an asterisk ("*") corresponds to a request to cancel and return.

If the subscriber selects the option to review the contents of the customer greeting that he has entered, in step 69504 the ARU performs the ARU Play Temp Greeting routine already described in FIG. 69C and step Return to 69502. If the subscriber selects the option to replace the currently recorded customer greeting with a newly recorded customer greeting, at step 69504 the ARU urges the subscriber to begin recording a new greeting, and at step 69506 the new greeting is received. Record. After recording the greeting, the ARU returns to step 69502, where the subscriber may request to save the newly recorded greeting. If the subscriber selects to save the greeting at step 69510, the ARU records the recorded greeting over the previous contents of the greeting file and stores it on disk, and at step 69514 broadcasts a message indicating that the new greeting has been saved. After saving the greeting, the ARU performs the ARU management routine described previously in FIG. 69W. If, in response to the menu provided by the ARU at step 69502, the subscriber cancels the greeting modification request, at step 69518 the ARU performs the ARU greeting routine described in FIG. 69W.

If, in response to the menu provided at step 69500, the subscriber selects the option to use a system greeting (eg, a default greeting that cannot identify the subscriber), then at step 69520 the ARU deletes the already recorded greeting and then steps At 69522, the caller broadcasts a pre-recorded message that he will now hear the system greeting instead of the personal greeting. The ARU then returns to step 69522 to perform the ARU management routine described in FIG. 69. The ARU also returns to step 69525 if the subscriber selects the cancel and return option.

69Z shows an ARU Feature Activation routine. In step 69530 the ARU provides a menu corresponding to the options available to the subscriber. For example, if item "1" corresponds to the request for setting the call screening option, and item "2" corresponds to the request to activate or deactivate the pager recipient, item "3" corresponds to the request to set up the pager notification. Correspondingly, option "4" corresponds to the request to activate or deactivate the account. If the subscriber selects call screening, then at step 69532 the ARU broadcasts a recording indicating that the current call screening option has been set. In step 69532 the ARU provides the subscriber with a list of options related to call screening. In this case, item "1" corresponds to the request for selecting screening by ANI (phone number), item "2" corresponds to the request for selecting call screening by name only, and item "3" corresponds to ANI. Corresponds to the request to select screening by name, and item "4" corresponds to the request to return to call screening off. If the subscriber selects one of the above options, at step 69536 the ARU provides a first parameter indicating a change in the screening option and a second parameter indicating the option value to be set, thereby describing the ARU described in FIG. 69AA. Run the program routine. Next, at step 69536, the ARU returns to step 69530. Otherwise, if the subscriber selects the cancel and return option at step 69534, the ARU returns to step 69530.

If the subscriber selects the option to activate or deactivate the pager, at step 69538 the ARU broadcasts a recording message indicating the new state of the pager notification option. At step 69540, the ARU toggles the current state of the pager option (eg, enable if the current option is disabled, disable if the current option is enabled). The ARU then returns to step 69530 after the toggle.

If the subscriber selects the pager notification option, at step 69542 the ARU broadcasts a recording indicating the current setting of the call screening option, and at step 69544 provides the subscriber with a list of options related to pager notification. For example, item "1" corresponds to a request to select notification of an incoming voicemail only with a pager, item "2" corresponds to a request to select notification of an incoming fax only to a pager, and item "3". Corresponds to a request to select notification of an incoming voicemail and an incoming fax to the pager, and item "4" corresponds to a request to completely switch call pager notification. If the subscriber selects one of these options, in step 69546 the ARU provides a first parameter indicating that the pager notification option is to be changed and a second parameter indicating the option value to be set, as described in FIG. 69AA. Perform the ARU program routine to be used. Next, at step 69546, the ARU returns to step 69530. Otherwise, if the subscriber selects the cancel and return option at step 69544, the ARU returns to step 69530.

If the subscriber selects the option to activate or deactivate himself or the caller's account at step 69530, then at step 69550 the ARU broadcasts an announcement indicating the new account status. At step 6952, the ARU toggles the current state of the account option (activates the option if it is currently inactive and deactivates it if it is active) and returns to step 69530. If the subscriber selects the cancel and return option at step 69530, the ARU returns to the ARU management routine described in FIG. 69W.

69AA shows an ARU program routine that is set by the subscriber to set options selected and performed by the ARU.

As shown in step 69560, the program routine has, as input, a Term_Slot that specifies two parameters, an option whose value is to be changed, and a Term that indicates the set value of the options specified by the Term_Slot. In step 69562 the ARU checks the type of value set in Trem so that if the parameter value is a POTS identifier (e.g., a telephone number to be programmed as a speed dial number as in step 69494 in FIG. 69X). Phone number), in step 69564, the subscriber is prompted to enter a POTS number. At this time, if the subscriber enters a national or international telephone number or an option (eg, "1") for erasing a previously stored POTS value, in step 69566, the ARU sets a new setting for the designated slot to be changed. Broadcast a message indicating. At step 69568, the ARU urges the subscriber to re-enter a new number to modify the number to confirm or cancel the request. At this time, if the subscriber selects the option to modify the number, the ARU returns to step 69564. If the subscriber confirms the request, at step 69570, the ARU returns the parameter (Term) as the variable specified by the parameter Term_Slot. Save the value. Then, if the subscriber cancels the request, the ARU returns to the calling routine at step 6767 2. In addition, if the subscriber selects the cancel option when the POTS number is prompted in step 69564, the ARU returns to the call routine in step 69572.

If the parameter value is not a POTS identifier, then at step 69580 the ARU broadcasts a message informing the subscriber that the specified option will be changed. At step 6958, the ARU urges the subscriber to confirm or cancel the request. At this time, if the subscriber selects confirmation of the request, at step 69584 the ARU stores the parameter value as the variable specified by the parameter Term_Slot and returns to the calling routine at step 6767 2. If the subscriber cancels the request, the ARU returns to the calling routine at step 6767 2 without storing the value.

69AI shows the ARU User Xfer to Customer Service routine. In step 69592, the ARU broadcasts a pre-recorded message requesting the subscriber to wait, and then in step 6859, converts the subscriber to a customer consumption.

69AB shows the ARU Validate Guest Entry routine. This routine is used by the ARU and is a routine for determining whether the use of the VFP guest facility by the guest is valid. The ARU allows a guest to enter his or her opponent's identification information up to three times. For the first two invalid attempts, the ARU returns a status at step 6696 indicating that the guest input is invalid. For the third attempt, the ARU performs the ARU Find-Me routine of FIGS. 69E and 69F at step 69615. If a guest input is received, at step 69617 the ARU checks whether the guest input is one of the valid ones selected from the applicable menu. If not, at step 69620 the ARU broadcasts a recorded message indicating that the guest input option cannot be used. If the guest input is the third invalid input, then at step 69624 the ARU performs the ARU Guest Xfer to MTOC routine of FIG. 69H, and if the first or second invalid input is a guest input to the routine at step 69622. It returns after indicating that it is invalid. If the ARU determines at step 69696 that the guest input was an appropriate menu option, it returns to a valid state at step 69626.

69AC is an ARU Validated User Entry routine used by the ARU to determine if a subscriber's attempts at using VFP's subscriber services are valid. If no user input is received, at step 69630 the ARU broadcasts a diagnostic message that no input has been received, and if an input is received, the ARU at step 69634 displays a menu of options for user input. Check if it is included. If so, then the ARU returns to a valid state at step 69636; otherwise, at step 69638 the ARU broadcasts a diagnostic message indicating that the option is not available. If no input is received or the input is not valid for the menu, the ARU checks at step 69632 if this is the third failure to specify subscriber information. If it is the third failure, the ARU executes the ARU User Xfer to Customer Service routine of FIG. 89AI at step 69640 and returns to the invalid state at step 669642 if it is the first or second failed input.

69AD shows an ARU Validate Passcode Entry routine used by the ARU to verify the passcode entered by the subscriber. At step 69650, the ARU checks if the entered passcode matches the passcode of the particular subscriber, and if so, at step 69652, the ARU returns to a valid state. However, if the input is invalid, then at step 69654 the ARU broadcasts a recording message that the input is invalid. The ARU represents a valid passcode in two attempts. In step 69656, the ARU checks if the attempt is a second attempt to enter a passcode. At this time, if it is the second attempt, the ARU in step 69660 performs the ARU User Xfer to Customer Service routine described in FIG. 69AI, and if it is the second attempt, the ARU enters a valid passcode for the subscriber in step 69658. After prompting, the process returns to step 69650.

69AE illustrates an ARU Validation Completion routine used by the ARU to verify valid phone number entry. In step 69670 the ARU checks if a valid user input has been received and if it is not received it is the third invalid input attempted. If this is not the third invalid input, then at step 69672 the ARU sends an indication to the indicator that no valid input has been received. However, if the third invalid input, the ARU broadcasts a message in step 69674 and performs the ARU Xfer User to MTOC routine described in FIG. 69H in step 69676.

If a valid user input is received, the ARU checks if the entered telephone number begins with "011". If so, then at step 69680, the ARU performs the Validation International Completion routine of FIG. 69AF. In step 69682, the ARU checks if the domestic term flag is set by the subscriber. If not, in step 69684, the ARU broadcasts a message indicating that the domestic call cannot be used and proceeds to step 69671. . In step 69686, the ARU checks whether a 10-digit number has been entered and checks in step 69688 whether a valid MPA-Nxx number has been entered. If the entered number is not a 10-digit valid MPA-Nxx number, then in step 69690 an ARU diagnostic message is broadcasted and the process proceeds to step 69671. At step 69690 the ARU checks if NADP blocking is valid for this subscriber and at step 69692 if 976 blocking is valid for this subscriber. If all blocking is valid, at step 69696 the ARU broadcasts a diagnostic message indicating that the calls to the specified number are blocked and proceeds to step 69671. If all blocking is not valid, the ARU at step 69696 Sends status that the entered number is valid.

FIG. 69AF illustrates the ARU Validate International Completion routine. In step 69700, the ARU determines whether the subscriber has an international call arrangement or not, and generates a message indicating otherwise (step 69702). The ARU then checks whether the entered number is valid as an international dialing number (step 69704). In step 69708, the ARU determines whether Cset Blocking will block the particular number, and if so generates a message indicating this (step 69710). If no error condition is found, the ARU returns to a valid state (step 69712). If an error is found, the ARU transitions to an invalid state (step 69713). If the third attempt to enter the number fails, the ARU generates a status message (step 69714) and sends the subscriber to the operator (step 69716).

FIG. 69AG shows the ARU Validate POTS Programming routine, used by the ARU to verify that only one valid phone number has been stored for use by call routing. do. In step 69720, the ARU checks whether a valid user entry has been received, and if not, the ARU determines if this was the third invalid entry input. If not, the ARU indicates that no valid entry was received (step 69722), while if this was the third attempt, the ARU User Xfer to customer as shown in FIG. 69AI described above. Service routine) (step 69676).

If a valid subscriber entry has been received, the ARU determines if the entered telephone number starts with "011" and if so performs the Validation International Completion routine of the ARU of FIG. 69730). In step 69732, the ARU checks whether the domestic terms flag is set by the subscriber, and if not, generates a message indicating that the domestic currency is not available (step 69734) and proceeds to step 69721. . In step 69736, the ARU confirms that a 10-digit number has been entered, and in step 69738 a valid MPA-Nxx number has been entered, and if neither is entered, the ARU generates a message indicating this (step 69740), the process proceeds to step 69721. In step 69750, the ARU determines whether 976 blocking is effective for the subscriber, and if so generates a message indicating that the call to the designated number has been blocked (step 69754) and proceeds to step 69721. Otherwise, the ARU enters a valid state (step 69756).

FIG. 69AH illustrates the ARU Validate International Programming routine, which is used by the ARU to verify that one valid telephone number has been stored for use by call routing. In step 69760, the ARU determines whether the subscriber is in an international call arrangement and generates a message indicating otherwise (step 69762). In step 69764, the ARU determines whether the entered number is valid as an international dialing number, and if not, the ARU generates a message indicating this in step 69766. In step 69768, the ARU determines whether Cset blocking will block the particular number, and if so, the ARU generates a message indicating this in step 69770. If no error condition is found, the ARU returns to a valid state (step 69772), and if an error is found, returns to an invalid state (step 69773). If three attempts to enter the number have failed, the ARU generates a status message (step 69774) and sends the subscriber to the operator (step 69776).

70A-70S illustrate a flow diagram of an automated console call showing software implementing the aforementioned direct line MCI product, which is useful for a better understanding of the present invention. Console call order is different from ARU call order. That is, the console call is operated by an individual who will respond to a request by the caller as opposed to automation. This allows the caller without DTMF-enabled equipment to use the product. DTMF data provided by the sender will be processed, and the utility of the human operator permits many useful operations to be performed without the use of DTMF input. The data may be entered directly by the caller on the keypad or by the operator in response to a voice response provided by the caller.

70A illustrates a starting point for an automated console call to proceed to a fare account. As the call begins, it is considered a guest call. If the charge calculation is not currently online, the automatic console generates a message indicating that the call cannot be accepted for charge calculation (step 70010). If the caller does not indicate to the operator that he has a passcode, the console hangs up (step 70012). If the caller provides the operator with a passcode, the operator begins the console's Console Validate Passcode routine (step 70014), which is described below with respect to FIG. 70K.

If billing is currently online, the console checks if the subscriber has instructed an override of an incoming call and if so, the console sends the call to the operator (step 70018). If the sender is generating a fax tone, the console performs a console fax tone detection routine (step 70024), which is described below with respect to FIG. 70S. If the caller has provided the operator with a passcode, the operator begins the console's Console Validate Passcode routine (step 70026), which will be described below with respect to FIG. 70K. Otherwise, the call is treated as an incoming call to the subscriber, and the console performs a Console Find Me routine (step 70020), which is described below with respect to FIG. 70BC. The console provides an "override" variable for the Console Find Me routine.

If no specific override is set, the console provides a menu that the caller can hear (step 70030). For example, item '1' relates to asking the subscriber to speak, item '2' relates to asking the subscriber to leave a voice mail message, and item '3' asks the subscriber to send a fax. And item '4' relates to the subscriber call request. In addition, the subscriber will provide his passcode to access the console as a subscriber.

If the caller requests to speak to the subscriber, the console checks the schedule flags associated with the caller's profile (step 70032). If instructing the subscriber's profile schedule, the console performs the Console Find Me routine of the console of FIGS. 70B and 70C, using "Sched1" as a variable (step 69034). If the subscriber's profile does not indicate a schedule, the console performs a console find me routine of the console using "First" as a variable (step 69036). The Console Find Me routine of the console will be described in more detail below with respect to FIGS. 70B and 70C.

If the caller requests to leave a voice mail message, the console performs a console Xfer to Voice / Fax Guest routine (step 70040), which is described below with reference to FIG. 70E. It is explained. If the caller requests a fax transmission, the console performs a console Xfer to Voice / Fax Guest w / or w / out Annotation routine (step 70042). This is explained below. After performing the procedure, the console returns to the guest menu (step 70030). If the sender requests to leave a voice mail message, the console performs a Console Send Page routine (step 70040), which will be described below with respect to FIG. 70G. After performing any of the above steps 70040, 70042 or 70044, the console enters the guest menu (step 70030).

If the sender provides a passcode, the console performs a Console Validate Passcode routine (step 70046), which is described below with respect to FIG. 70K. If the console detects a fax tone in an incoming call, the console performs a Console Fax Tone Detected routine (step 70048), which is described below with respect to FIG. 70S.

70B and 70C show the operation of the Console Find Me routine of the console. As shown in step 70060, the console's console find me routine has one variable Term_Slot, which is set by the sender and used by the console to select one of several alternative operating procedures. . If Term_Slot is set to "Find Me", this indicates that the console uses a default method to determine the subscriber's current number. This value may, for example, be set to override or default processing. If the subscriber profile includes a schedule flag, the console performs a console find me routine of the console using the variable 'Sched1' as shown in step 70062, and if not, the console As shown in step 70061, the first phone number in the number list for the subscriber is used to perform a Find Me routine.

If Term_Slot is set to "Voicemail", the console sends a message to the sender indicating that the caller has requested the subscriber to leave a voicemail message, and the voice / fax guest switch of the console, as shown in Figure 70E. A procedure (Console Xfer to Voice / Fax Guest routine) is performed (step 70074). If the procedure fails, the process returns to generating a message for the caller to attempt the call later, and disconnects from the caller (step 70075).

If Term_Slot is set to "pager", the console sends a message to the sender indicating that the subscriber requested that the caller requested to leave a call request. The console then performs a Console Send Page routine, which is described below with respect to FIG. 70G. If it fails, the procedure returns to the process of generating a message for the caller to attempt the call later, and disconnects from the caller (step 70066).

If Term_Slot is set to any POTS value (such as Schedule1, Sched2, First, Second, or Third) that indicates that the subscriber has set up incoming calls using a standard telephone system, the console will display a specially designed or selected phone number. I will command it to use. In step 70070, the console performs a console record name routine to obtain a digital record indicating the identity of the caller. The Console Record Name routine is described in more detail below with respect to FIG. 70H. The console displays the appropriate message for the caller in steps 70073 and 70075 (i.e. "wait until I reach you on the first try" and "I am still trying to reach you on the first try; keep on waiting") ).

If the caller receives a response from the person, the console performs a Console Connect Call routine to connect the caller (step 70072), which is described below with respect to FIG. 70D. If the caller receives a response from the answering machine, the console checks to see if the subscriber has requested to be forwarded to the next other number when connected to the answering machine (step 70090), otherwise the console connects the call. (Step 70094). If the subscriber chooses to pass to another phone number, the console alternately chooses to call the next number and uses the recently selected number to find the subscriber's subscriber procedure, as shown in steps 70081, 70082 and 70083. Run (Console Find Me routine) again.

If the call line is busy or the confirmed number no longer exists, the console performs the console alternate routing routine shown in FIG. 70I (step 70074).

70D illustrates a console connect call routine. If the subscriber did not request to block the call, the console connects the call to the subscriber (step 70100). If the subscriber has requested to block the call, the console sends an information message to the subscriber that can identify the caller by name or ANI if necessary (step 70104). If the subscriber chooses to answer the call, the console releases the caller's wait (step 70106), generates a message indicating that the call is connected (step 70108), and performs a call connection (step 70110). If the subscriber refuses to answer the call, the console releases the caller's wait (step 70114), notifies the calling party that the subscriber has not been reached, and generates a message asking if the caller will leave a voice mail message selectively. (Step 70118). If no mailbox is available, the console generates a message indicating this (step 70119), and disconnects the caller (step 70120). If there is a valid mailbox and can receive the message, the console performs the console Xfer to Voice / Fax Guest Voice routine shown in FIG. 70E (step 70128). After the procedure is performed, the console generates a message requesting the caller to call back later (step 70119) and disconnects (step 70120).

The Console Tone Detected routine of the console of FIG. 70S is shown. In step 70130, the console attempts to handshak with the VFP. If the handshaking succeeds, the console connects the call in step 70132, and if it does not succeed, disconnects the caller in step 69132.

70E illustrates the console's console Xfer to Voice / Fax Guest Voice routine, which connects the caller to the VFP to leave a voice mail message. The console generates a status message in step 70140 and checks in step 70142 whether the subscriber's mailbox is full. If the mailbox is full, the console generates a message indicating this (step 70144) and returns, and if the mailbox is not full, the console attempts to handshak with the VFP. If the handshaking succeeds, the console connects the call (step 70146), and if it does not succeed, generates an error message (step 70148) and returns.

70F shows the console Xfer to Voice / Fax Guest Fax w / or w / out Annotation routine, which connects the caller to the VFP to send a fax. It is. The console generates a status message in step 70150 and checks in step 70152 if the subscriber's mailbox is full. If the mailbox is full, the console issues a message indicating this (step 70154), and if the mailbox is not full, attempts handshaking with the VFP. If the handshaking succeeds, the console connects the call (step 70156), and if the handshaking does not succeed, generates an error message (step 70148) and returns. The procedures shown in Figures 70E and 70F are almost similar except for the content required for the VFP and the content of the error message sent to the sender.

70G shows a console send page routine, which initiates a call to the subscriber's calling service. In step 70160, the console allows the caller to leave a phone number to send to the designated pager. In step 70162, the console sends a status record to the sender requesting to wait while the call is sent. If the call was sent successfully, the console generates a status message indicating that the call was sent and hangs up at step 70165. If the call to the calling service is unsuccessful, the console informs in step 70166 that the failure has occurred, allows the caller to provide additional choices and returns.

70H shows a console record name routine. The procedure is used to record the caller's name when the subscriber has set up blocking of a particular call by name or by name and ANI. If the subscriber has set a name or name and specific call blocking by ANI, the console may enter a name for the caller in step 70170 and record the audible response. If a fax tone is detected during the recording process, the console performs a Console Fax Tone Detected routine in step 70172, otherwise the procedure returns.

FIG. 70I illustrates a Console Alternate Routing routine. The console performs the above procedure for routing calls that cannot find subscriber path. If the subscriber is set to route to the calling service for calls not found, the console generates a message indicating that the caller will send a page (step 70180). If the sender decides to send the page, the console performs the Console Send Page routine described in connection with the 70G (step 70182). If the call is unsuccessful, the console generates a message indicating this (step 70185) and disconnects the caller (step 70184). If the subscriber has routed to voicemail for calls not found, the console generates a message indicating that the caller will leave a voicemail message (step 70183). If the caller decides to leave a voicemail, the console performs a console Xfer to Voice / Fax Guest Voice routine, described in connection with FIG. 70E ( Step 70186). If the voicemail fails, the console generates a message indicating this (step 70185) and disconnects the caller (step 70184).

If the subscriber has indicated a "guest option", the console performs the Console Alternate Routing Guest Option of FIG. 70J (step 69190). Otherwise, the console generates a message indicating this (step 69192) and disconnects the caller (step 69194).

FIG. 70J illustrates a Console Alternate Routing Guest Option routine. This procedure allows the guest to choose whether to leave a voice message or send a call if the guest cannot reach the subscriber. The console provides the caller with a valid routing option (step 70200), which is either to leave a voice message or to send a call. If the caller requests to send a voicemail, the console performs the console Xfer to Voice / Fax Guest Voice routine shown in Fig. 70E (step 70202). If returning to the return code indicating that the procedure failed, the console sends a pre-recorded message indicating that the voicemail could not be sent and asks the sender whether to send the call instead (step 70204). If the caller requests a call transfer in response to step 70200 or 70204, the console performs the console Send Page routine shown in FIG. 70G (step 70206). If the Console Send Page routine returns (indicating that the call was not sent) or the sender refuses to send the call in response to step 70204, the console generates a message indicating this (step 70208), the connection with the caller is terminated (step 70209).

70K illustrates a Console Validate Passcode Entry procedure of the console, which is used by the console to verify the passcode provided by the subscriber. In step 70220, the caller asks for a passcode. And in step 70224, the console checks whether the entered passcode matches the passcode for a particular subscriber, and if so, the console performs a console user call routine (step 70226), which relates to FIG. 70L. Will be described below. The console allows two attempts to set a valid passcode. The console then checks if the second attempt to provide a passcode fails, and if the second attempt fails, the console informs the caller that the passcode is invalid (step 70232), and the caller provides customer service. Suggest linking to (customer sevice). If the caller does not choose to connect to customer service, the caller disconnects (step 70234). If this was the first attempt, the console prompts the subscriber to enter a valid passcode (step 70230) and returns to step 70224.

70L shows a console user call routine of the console. In step 70240, the console checks whether the subscriber's mailbox is full, and if so, generates a warning message to the subscriber (step 70242). Regardless of whether the mailbox is full, the console sends a status message to the subscriber informing the subscriber of the number of voicemail messages and faxes in the mailbox (step 70244). In step 70246, the console provides the subscriber with choices. For example, item '1' relates to requesting to send or retrieve mail, '2' relates to requesting to place a call, and '3' relates to requesting to exit. If the subscriber selects an item for sending or retrieving mail, the console generates a waiting message (step 70248), and the console Xfer to Voice / Fax Subscriber Send / Retrieve procedure of FIG. 70M. routine). After the procedure is completed, the console returns to step 70246. If the subscriber selects a call placement item, the console performs a Console Outbound Calling routine, which is described below with respect to FIG. 70N. If the subscriber selects the Exit Programming item, the console drops the call.

70M shows a console X / Fax to Fax / Fax Subscriber Send / Receive routine, which connects a subscriber to a VFP that sends or retrieves a voicemail message. The console attempts handshaking with the VFP, and if the handshaking is successful, the console connects the call (step 70250). If not successful, the console generates an error message (70252) and exits.

70N shows a console outbound calling routine, which is a procedure by the subscriber placing an outgoing call. In step 70260, the console confirms that the subscriber is set up to place an international call, and if so, the console enables an international call key to enable non-national calls (step 70262). In step 70264, the subscriber is prompted to enter a phone number. The console then connects the subscriber with the outgoing call (step 70268).

FIG. 70O illustrates a Console Valodate Guest Entry routine. The procedure is a procedure by which the console determines if an attempt by a guest using a VFP guest facility is possible. The console determines if the guest entry was one of the possible choices in the applicable menu (step 70270), and if not, as shown in step 70272, the entry is not accepted and the console maintains the same menu. If the guest entry is an appropriate menu selection, the console returns to a valid state (step 70274).

70P illustrates the Console Validate User Entry routine, which is used by the console to verify an attempt by a subscriber to use the subscriber services of the VFP. The console determines if the user entry is one of the valid choices in the applicable menu (step 70280), and if not, as shown in step 70282, the entry is not accepted and the console maintains the same menu. . If the user entry is an appropriate menu selection, the console returns to a valid state (step 70284).

70Q illustrates a Console Validate Completion routine, which is used by the console to verify the entry of a valid telephone number. In step 70292, the console determines whether a domestic term flag is set by the subscriber, and if not, the console generates a message indicating that the domestic call is unavailable (step 70294). It returns to the instruction indicating that the entered number is not valid (step 70310). In step 70296, the console determines whether a ten-digit number has been entered, and in step 70298, confirms that a valid MPA-Nxx number has been entered. If the entered number was not a 10-digit valid MPA-Nxx number, the console generates a message indicating this (step 70302) and returns to an indication that the entered number is invalid (step 70310). In step 70304, the console determines whether NADP blocking is valid for the subscriber and, in step 70306, confirms that 976 blocking is effective for the subscriber. If either of the two blocking is valid, the console generates a message indicating that the call to the designated number is blocked (step 70308) and returns to an indication that the input number is invalid (step 70310).

FIG. 70R illustrates the Console Validate International Completion routine. In step 70322, the console confirms that the subscriber has established an international call arrangement, and if not, the console generates a message indicating this (step 70324) and returns to an indication indicating that the entered number is invalid (step 70324). 70340). In step 70326, the console checks whether the number starts with "011" set to indicate that the number is an international number, and in step 70327, the console determines whether the entered number is valid as an international phone number. If the number does not begin with "011" or is invalid, the console generates a message indicating this (step 70328) and returns to an indication that the number is invalid (step 70340).

In step 70330, the console confirms whether Cset blocking will block the particular number, and if so, the console generates a message indicating this (step 70332). If no error condition is found, the console returns to valid state (step 70334).

The implementation of the advanced direct line MCI product described above has the following effects in the billing procedure:

Direct Line MCI Domestic Billing Type: 15

Direct Line MCI International Billing Type: 115

Direct Line MCI Call Type

Billing details, OSR for billing, and SCAI message operations for restart are as follows for various direct line MCI call types:

Billing type 115 is not applicable to BDRs generated by VFP (call type 144). Because all these calls originate from the VFP, they are all billed domestically using billing type 15.

* Account number refers to the user's 800 / 8xx access number.

** Termination status is offered; Other values may be more suitable.

Guest connection termination BDR is connection termination

At some point in the call sequence

Have different currency types

The following is a new direct line MCI script for an answering machine (ARU), referring to the relevant call sequence diagram in which they appear. diagram

The following are the new straight line MCI scripts for console application.

The ARU impact is described in detail below, and its call flow chart is also shown.

User input

In general, throughout the call flow, for every opportunity for user / caller input, the likelihood of response delay is minimized as much as possible. Here are some examples:

During the 'guest' portion of the call, the subscriber will enter '*'. The NIDS audio server (NAS) then begins to sum the six-digit passcode, with an inter-digit timeout. During the course of the guest menu, any single key other than '*' is entered and an immediate response is given. Where '*' is required, a six-digit passcode must be entered. If a single key is pressed while the user menu is in progress, an answer will come immediately, except in the case of an outbound call menu. The reason is that a domestic phone number, an international phone number, or a speed dial number is supposed to be entered in this menu, and the system allows the user to press '#' which means the end of the dialed digit. '# Can come after a single digit or after a multi-digit phone number.

Wherever a user can enter a national or international number, the '#' key is to mark the end of the dial digit anywhere in the call sequence. This includes programming the first, second or third subscriber lookup numbers and speed dial numbers and override routing to POTS.

Where possible, 'power dial' capability for the user is built into the call sequence. This means that if multiple keys are entered, the script is bypassed and the appropriate menu has been reached.

In this embodiment one access method is maintained for straight line MCI; How to access 800 / 8xx numbers that do not have a PIN. The PIN portion in the database defaults to 0000.

Check your billed number block (cheating)

All received direct line MCI calls require a billed number blocking confirmation, which proves that the number has not been identified as a risk of fraud. The lookup is in category 5, type 0; The identified flag is a credit card (Hot) flag. When the number is 'shut down', i.e. when the Hot flag is set to 'Y', the application treats the call as an offline transaction, but allows the subscriber to access programming choices. I never do that.

WorldPhone

Callers can access the direct-line MCI platform through the WorldPhone. In a preferred embodiment, these calls reach the direct line platform with pseudo-ANI (pseudo-ANI) in the calling number portion of the SCAI message. The pseudo ANI is associated with a particular Feature Group A (FGA) circuit from which the expansion of the world telephone call began. In another embodiment, the actual originating country information is transmitted to the direct line platform; The calling number portion is occupied by a three digit country code.

In a preferred embodiment, a WorldPhone-originated direct line call is billed as follows:

Calls originating through a world telephone and reaching the direct line platform with the pseudo ANI as the outgoing call are billed for domestic use using billing type 15. The calling number portion in the BDR is an FGA pseudo ANI.

In another embodiment, the call is charged as follows:

The ARU and console implement code to verify that the calling number portion contains a pseudo ANI or actual calling information. If actual country code origination information is provided, the application consults its configuration file, where the world call pseudo ANI is an optional entry. The presence of this item in the configuration file indicates how the application should charge the call.

If the application finds the world phone pseudo ANI in its configuration file, the call is billed for domestic use using billing type 15. The number to call in the BDR is set to its global telephone pseudo ANI, and the application instructs the bridge switch to change its caller ID to the same pseudo ANI.

If the application does not find the world phone pseudo ANI in the configuration file, the call is billed for international use using billing type 115, and the calling number information in the switch record is kept. The BDR is occupied by a ten-digit string; '191' + 3 digit country code + '0000'.

Guest call routing is defined by direct line MCI subscribers in several ways, which are described in the following paragraphs:

Blocking checks for guest incoming based on the source, which is included below.

Call Routing

The user is given two choices in the call routing definition; Find-Me procedure and schedule sequence. As an exception to the schedule definition, the user can define call routing through DTMF.

3-number find-me sequence

If the user selects the Find-Me procedure for call routing, the application initiates a call to the user's first programmed number. If the actual response is received, the guest caller is connected to the responding party. The call blocking described below will be activated if the answering party must actively accept the call before the call is connected. If the line of the first number is busy, the call is routed to an alternative routing programmed by the user described below. If no response is detected after the set time, the application initiates a call to the user's second programmed number.

The response process of the second number is the same as the call attempt for the first number for the result of no answer in the user's call attempt for the third number. The response process in the third number is the same for the result with no response in the alternative routing. If no incoming slot is programmed at any point in the call procedure, the application skips that number in this procedure and proceeds to the next number or alternative routing.

For any programmed international termination, the application looks up the destination area code in the country code table. If the Direct Dial Country flag is set to 'Y' for the region, the ARU sends a manual console (TTC = le) to handle the call.

2 level schedule sequence

If the user has selected a schedule sequence for call routing, the application joins the 800 translation database to retrieve schedule information to use the Schedule 1 trans and Schedule 2 trans fields as keys. From the two schedule conversions of the user and from using the current date and time, the first and second schedule numbers are determined.

The call enters the first schedule number, and as described in the Find-Me Sequence section, the response process does not have a response causing a call attempt to the second schedule number. The response processing in the second schedule number is not the same as the response causing the bypass routing.

If at any point in the schedule call sequence, the called number cannot be found again, the application will skip that slot in the sequence and proceed to the next number or bypass routing.

The user's schedule is set during Order Entry and cannot be updated by the user via DTMF. In an order entry, the user is asked to set his schedule to weekly, date, time (in increments of 20 minutes), time zone.

Override Routing

An option is available via DTMF to allow the user to disable the presentation of the guest menu by handling special routing for all guest requestors. Through override routing, the user associates the requesters with a single phone number, allows the requester to leave a voicemail message, allows the requester to page to him, or executes a programmed call routing (Find-Me or schedule). You can connect the requestor via

If a user has an override route to route to a phone number, no response occurs that causes the bypass routing process to occur at that number.

Alternate Routing

Bypass routing allows the user to define through the DTMF the handling of requestors who have attempted to access a subscriber but have no response. Bypass routing options include voicemail, pager, end message, guestmail's guest options, or pager's guest options. The default for bypass routing plays the exit message when it is not programmed.

Default routing

The user can specify order entry handling for requesters who do not respond to two attempts when the guest menu appears. The default routing option is a call to an operator (TTC = 67) where the guest menu reappears, an unanswered phone number that causes bypass routing, voice mail, or call routing (Find-Me or schedule). The default for the default route is to send the operator if it is not programmed.

Call screening

The user can represent all guest requestors to invoke call screening. Call screening options include no call screening, name and preliminary programming of ANI, only ANI, only name, and the like. Users can program call screening via DTMF.

Only the name or name and the name of the requester is recorded when ANI screening is programmed. If the user does not respond to the prompt nothing is logged and the system will default to ANI screening only. When a response arrives at the called telephone number, the requester's name or / and ANI is played and the responding party is required to accept or reject the request. If the call is accepted, the requestor will be connected. If call screening includes ANI screening and the calling number is a region code, the text "... International Location" will be displayed instead of ANI. If the call is rejected or no response is received from the answering party, the requester is asked to leave a voice message, or if the user has not subscribed to the voicemail the end message will be played.

Timeout parameter

The timeout value is set within a few seconds in the directline MCI database for the following termination.

These timeout values are decoded to 25 seconds, but the user can change them through customer service.

Call connection time

The call connection delay is most minimized when the guest call of the programmed incoming is completed.

Response detection

For every call attempt of the telephone number, the process for detecting the answering machine is defined by the Roll of the Machine Detect flag (State flag, 9 bits). If this flag is set to 'N', the requestor is connected to the responder. If set to 'Y', the application is routed to the next number in the bypass routing or calling sequence.

The current response detection for the ISN is as follows. The NAS will detect the response normally with 99% reliability, and the responder will normally detect with 67% reliability.

For any Answer detection reaction not specifically specified according to this need, a process such as, for example, Fast-Busy is as described for the No Answer condition.

Validation of the programmed number

The user can program the telephone number with the first, second and third Find-Me numbers and override routing. Before the number is accepted for programming, the application does the following validation.

Domestic number

Test the Domestic Terms flag (PIN bit 1) to see if the user can program the national number.

Using category 00O, type 002, and programmed NPA to find a pattern match, the international blocking database is queried to ensure that the programmed number is not an information / adult service number.

The Exchange Master is tested to determine if the incoming is a NADP number. If so, country set blocking is allowed. In contrast to the country set found in the directline MCI characteristic record, the pseudo-area code (PCC) associated with the programmed number becomes valid. If the PCC is blocked, programming to that number is not allowed.

International number

Test the International Terms flag (pin bit 2) to see if the user can program an international number.

A Country Set from the Directline MCI Feature Record is retrieved, and the application verifies that the programmed Country Code is blocked for the Country Set. Blocking checks whether the programming guest incoming is included below.

The Call Flow diagram illustrates various situations where transmission to the Voice / Fax Platform (VFP) is required. The transfer is performed by using the routing number in the Voicemail Route Number field of the account record.

In order to "mask" part of the delay in the call expansion to VFP, the call is expanded before the character "wait" is shown to the requestor. In addition, the call extension delay is reduced by eliminating the inter-digit timeout. After sending a call and displaying a character, the application waits for a response detection following a '*', at which time the user's directline MCI access number (800 / 8xx number) is passed to the VFP as a pulse, followed by a '#'. The single mode digit indicates to the VFP the type of conversion to be processed. The mode indicator is one of those values and is shown in the table below. To verify that the information has been received and verified by the VFP, the application waits for two DTMF '00' tones to be displayed from the VFP, and then the requestor connects.

If two handshake attempts fail, the VFP conversion attempt is considered failed. If the guest conversion from voiced, or default, or bypass routing to voice or faxmail fails, the guest requestor will be asked to call again later. If the guest conversion for the guest menu selection fails, the menu will reappear, and if the user conversion to voice or faxmail fails, the text indicating that the user failed will reappear, and the user will return to the previous menu.

When a fax tone is detected early in the request, an uncommented guest fax conversion occurs. Paxton detection is independent of the display of the welcome message, and the length of the greeting does not affect the detection of paxton.

When a user accesses user programming, the application displays the total number of full mailbox messages, new fax messages, and new voicemail messages whenever possible. The application queries this information from the VFP through the VFP_Trans service.

The user can also define whether to notify the pager of new voice and fax messages via DTMF. Pager notification options include voicemail notification, fax notification, voicemail and fax notification, and no notification. The settings for pager notification are stored on the page of the Vmail flag (pin bit 5) and the page of the Fax flag (pin bit 6).

Paging

The option to page subscribers is one of several categories shown in the guest menu. The guest may also be asked to send the page according to the user's programmed override or bypass routing.

When sending a page, the application asks the requester for a callback number. The user's customer record contains the following information used to process the page: a pager indicating the pager number used to send the call to the pager company, the pager pin of the user, and a dial string that can be arranged to exchange page information. type. The dial string provides a timeout value for waiting for a response detection, a delay following the response detection, a number of pin digits into the DTMF, and any incoming character, for example '#'. If the requester disconnects after entering the callback number, the pager is completed and released. The pager types are shown in the following table.

*: The 800-access number will be routed through DAP-looparound on the bridge switch.

The user can enable / disable the presentation of the pager with a guest menu option. When the pager is disabled, nothing appears in the guest menu, and nothing happens to the user in programming overrides or bypass routing. Guest options in voice mail or pager are also removed from the bypass routing programming choice. If override routing is set on the pager and the pager is off, the call is treated as if there were no overrides. If bypass routing is set on the pager and the pager is turned off, the requestor is routed to voicemail, and if the requester has voicemail, a termination message appears. These are the default treatments for overrides and bypass routing. The Pager 0n / 0ff flag (status bit 13) is when the enabled / disabled state of the pager is stored.

In addition to the enable / disable capability of the pager, as mentioned in the voicemail / faxmail portion of this specification, a user may define a pager notification option. VFP uses a pager to notify you of new voice and fax messages and supports the pager types supported by the ISN. The status Pager On / Off flag does not affect pager notification. In order to receive no notification of a new message, the user is required to set the pager notification to No Notification.

Outbound Dialing

The user can make a call to enter the call into his directline MCI account. These options appear in the main user programming menu. Outbound request options include a domestic call that relies on the Domestic Completion flag (status bit 4), an international call that relies on the International Compilations flag (status bit 5), and a programmed Speed Dial call that relies on the Speed Dial Completion flag. (Status bit 6).

For the required international completion, the application looks up the destination country code in the country code table. If the Direct Dial Country flag is set to 'Y' for that country, the ARU sends the call to the manual console (TTC = 9d).

The following confirmation check is made before the call is completed for the subscriber.

Domestic number

The Domestic Compilations flag should be set to 'Y'.

The international blocking database is queried using category 000, type 002, and programmed NPA, looking for pattern matches to ensure that the programmed number is not a blocked information / adult service number.

The Exchange Master is tested to determine if the incoming is a NANP number. If so, the country set blocking is authorized using the country set found in the Titline AuthCode Property record. When calling a subscriber at an international location, retrieve the Country Sets from the source's feature record and from the directline MCI feature record, and the application verifies for which country set the PCC is not blocked. Find the characteristic record at the source by using '191' + 3-digit country code + '0000' as the key to the characteristic record database.

International number

The International Compilations flag should be set to 'Y'.

The Country Set from the directline MCI Property Record is retrieved and the application verifies that the destination country code is not blocked with that code set. For international origins, country sets are retrieved from the source's feature record and from the directline MCI feature record, and the application verifies that the country code of destination is not blocked for which country set.

Blocking checks for call editing of the user based on origination and for programming speed dial numbers are included below.

Redial

The requestor can execute a call and redial to a VFP or phone number by pressing the '#' key for two seconds. The switch verifies that redial is allowed for the call, and if so it will pass the requestor back to the ISN.

The status of the requesting caller is derived from its value in the Val Stat field of the original call's BDR. The table below defines the possible values for the field and the representation of each value.

Moreover, # redial is valid for subscribers, from completion to voicemail / faxmail platforms. This is done with two changes to the data in the switch write (OSR), as mentioned in the Billing section.

*: Not used-Currently, there is no difference between access to voicemail and access to faxmail; Will appear as Val Stat of 201.

Redial Subscriber

Subscriber redial is confirmed by itself via the Val Stat field of the outgoing call and the user programming menu appears. A subscriber who completes the voicemail / faxmail platform or telephone number is allowed to redial.

Console Impact

Corsol effect will be described in detail in the next chapter, especially in the call flow diagram.

ARU transmission

The console is sent from the ARU for the reasons shown in the table. The processing of these transfers is shown in the console call flow diagram.

Access method

Mentioned in the Access Methods section of the ARU Effects section

Direct calling

Mentioned in the direct calling section of the ARU effect, except

Default routing

Default routing has no effect on the console, except when programmed or defaulted to operator transfers. In this case, the call will be treated as a new call with the guest menu displayed.

Voice Mail / Fax Mail

Mentioned in the Voicemail / Faxmail section of the ARU effect

Paging

Mentioned in the Paging section of the ARU effect

Outbound Dialing

As mentioned in the Outbound Dialing section of the ARU effect

Redial

Mentioned in the resend section of the ARU effect

Flag dependencies

Flag dependencies are shown in the following table:

Blocking check

There is no description of the flag check in this specification, but reference is made to the national set, 'Adult Services' 976 and inter-NANP blocking. If necessary, use the default ANI property record for country set blocking.

976 blocking is performed as follows.

By using programmed NPA, category 000, and type 002 to find pattern matches, the international blocking database is queried to ensure that the programmed number is not a blocked international / adult service number. If no match is found, no call / program is performed.

Inter-NANP blocking is performed as follows.

Examine the Exchange Master to determine if the called is a NANP number, and if so, check if the Intra-NANP flag is set to 'Y' and if the condition is met, the intra-country for the calling number. The flag is checked. If the intra-country flag for the calling number is also set to 'Y', the call is blocked. Otherwise the call will be allowed. In short, if the intra-country flag of the calling and called number is both 'Y', the call is blocked, and if either is 'N' the call is allowed.

Country set blocking is performed as follows.

The country set of directline MCI characteristic records, and the originating ANI / region below, are valid against the country code of the called party. If the destination country is blocked in any country set, the call is blocked.

Guest call complete

User call complete

Programming routing

Programming speed dial number

XIX. Internet fax

A. Overview

Most calls in the PSTN are fax calls. The call sends encoded digital information and is modulated for analog transmission to the telephone company's central office (CO). At the main office (CO), analog signals are digitized at 64 Kbps PSTN for continuous transmission. At the called station headquarters (CO), the digital signal is converted to analog and transmitted to the received fax. Due to the continuous transmission of international fax communications, the availability of insufficient transmission performance increases and the cost of international direct dial phone service increases.

B. Details

Currently, there is a growing interest in sending faxes and voice over the Internet. In the past, faxes were perceived as part of the network and did not use inherent intelligence on the Internet. The preferred embodiment clearly routes the fax to the Internet rather than describing the telephone network. With the help of appropriate logic, a network can detect fax calls by detecting the tone of the line. The call is then passed to some other piece of hardware or software that performs faxing on the Internet. The network performs routing by using the telephone number of the called station fax as an address. Then, by accessing the DAP, an appropriate gateway is selected, and the call is routed to the appropriate destination station based on the number. This is accomplished by sending a routing request to the DAP. The DAP selects the destination gateway in one of several ways. The method is specified by the origin point. That is, the lookup table assigns a particular origin point to a particular destination station gateway. Another method is by load balancing technique. Network logic can accurately detect normal telephone network activity and send it to the Internet without affecting its integrity. One embodiment uses a dual dialing scenario similar to current telephone credit cards. The first number is used to indicate how the call was routed, and the second number is used to route the call to the destination address as other telephone calls when the appropriate gateway is identified.

Detailed logic associated with the bypassable routing of faxes on the Internet is achieved by monitoring calls in the trunk group. A company or other organization will generally purchase the capability for a trunk line that can be used exclusively to serve its organization's needs. The trunk group of the preferred embodiment is a hybrid network, for example comprising a digital signal processor (DSP) for converting faxes intended for a predetermined carrier via a data network such as the X.25 network or the Internet instead of a public switched network. It will be embodied in the appropriate detection hardware that can be implemented. Call detection to a specific trunk group is explicitly performed.

The trunk group becomes a bridge switch for diverting calls to the Internet network. The intelligent network detects whether the call is related to a specific area that is targeted for handling a particular route via some other data network or Internet than the PSTN. If the call is not targeted to the code for that particular region, the call is normally routed to the destination via the PSTN.

Lowering the detail one more, when the call reaches the MCI switch, the switch issues a DAP query requesting the root for that call. The DAP interprets the call based on the dialed number and other profile information and routes the call to a fax performed in the detection system. The fax tone detection system pays attention to the fax CNG tones, and if a CHG tone is detected, a second phone call is placed at the fax Internet gateway. When the fax Internet gateway answers, the first and second call are bridged together at the branch switch.

The change required is to block incoming calls by incoming calls. For a predetermined target call, the intelligent network keeps the call for further processing. This is done according to the preferred embodiment shown in FIG. 52B. In the figure, the user's outgoing fax F1 is connected to a telephone line via a switch 5260. The switch 5260 connects the call via switch 5221 and places a routing request to DAP 5262 for querying routing data. The DAP is connected to a routing database, such as a Long Term Regulatory Routing database. The trunk is also connected to the appropriate logic, the Fax Tone Detector (FTD), represented by the symbol 5263. The logic is to route a fax call destined for the predetermined regions of the fax gate 5264 via switches 5221 and 5265 to the bypass data network 5268 from the preset country to the fax gateway 5267. It includes. For countries other than the preset country, switch 5201 will send the call via the PSTN.

Operation of the above embodiment shown in FIG. 52B is shown in the flow chart of FIG. 52C. At step 5270 of the flow chart, outgoing switch 5251 of FIG. 52B receives the call. The call may come from a phone, PC, fax F1, or other suitable device. At step 5271, the DAP is queried via switch 5251 using the incoming information associated with the call. The DAP looks for routing information, and a determination is made at step 5273 as to whether the incoming call is a preset country, city, or other place of interest. If the condition is not met, the call is handled through normal routing in step 5274.

If the call is for a preset call of interest, then routed to FTP at step 5275. FTP then determines in step 5276 whether this call is a fax call. This may be done by an attempt to detect the CNG by well known means. As one way to achieve this, a timer may be used. If a CNG tone is not detected within a certain period, the call is considered not to be a fax call, in which case it is released and bridged through normal routing in the PSTN at step 5277. If a CNG call is detected, the call is released and bridged at the fax gate 5264 at step 5278, and the call is connected so that the fax is sent to the bypass data network 5266 and sent to the fax gate 5267. It is then sent by fax (F2) at the destination.

This can be routed via a domain name that contains multiple countries. The domain name server will distribute multiple calls to multiple destinations via the lookup table. The gateway will be located at the called station and the TCP / IP session will be set up with the gateway for control. The data may be over TCP or UDP based on certain network characteristics. In some cases, dialed digits call the origin gateway, which directs the digits to the dialed destination gateway. Next, the destination gateway dials the called number and makes the fax engage the other side. The system uses two pairs of fax modems that convert telephone signals back into packets. The fax modems negotiate at a baud rate like other modems, but by executing every hour one page is transmitted. Each modem writes its function and negotiates the speed it can support. Firstly, transmission of the fax information is started, an ACK is sent after each page, and finally the baud rate is renegotiated back to 300 baud (LCD). Eventually, the message is received from a remote modem and the packet is packaged back into a fax package. At the end of each page, a renegotiation of the baud rate according to the error rate occurs, and if there are too many errors, the faxes will be renegotiated at a lower rate before resending and / or transmitting the page.

According to a preferred embodiment, the system detects whether the incoming telephone circuit is connected before delivering the fax information. The overhead associated with such processing causes the following losses in the normal fax process.

1) increase of automatic connection delay, and

2) 5% longer by actually sending the fax.

XX. Internet switch technology

A. Examples

The problem with current switch networks is that it is difficult to provide low-cost access when using a local switched carrier (LEC) connected via a legislated characteristic group D trunk. This is because the access fee is defined by the LEC. Therefore, if Internet access is provided through a service using a characteristic group D trunk, the cost to the consumer is excessive. If the characteristic group D trunk is bypassed, a defined network is provided. For example, LEC is connected directly to a pool of modems that access the Internet, and a second problem arises. These problems include scalability, survivability, and design inefficiency. Moreover, a modem may be needed for each of the DSOs purchased from the LEC. All these problems are solved by the arrangements discussed below.

Since the modem pool can be adjusted to meet network call demands, scalability is addressed by the CBLs shown in FIG. 1C. CBLs can be tailored to meet the needs of the particular group of interest. In a dedicated network, a one-to-one relationship exists between CBLs and writes to the modem pool. Therefore, if the modem is not connected, the likelihood of servicing the user is directly determined by the ability to use the modem. By eliminating the direct relationship between modem pools and CBLs, DAP can map calls to dynamic resources obtained through any network where dynamic resources exist. This design is more effective than any current architecture. A detailed description of this architecture follows.

The third problem solved by the preferred embodiment is a direct result of solving the two previous problems. The method of routing the call in the network was only required when the origination was indicated by the LEC. Embodiments relating to the functionality of the hotline solve these problems. If outgoing is detected in an incoming trunk (circuit) where hotline functionality is enabled, the database lookup is performed as an internal process of the routing database of the switch. This database lookup results in a temporary dialing plan (eg, 7 or 10 digits) that is used to temporarily determine the incoming call. The hotline function is present in the switches, but without the call information (ADF transaction) to the DAP, it causes the switch to clarify the DAL procedure request and is not included in the routing capability using the DAP. The request is sent over an X.25 protocol link, a local area network, an Optical Connection Three (OC3), ATM network, frame relay, SMDS, or other communication link to the DAP. The DAP performs an additional database lookup to determine the appropriate destination (in this case, the destination trunk group (TTG) and switch ID (SWID) corresponding to the trunk connection with the modem pool). The hotline is the basis for design that overcomes the above mentioned problems.

FIG. 71 shows a typical customer configuration of a hybrid network for delivering private dialing for on-premises network services, allocation or dedicated access, such as VNET, vision or other media while providing local dial access. The connection of the FDDI LAN 10201, the transaction servers 10205, and the communication servers 10215, 10225 are jointly treated as a DAP. Local Area Networks, such as Fiber Distrubute Data Interface (LDDI) LAN 10201, are used to connect various communication devices. In the connection as shown, transaction server (TS) 10205 is connected to LAN 10201. Telephone switches such as switches 10210 and 10120 are each connected to LAN 10201 through communication server (CS) 10215 and 10225. For example, communication server (CS) 10225 communicates with switches using a protocol called application data field (ADF) 10245. The gateway 10230 is connected to the LAN 10201 and communicates between a Customer Access Processor (CAP). The CAP 10235 is a typical microprocessor such as the Intel Pentium, RISC, or Motorola 68 Series. The DAP also sends transaction queries to the CAP. The CAP performs a database lookup and returns a routing command based on the state, for example, how many operators can work at a particular customer service center. The CAP returns a response indicating how the call is routed based on the database lookup. The DAP basically uses that information as an extension of its own database. The DAP then interprets the information received from the CAP 10235 and translates that information into routing information required by the switch to route the call to where the customer requested. 72 illustrates operation for DAP 10240, shown at 10241, 10242, and 10243. As shown in FIG. Routing and customer profile information is entered into order entry system 10235 after it is confirmed, and the information is routed to Service Control Manager (SCM) 10230. SCM 10320 sends rooting and customer profile information to each DAP of the network.

For example, if a problem occurs with Windows 95, the customer can call 1-800-FIX-WIN95. The call enters the network at the originating switch 10350, which initiates the transaction with the DAP 10241-3, which queries for appropriate routing information. The queried DAP recognizes the number, creates a transaction, and routes it to the appropriate gateway 10230 connected to the appropriate CAP 10235 (in this case, the CAP associated with the Microsoft company). CAP 10235 receives the transaction to determine if the customer service center in New York is busy. However, a customer service center in California is not so busy (in this case, time is counted). The CAP 10235 will send back a response to the queried DAP 1041-3 (via gateway 10230) indicating that this particular 1-800-FIX-WIN95 call should be routed to the California Customer Service Center. The selected DAP 10201-3 transmits the transaction information to a specific terminating trunk group (TTG) and a specific switch ID (SWID) corresponding to a route from the MCI network arriving at the California customer service center. The selected DAP (10241-3) sends this response information to the outgoing switch (10350), which outgoing switch (10350) sends outgoing calls of 1-800-FIX-WIN95, as indicated by the DAP response via the SWID. Route to the correct terminating switch (10351).

Next, the incoming switch 10351 determines the corrected incoming trunk group (TTG) using the information transmitted via the SS7 network generated from the parameters in the original DAP response and routes the call to the California Customer Service Center. . When a call is routed through a switch, it is forwarded to the customer PBX 10387, which forwards the call to the target number 10361 via a direct access line (DAL) connection, such as DAP 10386.

73 illustrates a process of connecting a telephone to a release link trunk for 1-800 call processing. A telephone, such as telephone 10410, is coupled to a local switched carrier (LEC) 10415. A user using the telephone 10410 presses 1-800 using the keypad of the telephone, whereby the LEC 10415 routes the call to the MCI originating switch 10420. In order to process the 1-800 request, switch 10420 must connect with ISN 10480. Therefore, switch 10420 connects the call to bridge switch 10440 connected to intelligent service network 10480 via release link trunk 10490. Bridge switch 10440 forwards the DAP request to ISN 10480 with 1-800 information, which forwards it to addressed DAP 10201. DAP (10241) tests the 1-800 request and selects the appropriate release link trunk (10490) that connects to the MCI D switch (10410) that is alternately connected to the DEC, the LEC ultimately connecting to the telephone (10410). This completes the call. ANI is a standard term used in the industry to mean Automatic Number Identification. ANI can be used to complete a call. This is the information that the MCI network receives from the LEC to identify the call originating. In short, if a user makes a call, the call is the user's home telephone number. It may be a public phone from which the card user originates the call, and is not used solely to determine who will pay for the call.

A similar process may be used to connect telephone 10450 via LEC 10455 to switch 10460 using bridge switch 10440 to bridge the call to release link trunk 10490 via ISN 10480. have.

74 illustrates a client side requesting a DAP process. In a home or small office environment, devices such as modem 10510, telephone 10513, and fax 10510 are plugged into a standard RJ11 jack 10520 that connects to a local switched carrier. Local exchange carrier 10525 connects to switch 10530 via common office line 10527. In a large office environment, an office equipped with a PBX 10540 may be connected to the switch 10530 via a dedicated access line (DAL) 10547 without involving a local carrier. The switch 10530 issues a DAL procedure request to the DAP 10560, as shown in detail in FIG. 75, and the DAP 10560 selects routing 10570 for the call.

75 illustrates the operation of switch 10530 to select a "hotline" or specific number for the requestor. The switch 10530 accepts the incoming call from the CBL 10527 or the DAL 10547 and connects to the DAP 10560 for information to route the call. DAP 10560 returns routing information encoded in the form of a pseudo-phone number. The pseudo-phone number looks like a normal phone number but encodes a file number and a 3-digit switch identifier (SWID) in a file that identifies the desired destination trunk group (TTG). The switch 10530 is connected to the switch 10610 identified by the SWID and carries the file number. The switch 10610 selects the appropriate modem pool 10620 to complete the connection using the TTG. The modem pool alternately connects an Internet Protocol (IP) connection 10630 to services such as authentication service 10640 and a basic Internet Protocol platform (BIPP) 10650. The BIPP 10650 is composed of packet switches, such as ATM switches, to forward IP packets from one node to another. The authentication service 10640 selectively performs a security function for authenticating the requesting side and prevents unauthorized access on the Internet. It may also be used to clarify the charges needed to ensure proper coordination for users accessing the Internet through the TTG hotline. This hotline facility allows for routing calls through switches 10530 and 10610 without using expensive FGDs such as FGD 10380 shown in FIG.

76 illustrates the operation of a gate to selectively route phone numbers over the Internet. The terminal switch 10710 is connected to the ARU 10720 to request routing information. The ARU 10720 queries the characteristics of the call to determine if the call is a candidate for internet routing. If the call is a modem call, the call is routed to modem pool 10730. From modem pool 10730, the call may be routed to Basic Internet Protocol Platform 10750 to provide Internet access to the modem call. The modem call is optionally authenticated by the authentication service 10760. If the call is a fax call, the call is routed to popdem pool 10730. From modem pool 10730, the call can be routed to Basic Internet Protocol platform 10750 and from there to the fax gate 10770. Like the modem call, the fax call is optionally authenticated by the authentication service 10760. If the call being routed is a voice call, the ARU 10720 waits for the user to dial the call card number and the called phone number. The ARU 10720 queries the called number to determine whether the incoming call is an international call or a domestic call. The domestic call is returned to the terminating switch 10710 for equivalent routing. The international call is encoded as data by supplying an analog voice signal to the coder / decoder (or codec) 10725. Codec 10725 has a signal encoded as digital data and routes the call through the modem pool 10730 to the Basic Internet Protocol Platform 10750.

In another embodiment, when a call is delivered to an ISN by a network switch, the SS7 ISUP message is routed to the resident ISN switch, which is called a DMS-ACD. Here, ACD is an Auto Call Distributor. The ACD receives the incoming SS7 ISUP message and switches to SCAI (Switch / Computer Application Interface). On the other side of the ACD is a device called an Intelligent Service Network-Adjunct processor (ISN-AP). SCAI is the language used between ACD and ISN-AP. Therefore, there are two interfaces inbound from the network to the ACD SS7 ISUP and outbound from the ACD to the ISN-AP SCAI.

When a call reaches the ACD from the network, the ACD does not automatically know where to route the call. The ACD receives its information from the ISN-AP. To this end, the ACD takes the ISUP signaling parameters from the network, converts them into the SCAI protocol format, and sends a SCAI message to the ISN-AP.

Specifically, the SCAI message is called 'DV_Call_Received' (DV stands for Data / Voice). When ISN_AP receives this message, it is a Called Party Number field inside the SCAI message. Based on that number, it determines where the ACD routes calls within the ISN. When the ISN-AP makes a decision, the ISN-AP makes a DV_Call_Received_RR (the response from the previous message DV_Call_Received_RR means a return result). The RR message is the command of the ACD internally to the ACD port for which call should be received.

For this service, the ACD is instructed to receive a call to an ACD port connected to the ARU 10720. When the call arrives at ARU 10720, two things happen:

1) If the requester has dialed an access number from a) a telephone or b) a fax machine, the requester will hear a voice prompt saying "Press 1 for Voice and 2 for Fax."

2) If you have dialed the access number using a PC modem, the requester will probably not hear any comments. The next thing to happen is that the ARU timer expires. The end of the timer informs the ARU that the call is from a modem.

Calls deployed in such a scenario can be confusing, so consider the following one at a time:

If the requester made a call to the telephone, at the ARU 10720 voice prompt, the requester would press '1' (for voice service). At that time, the ARU 10720 will get more information about the requestor. This feature is a variation of the calling card service provided by telephone companies today. The ARU 10720 first collects the card numbers, and then collects the numbers that the requester wants to receive. After gathering this information, the ARU 10720 sends the data to the authentication database via a communication network (LAN) on an ISN basis. Moreover, to verify the phone card number, the database ensures that the called number is within the dialing plan allowed for the card holder.

Once the card information is authenticated, the ARU 10720 will determine whether the termination number is domestic or international. If the called number is domestic, the ARU 10720 will release the call from the ISN to the voice network, where the call will be routed to the intended call. If the called number is international, the call will be routed to the codec of the BIPP site. The purpose of the codec is to convert the voice signal into data and route it to the Internet using UDP / IP.

In another embodiment, if the requester made a call from the fax machine at the ARU 10720 voice prompt, the requester would press 2 indicating a request for a fax service. At that time, the ARU 10720 will route to a fax platform, which is a guaranteed fax service 10770 for those who cannot wait until an incoming fax number becomes available or need help in delivering an international fax. One embodiment gathers information about the requestor and called number, informing the requestor that the transmission operation has begun. The fax service 10770 collects the faxes and stores them for later delivery.

If the requester has dialed with a PC modem, at the ARU 10720 voice prompt, the requester will not hear any comments. This is intentional. It is possible for the requester to listen to the ARU 10720 through a PC speaker or modem. However, the requestor cannot register with the ARU 10720 and will eventually time-out indicating that this call originated from the PC modem (as mentioned above). The ARU 10720 will release the callback to the network for incoming to the modem pool 10730 at one of the MCI's BIPP 10750 sites.

FIG. 77 illustrates operation of the ARU of FIG. 76 arranged in a centralized structure. Telephone 10810 communicates with switch 10710 via local exchange 10820. The switch 10710 connects the intelligent service network (ISN) 10840 ARU 10720 through the bridge switch 10830. The ARU 10720 coordinates the call routing to the BIPP 10750 or fax server via the modem pool 10730 or codec 10825.

FIG. 78 illustrates operation of the ARU of FIG. 77 arranged in a distributed structure. Telephone 10910 communicates with switch 10710 via local exchange 10920. The switch 10710 connects the intelligent service network 10840 ARU 10720 through the bridge switch 10730. The ARU 10720 operates under the control of the voice response unit 10950 connected to the switch 10111 and the bridge switch 10930 to control a call to the modem pool 10730 or the codec that passes through the switch 10110. . The ARU must be located inside the ISN, but other devices (eg, ARU 10850, 10950, modem pool 10730, and codec 10725) may be located anywhere in the network.

79A and 97B illustrate the operation of a sample application for Internet call routing. 79A shows a sample application for customer service. Intranet computer 11010 connects to server computer 11025 by connecting to the Internet 11020 described above. The server computer 11025 allows an intranet computer 11010 user to query the provider 11030 via a single resource locator via designation of an internet resource such as a Packing Shipping Server Provider 11030. . Through an internal function shown as 11032, the supplier 11030 provides resources such as a full motion image display 11035 from a customer service department in response to a user conversation, or provides an interactive conversation to a customer service representative 11037. do.

79B illustrates various applications for a caller-initiated consumer transaction. A customer calling a preset number 11040 (555-IMCI, 555-PAGE, or 555-RNET) can be routed to a particular transaction processor by using a common office line (CBL) 1150. CBL 11050 is connected to a switch 11060. Switch 11060 calls DAP 11065 which analyzes an incoming call that uses automatic number identification (ANI) to determine requestor identification. Based on the requestor identification along with the requested number, DAP 11065 designates switch 11060 to direct the call to a 555-IMCI, such as, for example, a data network interface (DNI) 11070. The DNI 11070 acts as an interface between the switch network and the database host 11075 capable of handling point-of-sale books and credit card transactions. In addition to routing the call based on the target phone number, ANI data is used by the requester to identify the database host 11075. Similarly, the 555-PAGE call may be routed to the PBX of the paging service company 11080, where the ANI data is used to select a particular paging service 11085 provided by the company. In turn, the 555-RNET call can be used to provide connectivity of the underlying Internet protocol platform 11090 as described above.

80 illustrates a configuration of a switching network that provides voice mail and voice responder services as well as interconnection to a service provider according to a preferred embodiment. Telephones 11111 and 11112 enter the network via switches 11120 and 11121, respectively, and in addition to providing network entry to telephones 11112, switch 11121 provides an intermediate line for switch 11120. to provide. The switch 11125 not only receives a direct input such as the PBX 11130 but also is interconnected with the switch 11121. The switch 11125 connects the voice response server 11140 and the voice mail server 11145. In addition, the switch 11125 connects the service provider server 11150 via the dial access line 11155. Moreover, service provider server 11150 routes incoming calls to email service 11070 using BIPP 11075 that is connected through paging service 11060 or modem pool 11076 in accordance with the required service and authentication. .

B. Other Examples

FIG. 81 illustrates inbound sharing Automated Call Distributed (ACD) calls with data sharing through a database according to a preferred embodiment. Internet user 12000 using a telephone line dials a telephone number using a computer modem. The telephone number is routed from RBOC / LEC switch 12002 to MCI switch 1 12004. MCI switch 1 12004 queries Network Control System (NCS) 12020 to request a dialed telephone number and route for a given ANI. NCS 12020 returns a destination address that directs MCI switch 1 12004 to route the call to the trunk group of MCI switch 2 12006.

MCI switch 2 12006 completes the call to Internet access device 12008. The modems of the dial-up user computer 12000 and the Internet access device 12008 initiate data gathering, and data packets are exchanged according to point-to-point prototyping (PPP). From the Internet Access Device 12008, the PPP packet is converted to Internet Prototyping (IP) and transmitted in the form of 12026 over the Internet. Similarly, Internet access device 12008 receives an IP packet from Internet 12026 and sends it to dial-up user 12000.

Dial-up user 12000 is authenticated before the packet is allowed to pass freely through Internet access element 12008. This is done using the username / password method or the challenge / response method.

In the username / password method, Internet access device 12008 prompts the dial-up user to connect with the username. The dial up user 12000 enters a user name into the computer, and the user name is transmitted from the dial up user 12000 to the device 12008. Internet access device 12008 then prompts dial-up user 12000 to access the password. Dial-up user 12000 enters a password into the computer, and the password is transmitted from dial-up user 12000 to Internet access device 12008. Once the username and password are received, the Internet access device 12008 sends a confirmation request including the username and password to the verification server 12014. Validation server 12014 checks the username and password against a database of valid username / password pairs. If the username / password entered is in the database, the verification server 12014 sends a "user confirmation" message back to the Internet access device 12014. If the username / password entered does not exist in the database, the verification server 12014 sends a "no user verification" message back to the Internet access device 12008.

In the challenge / response method, the Internet access device 12008 prompts the dial-up user 12000 to enter a username. Dial-up user 12000 enters a user name into the computer, and the user name is transferred from dial-up user 12000 to Internet access device 12008. Internet access device 12008 then prompts dial-up user 12000 in an attempt. The dial-up user 12000 calculates the response to the attempt by entering a DIGITS and entering the secret key into the response generating program.

The shared secret is known only to dial-up user 12000 and verification server 12014. Dial-up user 12000 enters the calculated response and the response is transmitted from dial-up user 12000 to Internet access device 12008. Internet access device 12008 sends a confirmation message to the verification server 12014, including the username, challenge and response. The verification server reads the username, finds the shared secret key for the username, and uses the shared secret key and the challenge digit to compute the response. The calculated response is compared with the response given by the dial up user 12000. If the response matches, the message "User Verified" is sent to the confirmation server from 12014 to Internet Access Device 12008. If the response does not match, the message "User not confirmed" is sent to the confirmation server from 12014 to Internet Access Device 12008.

If a username / password or challenge / response method is used for verification, the remainder of this description is the message "User Verified" is sent to the verification server from 12014 to Internet Access Device 12008 and IP packet communication passes through Internet Access Device 12008. Assume that it can flow freely.

Dial-up user 12000 starts a web browser and browsers a web page from integrated web server 12024. The integrated web server 12024 records the web pages searched by the dial-up user 12000 on the call center server 12028 using the uniform searcher. Dial-up user 12000 delivers the information to the integrated web server 12024 by filing a hypertext markup language (HTML) form. The integrated web server 12024 stores this information on the call center server using the same uniform searcher.

Dial-up user 12000 browsers another web page, and an icon is displayed according to the textual display so that the user can talk to the agent by clocking the icon. The icon's clock brings multiple Internet Mail Extensions (MIME) downloads from the integrated web server 12024 to the dial-up user's 12000 web browser. The MIME file contains an alphanumeric string called a user identifier, indicating the destination for the resulting phone call. The browser drives the application of browser plug-ins or helpers to handle files of the specified MIME type. The helper application reads the MIME file and applies a question mark to the MIME file contents from dialup user 12000 to Directory Server 12012. Directory Server 12012 translates the alphanumeric string from the MIME file into the destination IP address of the destination Internet Telephony Gateway 12018 and sends a message containing the IP address to the dial-up user's 12000 helper application. The helper application then authorizes Internet telephony calls to the 12018 IP address of the Internet Telephony Gateway and provides Alphanumeric strings from the MIME file to the Internet Telephony Gateway 12018 as part of the call setup.

Internet Telephony Gateway 12018 translates the given alphanumeric string to the destination telephone number and dials the destination telephone number of the telephone network interface to MCI switch 12006. MCI switch 2 12006 asks NCS 12020 for the dialed number, requesting performance instructions. The NCS 12020 determines the appropriate route and sends a performance instruction back to MCI switch 1 12006 to place the call on a particular trunk group of MCI switch 1 12004. The call is tracked to 12004, MCI switch 1, and the call is then completed on an automatic call splitter (ACD) 12022. When the ACD 122 answers the call, the Internet Telephony Gateway 12O18 completes a certain audio route between the ACD 12022 and the dial-up user 120OO, with the Internet telephony gateway circuit-switched from the ACD to PCM audio and dialing up from the Internet telephony gate. Audio up to is encoded into digital audio using an audio code and packetized.

When a call is delivered to ACD 12022, the unique record identifier is delivered to the ACD via the telephone network signal mechanism. When the agent of call center 12O26 receives a call, the unique record identifier is displayed for the agent, and the call information connected by dial-up user 12000 is retrieved from call center server 12028.

XXL. Billing

Other implementations in accordance with the present invention generally relate to telecommunications networks, in particular those of telecommunications networks that generate a call record using a flexible and scalable recording format and generate a unique call identifier for each telephony call passing through the network. It is about a switch.

A typical telecommunications network consists of multiple telecommunications switches located through geopolitical domains. When a user makes a call, the call is made through one or more switches before reaching the destination.

FIG 82 describes an example communication system passing through the United States. For illustrative purposes, caller 30124 makes a call from Los Angeles, California, to an area located in New York City. Such calls are typically transmitted through three switches. Los Angeles, Switch 30106 Chicago, Switch 30108 New York, Switch 30110 In this scenario, the start switch is Los Angeles 30106 and the end switch is New York Switch 30110.

Each switch, 30106-30110, is connected to two or more data access points (DAPs) 30116-30120 DP. For example, initial DAP 30116 and backup DAP 30116-30120. The DAP 30116-30120 receives the information request from the switch 30106-30110 and returns the requested information back to the request switch 30106-30110. Switch 30106-30110 uses information from DAP 30116-30120 to handle calls over the network.

When a call passes through one of the switches 30106-30110, the switch generates a call record. The call log has call information including routing, billing, call characteristics, and troubleshooting information. After the call ends, each switch that handles the call 30106-30110 completes the associated call record. Switch 30106-30110 combines multiple call records into a billing block.

When switch 30106-30110 fills the billing block, switch 30106-30110 sends the billing block to the billing center. Thus, billing center 30114 receives one billing block from each switch 30106-30110 that handles the call, in this case three billing blocks. Billing center 30114 searches each billing block and retrieves the call log associated with the call to retrieve one call log per switch 30106-30110 handling the call. Billing center 30114 then uses one or more of the retrieved call records to establish a billing connection. Billing center 30114 is also connected to each DAP to retrieve switch 30106-30110 or call log information.

In order to better understand the present invention, it is beneficial to describe additional terms related to the communication network.

The call comes with a switch on the transmission line referred to as the start port or trunk. This port group is the starting port group. The start port is one of many transmission lines coming from the home position to the switch. After processing the incoming call, the switch sends the call to the destination, which is either another switch, a local exchange carrier, or an individual branch exchange. The call is sent to the transmission line referenced by the end port or trunk. Similar to the start port, the end port is one of a group of ports from the switch to the same destination. This port group is a terminating port group.

Modern telecommunications networks provide customers with facilities that use the public network, as well as facilities that define a customer real network (VNet). As a VNet, customers define individual dialing plans and plan phone numbers. Vnet customers can define customer telephone numbers without being limited to missing telephone numbers assigned to public telecommunication systems devoted to specific regions.

In handling a telephone call, the switch should generate a call record of sufficient size to contain all the necessary information on the call. However, the call log should not be too large so that the majority of the record fields are not in the call log where the normal call is not used. In such a case storing such call records wastes the storage and sends the call log causing unnecessary transmission.

One solution to creating and processing call logs is to apply a fixed length call record format, such as a 32 word call record. One word is 2 bytes or 16 bits. However, fixed-length recording formats cannot be expanded when new currency features are added. More importantly, fixed call record formats cannot handle extended data fields as communication networks become more complex with new features and phone numbers.

Modern fixed-length recording formats include a time field, which records the local time at three second intervals, and the local switch time represents the day of the day on the switch.

Time fields are used by network switches, billing centers, and other network subsystems. However, each subsystem requires a different use, such as the age of the format, and a different time interval for the format. Era time is a number that increases by one second after a specific day and time in history. For example, billing centers require era times for records to be borrowed, and switch reports and error logs require local switch times.

Problems arise when using local switch times without consideration of time variations due to things like summer time. In addition, each subsystem requires more precise details than the current three second increase. By providing only local switch time in 3 second increments, the switches have taken the burden of translating the time into the format used by the network subsystem. Fixed recording formats cannot meet the requirements of multiple time intervals because they include time intervals at low accuracy local switch times. Due to its fixed nature, the fixed recording format cannot be extended to include other time formats or details of accuracy such as 1 second increments.

Therefore, there is a need for a switch in a communication network that stores call log information in a flexible and extensible format. There is a further need to provide time points with 1 second units in a flexible format that easily respond to daylight savings or time zone changes.

In addition, it is necessary to be able to correspond to all the call records related to a particular telephone call. For example, for proper billing and cost control, the billing center needs to match the start switch call record to the end switch call record. It is also necessary to track telephone calls over the network for problem solving and secrecy purposes, to easily block problem areas. Therefore, it is necessary to identify a switch in the communication network that uniformly identifies each telephone call passing through the network and all call records associated with a particular telephone call.

A. Implementation

1. Call record format

This implementation solves the problem of providing a flexible and scalable call recording format by implementing a small and large call recording format. In particular, this implementation implements a default 32 word call record format and an extended 64 word call record.

This implementation uses a 32-word call record for a typical telephone call that makes up the majority of the call and uses a 64-word call record format when additional information about the call is needed. This implementation provides the flexibility needed to operate efficiently by changing the data needs of a given call log.

This implementation also records the time point of the era time format. This implementation records the origin time of the era time format and the remaining time points are offset or number of seconds from the origin time. This implementation solves the problem of converting from or to daylight saving time, because daylight saving time is a local time set and does not affect the era time. Moreover, time points in the Era format require less space in the call log than the local switch time format.

The era time format represents the coordinated world time (UTC) determined in Greenwich, England, which has a time zone of zero local switch time or another time. Era time is only one format and does not indicate that UTC must be used. The billing time and local switch time are UTC or local time, and the local switch time does not have to be the same time used for billing. Therefore, the switch keeps the billing time separate from the local switch time to prevent problems during daylight savings time changes.

2. Network call identifier

This implementation solves the problem of uniquely identifying all call logs and each phone number associated with a particular phone number by providing a unique identifier for each call record. Generate a network call identifier assigned to each call record at the call origin. That is, the one switch generates an NCID for each telephone number. The NCID carries the relevant telephone number through the communication network at the end point at the end switch. Therefore, at some point in the telephone call in the network, the associated NCID identifies the origin and time of the telephone call. Each switch the telephone call passes through records the NCID in the call log associated with the call. NCID is small enough to fit into a 32-word call log, reducing data production and storage. NCID provides billing centers and other network subsystems that allow you to start and end call recording for specific phone numbers.

The implementation also provides a switch to discard the received NCID and generate a new NCID. If the NCID format is not valid or unreliable, the received NCID is discarded to ensure that a valid unique identifier is associated with each call going through the network. For example, NCID is unreliable when generated by a third switch.

This implementation relates to a switch in a transmission network that generates call recordings using a flexible and extensible recording format. Call recording formats include small (32 words) and large (64 words) extended formats. It is clear to those skilled in the art to implement small and large recording formats of different sizes.

This implementation also relates to a switch in the sending network that generates a unique NCID for each telephone call passing through the network. NCID provides a mechanism to match all call records related to a particular phone call. It is clear to those skilled in the art that different types of call recorders are implemented.

The selected implementation is computer software running within a computer system. FIG 83 shows an example of a computer system. Computer system 30202 has one or more processors, such as processor 30204. The processor 30204 is connected to the communication bus 30206.

Computer system 30202 also includes main memory 30208, RAM, secondary memory 30210. For example, secondary memory 30210 may represent a floppy disk drive, a magnetic tape drive, a compact disk drive and include a hard disk drive 30212 and / or a removable storage drive 30214. The removable storage drive 30214 can read and write to and from the removable storage unit 30216 in well-known ways. The removable storage unit 30216 is also called a program storage device or computer program product and represents a floppy disk, magnetic tape, compact disk, and the like. The removable storage unit 30216 includes a computer-used storage medium having stored computer software and / or data.

Computer programs (also called computer control logic) are stored in main memory 30208 and / or secondary memory 30210. Such computer programs, when executed, drive computer system 30202 to perform the functions of the present invention. In particular, the computer program, when executed, drives processor 30204 to perform the functions of the present invention. Thus, such a computer program represents a regulator of computer system 30202.

B. [Other Implementations]

Another implementation is a computer program medium consisting of a computer reading medium on which coordination logic (computer software) is stored. The coordination logic causes the processor 30204 to perform the functions as described herein when performed by the processor 30204.

Another implementation is initially applied in hardware using a hardware state machine. The application of hardware state machines is obvious to the expert in the relevant field.

1. Call record format

This implementation provides a switch of a transmission network having nine different recording formats. These records include the following: : Call Detail Record (CDR), Extended Call Detail Record (EDCR), Private Network Record (PNR), Extended Private Network Record (EPNR), Operator Service Record (OSR), Extended Operator Service Record (EOSR), Private Operator Service Record (POSR), Extended Private Operator Service Record (EPOSR), Switch Event Record (SER), each record is 32 words in length and the extended version is 64 words.

An example of the nine call record formats described herein is shown in FIG. 82-86. The implementation of the call log of the present invention consists of 32 and 64 word call record formats. It is easy for experts in the related field to create different implementations of currency records that consist of different numbers of words and different field definitions. The accompanying table 301 contains an example of CDR and PNR call recording formats. FIG84 shows a graphical representation of the CDR and PNR call record formats. The accompanying table 302 contains examples of EDCR and EPNR call recording formats. FIG. 85A and 85B show graphical representations of call record formats of EDCR and EPNR. Attached table 303 shows an example of OSR and POSR call recording formats. FIG 86 shows a graphical representation of the OSR and POSR call log formats. The attached table 304 contains examples of EOSR and EPOSR call record formats. FIG 87 (A) and 87 (B) show graphical representations of the EOSR and EPOSR call recording formats. Attached table 305 contains an example of the SER recording format. FIG 88 shows a graphical representation of the SER recording format.

CDR, PNR, EDCR and EPNR are standard call record formats and contain information regarding typical phone calls as they pass through the switch. CDRs are used for customers, not VNETs, and PNRs are used for VNET customers, resulting in switches that originate VNET calls. These two recording fields are identical except for some field specific information described below.

OSR, POSR, EOSR and EPOSR occur in a switch or system that contains information related to the telephone call requiring operator assistance and is actually equipped at the operator's location. The switch performs OSR for non-VNET customers and POSR for private VNET customers. These records occur in a system or switch having a network audio system (NARS) function or a function of performing an operator service. The two recording formats are identical except for the field specific information described below.

The SER is preserved at the end of each billing block, time change, events such as system receivers, and billing block. The SER recording format is also described in detail below.

FIG 89 (A) and (B) collectively describe the logic used by the switch to determine when to use the extended format of the recording format. Call 30202 comes to switch 30106-30110 (referred to as current switch for reference only: current switch is the switch that currently handles the call), and switch 30106-30110 is a call log and call log format (small / Default or large / extension). From this point of view, switch 30106-30110 checks nine times for each incoming call 30802. Switch 30106-30110 uses extended records for calls 30802 that pass any combination of checks as well as calls 30802 that pass any combination of checks. .

First check 30804 determines whether the call is currently associated with a direct end overflow (DTO) at switch 30106-30110. For example, a DTO occurs when a customer calls 30802 on the 30800 number and the home location of the 800 number is busy. If the home location is busy, telephone call 30802 will overflow to the new location.

In this case, the switch should record the original attempted destination, the final destination of the telephone call 30802, and the number of overflows. Therefore, if the call 30802 is included in the DTO, the switches 30106-30110 must complete extended recording (EDCR, EPNR, EOSR, EPOSR) 30816.

A second check 30806 is call 30802 by switch 30106-30110 determining whether the call ring area of call 30802 is greater than 10 digits. The call ring position is the charge number of the position from where the call 30802 is located. An example is an international currency consisting of the last 11 digits. If the call ring position is greater than 10 digits, the switch records the telephone ring number of the call ring position in the extended record (EDCR, EPNR, EOSR, EPOSR) 30816.

Switches 30106-30110 make a third check 30808 with call 30802 to determine if the designated address is greater than 17 digits. The designated address is a call location number and becomes a telephone number or a trunk group. If the designation is greater than 17 digits, the switch writes the designation to extended recording (EDCR, EPNR, EOSR, EPOSR) 30816.

Switches 30106-30110 perform a fourth check on call 30802 to determine if a pre-translated digit field is used for the driven supported service call. The translated digit is the call 30802 number dialed by the talker if call 30202 has to be translated to another number in the network. Therefore, when the talker uses the operator service, the switch 30106-30110 records the number dialed in the extended recording (EOSR, EPOSR) 30816. At the fifth 30812 of call 30802, switch 30106-30110 determines if the pre-translated digits of call 30802 that were placed by the caller without operator assistance have more than 10 digits. With more than 10 digits, the switches 30106-30110 record the number dialed in the extended recording (EDCR, EPNR).

In the sixth check 308 14 of call 30802, switches 30106-30110 determine whether more than 22 digits, including additional data, are recorded in the confirmation code field of the call log. The confirmation code indicates the person to be charged for the call, such as the call ring area or credit card call. If the data input requires more than 22 digits, the switches 30106-30110 record the fare information from the extended records (EDCR, EPNR, EOSR, EPOSR) 30616.

In the seventh check at call 30802, switches 30106-30110 determine whether call 30802 is a wideband call. Wideband calls require multiple transmission lines or channels. For example, a typical video call requires six transport channels, one for voice and one for video transmission. More transport channels used during wideband calls result in better reception. Currently, the simultaneous transmission system provides up to 24 channels. Therefore, the switch records channel information in Extended Record (ECDR, EPNR) 30828 to indicate which and how many of the 24 channels are used during wideband calls.

In the eighth check 30822 of call 30802, switches 30106-30110 determine whether the time and charging characteristics were used by the operator. Time and charge characteristics are commonly used when hotel guests call with the help of an operator and charge 30802. Once call 30802 is completed, the operator will charge a fee and a fee for call 30802 to the guest. If time and charge characteristics were used for call 30802, switch 30106-30110 records the guest's name and room number in extended record (EOSR, EPOSR) 30832.

The ninth final check of call 30802 by switch 30106-30110 determines if call 30802 is an enhanced voice service network audio answering system (EVS / NARS). EVS / NARS is a voice menu system selected by the customer according to the automatic menu via the user's telephone keypad. Such a system includes a NARS switch with an audio menu system. Therefore, during an EVS / NARS call, the NARS switches 30106-30110 record the menu selection of extended records (EOSR, EPOSR) 30832.

If none of the checks 30804-30824 is the desired result, then the switch 30106-30110 uses the default recording format (OSR, POSR) 30830. Once the check is through, the switch generates and completes the appropriate call log. Call log data is recorded in binary form and in telephone binary code decimal (TBCD) format. The TBCD format is described below.

0000 = TBCD-Null

0001 = digit 1

0010 = digit 2

0011 = digit 3

0100 = digit 4

0101 = digit 5

0110 = digit 6

0111 = digit 7

1000 = digit 8

1001 = digit 9

1O11 = special digit 1 (DTMF digit A)

1100 = special digit 2 (DTMF digit B)

1101 = special digit 3 (DTMF digit C)

1110 = special digit 4 (DTMF digit D)

1111 = special digit 5 (Not Used)

All digit fields must be filled with TBCD-null or 0 before data is recorded. When applied, the dialed digit format follows this appointment.

N = digits 2-9

X = digits 0-9

Y = digits 2-8

Therefore, if you include N in the detail for a currency record field, the valid field value is digits 2-9.

Except for SER, each call record contains a specific call time field. The time field is recorded in the era time format. Era time is the second increment from a specific date / time in history. Implementations of the present invention use midnight (UTC 0:00) day / time on January 1, 1976, but this is one example and not limitation. It is easy to apply a different date / time to the expert concerned. Timepoint 1 in the record represents the era time, which is the original time of call 30802. The other timepoint stored in the record is the second number from timepoint 1, the offset value from timepoint 1 at which the specific time point occurred. All other time points must be filled with zeros before any data is recorded. Therefore, if a time point occurs, count one or more. Additionally, a timepoint counter that does not include timepoint 1 does not roll over its value but stays at the maximum count when the time exceeds the threshold.

The switch clock represents the local switch time and is used for all time except billing. Billing information is recorded at the time of day, and this implementation is UTC. The time offset is a value that reflects the switch time relative to UTC and, where applicable, is the daylight savings time offset or time zone offset. There are three factors to consider when evaluating time changes in relation to UTC. First, there are time domains on both sides of UTC, so there are negative and positive offsets. Second, the time domain offset counts from zero (Greenwich, England) in the east until the international date line is reached. In the dateline, the date changes until the next day by counting down until the offset is positive and zero offset is reached for Greenwich. Third, there are regions that have a time domain that is not exactly an hour increase. Australia, for example, has a time zone with 30 minutes difference from both sides of the time zone, while North India has a time zone with 15 minutes difference. Therefore, the time offset of the call record accounts for the positive and negative offset changes in 15 minute increments. Implementations of the present invention satisfy this requirement by providing a time offset that represents a positive or negative one minute increase.

There are two formulas for converting local switch time back to era time.

i) Era Time + (Sine Bit * Time Offset) = Local Switch Time

ii) Local switch time-(Sine bit * time offset) = Era time

The switch records the time offset in the SER using a value equal to 1 minute and calculates it in seconds and adds this value to each local time point 1 before the call is recorded. For example, the central standard time is 6 hours before UTC. In this case the sine bit would indicate 1 for the negative offset and the time offset value recorded in the SER would be 360 (6 hours * 60 minutes / hour = 360 minutes). See FIG 86 for more details on the SER recording format. When recording time point 1 in the call record, the switch is 60 seconds in 1 minute increments.

Multiply the time offset by 60 and check the sine bit to determine whether the offset is positive or negative. This example has a value of -21,600 (-1 * 360 minutes * 60 seconds / minute = -21,600). Using the above formula (ii), if the local switch time is midnight, for example, the corresponding time is 1,200,000,000. Subtracting the time offset of -21,600, it is a corrected era time of 1,200,021,600 seconds, which is six hours after midnight the day after the era time. This implementation works equally well for a switch located east of Greenwich where the time offset is positive. Two commands are used to change the time. First, FIG 90 describes adjusting the flow of the change time command 30900 to change the local switch time and time offset. In FIG 90, after the switch operator inputs the change time command, the switch enters step 30902 to prompt the switch operator for time offset and local switch time from UTC. In step 30902 the switch operator enters a new local switch time and time offset. Subsequent to step 30904, the new time and time offset are displayed again in the switch operator. Following step 30906, the switch operator verifies the entered time and time offset before the actual time and offset changes to the switch. In step 30906 the switch operator confirms the change and the switch proceeds to step 30908 to generate an SER with event qualifiers that match both the local switch time and the time offset of the switch. Billing centers use SER for bill handling. The switch proceeds to step 30910 to discharge the command. If returning to step 30906 and the switch operator does not confirm the change, the switch proceeds to step 30110 to issue a command without updating the local switch time and time offset. See FIG 86 for more details on SER.

FIG. 91 illustrates a flow of adjustment of the change daylight saving time command 31000, which is a second command to change time. In FIG 91, after the switch operator enters the change daylight saving time command, the switch enters step 31002 and prompts the switch operator to select a forward or backward time change. Subsequent to step 31004, the switch operator makes a selection. If the switch operator makes a forward selection in step 31004, the switch goes to step 31006. In step 31006 the local switch time is set to one hour, and one hour (60 counts) is added to the time offset. The switch then proceeds to step 31010. Returning to step 31004, when the switch operator selects back, the switch sets the local switch time back one hour and subtracts one hour from the time offset. The switch then proceeds to step 31010.

In step 31010 the switch operator must confirm the forward or backward selection and the new local switch time and time offset before the actual time changes. In step 31010, if the switch operator confirms the new time and time offset, the switch proceeds to step 31012 to generate an SER with an event qualifier corresponding to 9 that changes the switch's offset and the local switch time. The switch proceeds to step 30104 to issue the command. If returning to step 31010 and the switch operator does not confirm the change, the switch proceeds to step 31014 to issue an instruction without updating the local switch time and time offset.

After successful completion of the change daylight savings time instruction, the billing record is affected by the new time offset. This implementation allows the era time used as billing time to increase normally through the course of daylight saving time and is not affected by local switch time and time offsets.

2. Network call identifier

Every implementation provides a unique NCID that is assigned to each telephone call that travels through the communication network. NCID is thus a distinguished identifier among all network calls. The NCID is recorded and transmitted on each switch involved in the telephone call.

The telephone call generation switch generates an NCID. The selected implementation of the NCID of the present invention is an 82-bit identifier consisting of the following subfields.

i) Source Switch ID (14-bit): This field indicates the NCS switch ID defined in Office Engineering for each switch. However, the SER call record contains an alphanumeric representation of the Switch ID. Thus, the switch uses the alphanumeric switch ID as an index into the database to receive the corresponding NCS switch ID.

ii) Source trunk group (14 bits): This field indicates the source trunk group defined in the 32/64 word call record format described above.

ii) Source port number (19 bits): This field indicates the source port number defined in the 32/64 word call record format described above.

iii) Timepoint 1 (32-bit): This field indicates the timepoint 1 value defined in the 32/64 word call record format described above.

iv) Consecutive Numbers (3 bits): This field indicates the number of calls originating from the same port number with the same timepoint (second) value. The first telephone call will have a consecutive number set to zero. This value increments each successive digit that occurs on the same port number with the same timepoint 1 value.

It is clear to experts in the field that they produce NCIDs in different formats. Each switch records the NCID in 32 or 64 call record formats. Considering the 32-word call record format, the middle and end switches record the NCID in the acknowledgment field of the 32-word call record unless the acknowledgment code field is used to record other information. In this case, the source switch ID is recorded in the SER call record and is NCS switch ID, not alphanumeric switch ID. If the confirmation code is used for other information, the middle and end switches record the NCID in the 64-word call recording format. In contrast, the source switch does not use the acknowledgment code field when storing the NCID in a 32-word call record. The source switch records the NCID subfield in a separate 32-word call record. That is, the source switch ID is stored as an alphanumeric switch ID in the switch ID field of the SER call record. The source trunk group is stored in the Source Trunk Group field of the 32-word call record. The source port number is stored in the source port field of a 32-word call record. Time point 1 is stored in the NCID consecutive numeric field of the 32-word call record. The consecutive numbers are stored in the NCID consecutive number field of the 32-word call record. The 32-word call record also includes an NCID Location (NCIDLOC) field to identify when the NCID is recorded in the call record confirmation field. If the NCID location field contains 1 then the confirmation field contains the NCID. If the NCID location field contains zero then the NCID is stored in a separate subfield of the call log. Only the middle and end switches set the NCID position field to 1 because the source switch stores the NCID in each field of the 32-word call record.

The extended call log, taking into account the 64-word call record format, calls the NCID field to contain 82 bits of the NCID and includes separate fields. These call records are treated the same regardless of whether the source, middle or end switch stores the NCID. In the 64-word call recording format, the source switch ID is the NCS switch ID, not the alphanumeric switch recorded in the SER call recording.

FIG 92 describes the flow of adjustment for the network call identifier switch call processing. Call 30202 is called switch 30106-30110 at step 31104 (called the current switch for reference purposes: the current switch is the switch that handles the current call). At step 31104 the current switch receives call 30202 and proceeds to step 31106. In step 31106, the current switch accesses the local database and obtains trunk group parameters associated with the source trunk group of call 30202. After obtaining the parameters, the current switch proceeds to step 31108. In step 31108, the current switch determines whether an NCID with call 30202 has been received. If the current switch did not receive an NCID with call 30202, the switch continues to step 31112.

In step 31112, the switch analyzes the source trunk group parameters to determine the source trunk group type. If the source trunk group type is an intermachine trunk (IMT) or an emission link trunk (RLT) then the switch proceeds to step 31116. IMT is a trunk connecting two general communication switches, while RLT is a trunk connecting the intelligent service network (ISN) platform to a general communication switch. When the current switch reaches step 31116, it knows that it is not a source switch and has not received an NCID. In step 31116, the current switch analyzes the source trunk group parameters to determine whether to make an NCID for call 30202. In step 31116, if no NCID is made for call 30202, the current switch proceeds to step 31118. At step 31118 we know that the current switch is not a source switch, so we have not received the NCID for call 30202 but are not authorized to generate an NCID. Therefore, in step 31118 the current switch records the call record related to call 30202 to the local switch database and proceeds to step 31120. In step 31120 the current switch sends call 30202 along with the associated NCID over the network. Step 31120 is described in more detail below.

Referring back to step 31116, if the current switch is to create an NCID for call 30202, then the current switch proceeds to step 31114. In step 31114, the current switch generates a new NCID for call 30202 before continuing to step 31136. In step 31136 the current switch writes the call log related to call 30202 to the local switch database including the NCID. In step 31120, the current switch sends out call 30202 over the network associated with the NCID. Step 31120 is described in more detail below. Returning to step 31112 again, if the current switch determines whether the source trunk group type is IMT or RLT, then the current switch proceeds to step 31114. When step 31114 is reached, it knows that the current switch is a source switch and generates an NCID for call 30202. Step 31114 is described in detail below. After generating the NCID in step 31114, the current switch proceeds to step 31136 to write the call log including the NCID related to call 30202 to the local database. After writing the call log, the current switch proceeds to step 31120 to send the call out over the network with the associated NCID. Step 31120 is also described in detail below.

Returning to step 31108 again, if it is determined whether the current switch has received the NCID with call 30202, the current switch proceeds to step 31110. In step 31110 the current switch processes the received NCID. In step 31110 there are two possible results. First, the current switch determines not to retain the received NCID and proceeds from step 31110 to step 31114 to generate a new NCID. Step 31110 is described in detail below. Generate a new NCID for call 30202 before continuing from step 31114 to step 31116. Step 31114 is also described in detail below. In step 31136 the current switch writes the call log related to call 30202 to the local database. The current switch then proceeds to step 31120 to send the call 30202 over the network associated with the NCID. Step 31120 is also described in detail below.

Referring back to step 31110, the current switch determines to retain the received NCID and proceeds from step 31110 to step 31115. In step 31115, the current switch adds the received NCID to the call record older than call 30202. Steps 31110 and 31115 are described in detail below. After step 31115 the current switch continues to step 31136 to write the call log related to call 30202 to the local database. The current switch then proceeds to step 31120 to send the call 30202 over the network with the associated NCID.

FIG 93 describes the adjustment logic for step 31110 for processing the received NCID. The current switch enters step 31202 of step 31110 when determining whether the NCID has been received in call 30202. In step 31202 the current switch analyzes the source trunk group parameters to determine the source trunk group type. If the source trunk group type is IMT or RLT then the current switch proceeds to step 3312. In step 31212 we know that the current switch is not a source switch and received the NCID for call 30202. Therefore, in step 31212 the current switch maintains the received NCID and releases step 31110 and continues in step 31115 of FIG 92, after which the current switch stores the NCID received in the call record and stores the call.

Referring back to step 31202, if the source trunk group type is not IMT or RLT, the current switch proceeds to step 31204. In step 31204 the current switch determines whether the source trunk group type is an integrated service user sector direct access line (ISUP DAL) or an integrated service digital network primary rate interface (ISDN PRI). ISUP is a signaling protocol that allows information to be transferred from switch to switch as an information parameter. ISUP DAL is the first trunk group shared by multiple customers in a network and can also be dedicated to a single network customer. In contrast, ISDN PRI is the first trunk group shared by a single customer on a network and can also be dedicated to multiple network customers. Network customers are entities that borrow network resources. If the current switch determines in step 31204 whether the trunk group type is ISUP DAL or ISDN PRI, the current switch proceeds to step 31206. At step 31206 the current switch knows that it has received an NCID not generated by a switch that is a network customer or a switch that is part of a communication network. Therefore, in step 31206, the current switch discards the received NCID because it is an unreliable NCID. Step 31206 is released from step 31206, in which the current switch creates a new NCID and continues to step 31114, sending a NCID with call 30202.

Referring back to step 31204, if the current switch determines whether the source trunk group type is ISUP DAL or ISDN PRI, the current switch continues to step 31208. At step 31208 the current switch knows it has received an NCID from the customer trunk group. Therefore, the current switch analyzes the source trunk group parameters to determine whether or not it is authorized to create a new NCID for call 30202. Currently, the switch can create a new NCID and overwrite the NCID provided by the customer and send over the network to ensure a valid NCID corresponding to call 30202. In step 31208, if the new switch does not make a new NCID for call 30202, then the current switch proceeds to step 31210.

In step 31210 the current switch checks the validity of the received NCID, such as the NCID length. If the received NCID is invalid, the current switch proceeds to step 31206. In step 31206 the current switch discards the invalid NCID. From step 31206 the current switch releases step 31110 to go to step 31114 of FIG92 to create a new NCID and send the NCID with call 30202.

Referring back to step 31210, if the current switch determines whether the received NCID is valid, the current switch proceeds to step 31212. At step 31212 the current switch maintains the received NCID, exits to step 31110 and continues to step 31115 of FIG 92 to store the received NCID in the call log and transfer the call.

FIG 94A describes the adjustment logic for step 31114 for generating an NCID. The current switch enters step 31302 when the NCID is created. In step 31302 the current switch will calculate the consecutive digits. The consecutive numbers represent the number of calls originating from the same port with the same timepoint value. The first call has a sequential number of '0' values, and then the sequential number increments for successive calls that originate at the same port number with the same time point. After generating the continuous digits in step 31302, the current switch proceeds to step 31304. In step 31304 the current switch generates a call log for call 30202 including the newly created NCID in call 30202. After the call record is made, the current switch goes to step 31114 and proceeds to step 31136 of FIG 92 to write the call record to the local switch database.

FIG 94B describes the adjustment logic for step 31115 for adding the received NCID to the call log associated with call 30202. FIG. Inputted to step 31115 is the current switch to 31306. In step 31306, it is known that a valid NCID has been received from the intermediate or end switch or the customer switch. In step 31306 the current switch determines whether the confirmation code field of the 32-word call record is valid for storing the NCID. If valid, the current switch proceeds to step 31310. In step 31310 the current switch stores the NCID in the confirmation code field of the 32-word call record. The current switch must also set a value of '1' in the NCID position field indicating the NCID stored in the confirmation code field. After step 31310 the current switch goes to step 31115 and continues to step 31136 of FIG 92 to write the call log to the local switch database.

Referring back to step 31306, if the confirmation code field is not available for 32-word call recording, the current switch proceeds to step 31308. In step 31308 the current switch stores the NCID in the NCID field of the 64 word call record. After step 31308, the current switch goes to step 31115 and continuously writes a call log to the local switch database in step 31136 of FIG.

FIG 95 clears the coordination logic for step 31120 to transfer the call from the current switch. There are two input points for the control logic. Step 31402 and 31412. From step 31136 of FIG. 92, the input of step 31402 knows whether the current switch has generated an NCID or has received a valid NCID. In step 31402 the current switch obtains trunk group parameters associated with the trunk group for accessing the local database and sending call 30202. After obtaining the parameters the current switch proceeds to step 31404. In step 31404 the current switch determines the end trunk group type. If the end trunk is an ISUP trunk, the current switch proceeds to step 31408. In step 31408 the current switch analyzes the parameters related to the ISUP trunk shape to determine whether to forward the NCID to the next switch. Current switch

If the NCID can be passed, the current switch proceeds to step 31416. In step 31416 the current switch forwards the call to the next switch following the SS7 Initial Address Message (IAM). The NCID is transmitted as part of the IAM's comprehensive digit parameter. The IAM contains setup information for the next switch that prepares the next switch to accept and complete call 30202. The format of the generic digit parameters is shown in Table 306 below.

Comprehensive Digit Parameters:

code; 11000001

shape; 0

Table 306

After sending call 30202 and IAM, the current switch proceeds to step 31418 to terminate the switch processing.

Referring back to step 31408, if the current switch is authorized to forward the NCID in the IAM message to the next switch, the current switch proceeds to step 31412. In step 31412 the current switch forwards the call 30202 to the next switch under the normal procedure consisting of sending an IAM message to the next switch without the NCID recorded as part of a comprehensive digit parameter. After transferring to call 30202, the current switch proceeds to step 31418 to terminate the switch processing there.

Referring back to step 31404, if the current switch determines that the end trunk is not ISUP, the current switch proceeds to step 31406.

In step 31406 the current switch determines whether the end trunk group is an ISDN trunk (the end trunk group is dedicated to one network customer). If the end trunk group is ISDN, the current switch proceeds to step 31410. In step 31410, the current switch analyzes the parameters associated with the ISDN trunk group type to determine whether to forward the NCID to another switch. If the current switch is authorized to pass the NCID, the current switch proceeds to step 31414. In step 31414, the current switch sends the call to the next message according to the setup message. The setup message includes setup information for the next switch that prepares the next switch to accept and complete call 30202. The NCID is transmitted as part of locking the mobile codeset 6 parameter of the setup message. The format for locking the mobile codeset six parameters is shown in Table 307 below.

Locking moving codeset 6 parameters:

Code: 11000001

Form: 0

shape; 0

Table 307

After sending the call 30202 and the setup message, the current switch proceeds to step 31418 to terminate the switch processing.

Referring back to step 31408, if the current switch is authorized to forward the NCID to the next switch in the setup message, the current switch proceeds to step 31412. In step 31412 the current switch transmits call 30202 to the next switch under the normal procedure consisting of sending a setup message to the next switch without the NCID recorded as part of the Locking Move Codeset 6 parameter. After transferring to call 30202, the current switch proceeds to step 31418 to terminate the switch processing there.

Referring back to step 31412, input is made from step 31118 of FIG 92 when the current switch has not received the NCID, when it is the middle and end switches, and when the NCID is not made. In this case, at step 31412 the current switch sends call 30202 to the next switch under the normal procedure consisting of sending a setup message or IAM to the next switch without the NCID recorded as part of the parameter. After transferring to call 30202, the current switch proceeds to step 31418 to terminate the switch processing there.

The system and method for a switch in a communication network for generating call records for a telephone uses a flexible and extended format. Upon receipt of a telephone call, the network switch analyzes the telephone call to determine whether the default call log is large enough to store call log information, including the phone call, or whether the extended call log should store the call log, including the phone call. . After deciding which call log to use, the switch generates a default or extended call record. The switch sends the billing block to the billing center, which consists of complete call logs by filing the entire billing block.

What has been described above is merely one example and does not impose any limitation.

Index

Table 301-CDR / PNR Record Formats

Table 302-CDR / PNR Record Format

Table 303-OSR / POSR Record Formats

Claims (388)

A method of routing media transfers through a hybrid network that includes directory services. (a) transmitting media information to the hybrid network; (b) receiving the media transmission in the hybrid network; (c) parsing call information from the media information and querying the directory service based on the call information; (d) receiving the query from the hybrid network in the directory service; (e) confirming an operation based on the call information and the directory service information. The method of claim 1, A media transport routing method in which the call information includes delivery preference information The method of claim 2, Retrieving stored message information based on the delivery preference information. The method of claim 1, And wherein the media information includes support for text, audio, multimedia, video, and data. The method of claim 1, And wherein said operations based on said call information comprise document delivery. The method of claim 5, And the document delivery includes pager delivery, e-mail, faxing, and voice mail delivery. The method of claim 1, And the operations based on the call information comprise an outbound call. A system for routing media transmissions through a hybrid network that includes directory services. (a) control software for transmitting media information to the hybrid network; (b) control software for receiving the media transmission in the hybrid network; (c) control software for parsing call information from the media information and querying the directory service based on the call information; (d) control software to receive the query from the hybrid network in the directory service; (e) control software for verifying operation based on the call information and the information from the directory service. The method of claim 8, And the call information includes delivery preference information. The method of claim 9, Control software for retrieving stored message information based on the preference information. The method of claim 8, And the stored message information includes support for text, audio, multimedia, video and data. The method of claim 8, And the operations based on the paging information include document delivery. The method of claim 12, And the document delivery includes pager delivery, e-mail, faxing, and voice mail delivery. The method of claim 8, A media transport routing system in which said operations based on said call information comprise an outbound call A computer program contained on a computer readable medium for routing media transmissions through a hybrid network including directory services. (a) control software for confirming operation based on calling information and information from the directory service; (b) first software for transmitting media information to the hybrid network; (c) second software for receiving the media information in the hybrid network; (d) parsing call information from the media information and querying a directory service based on the call information; (e) fourth software for receiving the query from the hybrid network in the directory service; (f) a computer program recorded on a computer-readable medium having fifth software for confirming operation based on the call information and the information from the directory service. The method of claim 15, And the call information is embodied in a computer readable medium containing delivery preference information. The method of claim 16, And a software program for retrieving stored message information based on the delivery preference information. The method of claim 15, And wherein the stored media information includes support for text, audio, multimedia, video, and data. The method of claim 15, And the operations based on the calling information are recorded on a computer readable medium including document delivery. The method of claim 19, And the document delivery is recorded on a computer readable medium including pager transmission, electronic mail, fax transmission, and voice mail delivery. The method of claim 15, And the operations based on the call information are recorded on a computer readable medium including an outbound call. As a media communication method through a hybrid network, (a) establishing a multicast communication between two or more customers over a switching network and the Internet to transmit video, audio and / or data communications in a Real Time Transmission Protocol (RTP) format; (b) transmitting video information from each customer to all other customers concurrently participating in the communication; And (c) transmitting the mixed voice information from each of the other participating customers to each participating customer so that each participating customer can hear the voices of all other participating customers at the same time. Way. The method of claim 22, And examining the directory of customers capable of participating in video, audio and / or data communications via a user interface. The method of claim 22, A method of media communication over a hybrid network in which one customer establishes communication between two or more customers by selecting the participating customers according to the Internet protocol addresses of the other participating customers. The method of claim 23, wherein A method of media communication over a hybrid network in which one customer establishes communication between two or more customers by selecting other participating customers through a user interface. The method of claim 22, Media communication over hybrid network where one customer establishes communication between two or more customers by communicating with human or auto operator or agent The method of claim 22, (a) creating a virtual reality environment in which each customer participating in the communication is represented by a separate image; And (b) A customer making media communication between participants by processing virtual objects between the appearing images selects the participating customers according to the Internet protocol address of the other participating customers, thereby communicating between two or more customers. Media communication method through a hybrid network to set. As a media communication device over a hybrid network, (a) a processor having control software for establishing multicast communication between two or more customers over a switching network and the Internet for transmitting video, audio, and / or data communications in a Real Time Transmission Protocol (RTP) format; (b) a processor having control software for transmitting the media communication over the Internet to one or more other customers; (c) a processor having control software for receiving media communications via the Internet from one or more customers; (d) a media communications device over a hybrid network having a processor having control software for controlling said transmission and reception to obtain a predetermined quality of service for said media communications. The method of claim 28, And the media communication comprises a combination of video information, audio information and data. The method of claim 29, And a user interface for conducting a search to determine if an intended recipient of the media communication can receive the media communication by examining a directory of available video telephony customers. The method of claim 29, And the media communication is transmitted through a human, automatic operator or agent. The method of claim 29, Wherein the transmission and reception are controlled by a resource reservation protocol that reserves network resources over a communication path to obtain a specified quality of service for the media communication. The method of claim 29, (a) a processor having control software for transmitting the media communication via a human or auto operator or agent if a human or auto agent is available: (b) a storage unit for storing the recorded media information; (c) a processor having control software for transferring the recorded media information from a storage location to a customer if a human or automated agent is not available: and (d) a media communication device over a hybrid network having a processor having control software for terminating said recorded information transfer when a human or automatic operator or agent becomes available. A computer program on a computer readable medium for media communication over a hybrid network, (a) first software for establishing multicast communication between two or more customers over a switching network and the Internet for transmitting video, audio, and / or data communications in a Real Time Transmission Protocol (RTP) format; (b) second software for transmitting media communications over the Internet to one or more other customers; (c) third software for receiving media communications via the Internet from one or more other customers; And (d) a computer program recorded on a computer readable medium for media communication via a hybrid network having fourth software for controlling the transmission and reception to obtain a designated quality of service for the media communication. The method of claim 34, wherein And the media communication is embodied in a computer readable medium for media communication via a hybrid network having a combination of video information, audio information and data. The method of claim 34, wherein Further equipped with a fifth software of a directory of available video telephony customers, where one customer examines the directory to determine whether an intended recipient of the media communication can receive the media communication Computer programs on a computer readable medium for a computer. The method of claim 34, wherein And the media communication is embodied in a computer readable medium for media communication via a hybrid network transmitted through a human, automatic operator or agent. The method of claim 34, wherein And said transmitting and receiving is embodied in a computer readable medium for media communication over a hybrid network controlled by a resource reservation protocol for reserving network resources over a communication path to obtain a specified quality of service for said media communication. The method of claim 34, wherein (a) fifth software for transmitting the media communication via a human or auto operator or agent if a human or auto agent is available; (b) sixth software for storing the recorded media information in a storage location; (c) seventh software for transmitting the recorded media information from a storage location to a customer if a human or automated agent is not available; And (d) a computer program embodied in a computer readable medium for media communication via a hybrid network, further comprising an eighth software for terminating the transmission of the recorded media information when a human or automatic operator or agent becomes available. As a media communication method through a hybrid network, (a) establishing multicast communication between a plurality of users for media communication in a real time transport protocol (RTP) format utilizing the hybrid network; (b) transmitting audio information from the first user to all other customers concurrently participating in the communication; (c) transmitting video information from the first user participating in the multicast communication to each user so that each participating user can hear the voices of all other participating users at the same time; And (d) storing a claim record based on media characteristics and user participation utilized to route the media communication through the hybrid network. The method of claim 40, Examining the directory of users available for participating in video, audio and / or data communications and reflecting the use of the survey characteristics in the billing record. The method of claim 40, A method of media communication over a hybrid network in which one user establishes communication between two or more users by selecting the participating users according to the Internet protocol addresses of the other participating users. The method of claim 41, wherein A method of media communication over a hybrid network in which one user establishes communication between two or more users by selecting other participating users from a user interface. The method of claim 40, Media communication method through a hybrid network in which one user establishes communication among a plurality of users by communicating with one operator. The method of claim 40, (a) creating a virtual reality environment in which each user participating in the communication is represented by a separate image; And and (b) performing media communication between participants by processing the virtual object associated with the individual video. As a media communication system through a hybrid network, (a) control software for establishing multicast communication between a plurality of users for media communication in a real-time transport protocol (RTP) format utilizing the hybrid network; (b) communication software for transmitting audio communication from one user to all other users participating in the communication at the same time; (c) communication software for transmitting video information from the first user participating in the multicast communication to each user so that each participating user can communicate with all other participating users; (d) a media communication system via a hybrid network having control software for storing a claim record based on media characteristics and user participation utilized in routing the media communication through the hybrid network. The method of claim 46, And a user interface for examining a directory of users available for participating in video, audio, and / or data communications and reflecting the use of the survey characteristics in the billing record. 47. The method of claim 46 wherein A media communication system via a hybrid network in which one user establishes communication between two or more users by selecting the participating users according to the Internet protocol addresses of the other participating users. The method of claim 47, A media communication system over a hybrid network, wherein one user establishes communication between two or more users by selecting participating users from the user interface. 47. The method of claim 46 wherein A media communication system via a hybrid network in which one user establishes communication between a plurality of users by communicating with one operator. 47. The method of claim 46 wherein (a) control software utilized to create a virtual reality environment in which each user participating in the communication is represented by a separate image; And (b) further comprising control software utilized to conduct media communication between the participants by processing a virtual object associated with an individual image. A computer program on a computer readable medium for routing media communications over a hybrid network, (a) first software for establishing multicast communication between a plurality of users for media communication in a real-time transport protocol (RTP) format utilizing the hybrid network; (c) second software for transmitting audio communications from the first user to all other users concurrently participating in the communications; (d) third software for transmitting video information from the first user participating in the multicast communication to each user so that each participating user can communicate with all other participating users; (e) a computer readable medium for routing media communications over a hybrid network having control software for storing a claim record based on media characteristics utilized for routing said media communications over said hybrid network and said user participation. Computer programs listed in. The method of claim 52, wherein Read to a computer for routing media communications over a hybrid network further comprising a user interface that examines a directory of users available for participating in video, audio and / or data communications and reflects the use of the survey characteristics in the claim record. Computer programs on the available media. The method of claim 52, wherein A computer on a readable medium for routing media communications over a hybrid network in which one user selects the participating users according to the Internet protocol addresses of the other participating users, thereby establishing communication between two or more users. program. The method of claim 53, A computer program recorded on a computer-readable medium for routing media communications over a hybrid network, where one user selects participating users from the user interface, thereby establishing communications between two or more users. The method of claim 52, wherein A computer program recorded on a computer-readable medium for routing media communications over a hybrid network in which one user communicates with one operator to establish communication between a plurality of users. The method of claim 52, wherein (a) fifth software used to create a virtual reality environment in which each user participating in the communication is represented by a separate image; And (b) a computer readable on a computer-readable medium for routing media communications over a hybrid network, further comprising a sixth software utilized to perform media communications between participants by processing the virtual objects associated with the individual images. program. A method of connecting a first telephony device with a second telephony device to perform media transfer over a hybrid network including an authentication mechanism, (a) dialing a card access number from the first telephony device; (b) determining whether the first telephony device is authorized to establish a desired call by prompting the card number; (c) receiving a card number entry from the first telephone call device; (d) prompting the telephone number; (e) receiving a telephone number entry from the first telephony device; (f) accessing a directory service and verifying the destination of the call by translating the telephone number entry into a destination number; (g) connect the first telephony device to the second telephony device for media transmission via a hybrid network comprising an authentication mechanism comprising the step of completing the call at a destination number of the second telephony device; How to. The method of claim 58, Connecting the first telephony device to the second telephony device for media transmission via a hybrid network wherein the card information includes an authentication mechanism comprising a unique card number. The method of claim 59, Connecting the first telephony device to the second telephony device for media transmission via a hybrid network comprising an authentication mechanism comprising an access number; The method of claim 58, And the calling card connects the first telephony device with the second telephony device for media transmission via a hybrid network comprising an authentication mechanism that is a cache card. The method of claim 58, And the calling card connects the first telephony device with the second telephony device for media transmission via a hybrid network comprising an authentication mechanism comprising access to operator information. The method of claim 58, And the calling card connects the first telephony device with the second telephony device to perform media transmission over a hybrid network including an authentication mechanism comprising speed dial characteristics. The method of claim 58, And the calling card connects the first telephony device with the second telephony device for media transmission via a hybrid network including an authentication mechanism that provides access to conference call support. The method of claim 58, And the calling card connects the first telephony device with the second telephony device to perform media transfer over a hybrid network including an authentication mechanism that provides access to voicemail. The method of claim 58, And the calling card connects the first telephony device with the second telephony device to perform media transfer over a hybrid network including an authentication mechanism that provides access to the e-mail. The method of claim 58, And the calling card connects the first telephony device with the second telephony device for media transmission via a hybrid network including an authentication mechanism that provides access to a news service. A computer program stored on a computer readable medium for routing media transmissions over a hybrid network from a first telephony device to a second telephony device, (a) first software for dialing a card access number from said first telephone call device; (b) second software for determining whether the first telephony device is authorized to set up a desired call by prompting a card number; (c) third software for receiving a card number entry from the first telephony device; (d) fourth software for prompting the telephone number; (e) fifth software for receiving a telephone number from said first telephone call device; (f) sixth software accessing a directory service and verifying the destination of the call by translating the telephone number entry into a destination number; And (g) a seventh software program for completing the call at a destination number of the second telephony device. The method of claim 68, And the card information comprises a unique card number. The method of claim 68, And the card information includes an access number. The method of claim 68, And the calling card is a billing card. The method of claim 68, And the calling card includes access to operator information. The method of claim 68, And the call card comprises a speed-dial feature. The method of claim 68, And the calling card provides access to conference call support. The method of claim 68, And the calling card provides access to voicemail. The method of claim 68, And the calling card provides access to the e-mail. The method of claim 68, And the calling card provides access to a news service. As a media communication method through a hybrid network, (a) generating profile information belonging to the caller; And (b) utilizing the profile information to provide media characteristics via the hybrid network based on the profile information belonging to the caller. The method of claim 78, And the profile information is stored in a database accessible from the hybrid network. The method of claim 78, And the profile information is stored in a distributed database that facilitates highly available processing. The method of claim 78, And the profile information is stored in a database located at a host processor attached to a switching network. The method of claim 78, When the new user is processed, the profile information is generated in a database located in a host processor. The method of claim 78, And wherein said profile information is dynamically changed by a user associated with said profile information to reflect current information. Media communication device via a hybrid network connected to the Internet, (a) a storage unit connected to the hybrid network and storing profile information about a user; And and (b) a processor having control software that utilizes the profile information to provide properties over the hybrid network based on profile information about the user. 85. The method of claim 84, And the profile information is stored in a database accessible from the hybrid network. 85. The method of claim 84, And wherein said profile information is stored in a database that facilitates high availability processing. 85. The method of claim 84, And the profile information is stored in a database located at a host processor connected to the hybrid network. 85. The method of claim 84, And the profile information is stored in a database located in a host processor when a new customer is processed. 85. The method of claim 84, And wherein said profile information is dynamically changed by a customer associated with said profile information to reflect current information. A computer program contained in a computer readable medium for communication of media through a hybrid network connected to the Internet. (a) first software for storing profile information about the user; And (b) a computer-readable medium for media communication over a hybrid network having a processor having a second software for utilizing the profile information to provide properties over the hybrid network based on profile information about the user. Computer programs listed in. 91. The method of claim 90, And the profile information is recorded on a computer-readable medium for media communication via a hybrid network stored in a database accessible from the hybrid network. 91. The method of claim 90, And the profile information is stored in a distributed database that facilitates high availability processing. 91. The method of claim 90, And the profile information is stored in a database located on a host processor connected to the hybrid network. 91. The method of claim 90, A computer program recorded on a computer-readable medium for media communication via a hybrid network in which the profile information is generated in a database located on a host processor when a new customer is processed. 91. The method of claim 90, Computer program dynamically changed by a customer associated with the profile information to reflect the profile information. As a media communication method through a hybrid network, (a) generating profile information about the caller; And (b) utilizing the profile information to provide find-me-follow-me processing based on the profile information about the caller. 97. The method of claim 96, And the profile information is stored in a database accessible from the hybrid network. 97. The method of claim 96, And wherein said profile information is stored in a distributed database that facilitates high availability processing. 97. The method of claim 96, And the profile information is stored in a database located in a host processor connected to a switching network. 97. The method of claim 96, And the profile information is generated in a database located in a host processor when a new user is processed. 97. The method of claim 96, And wherein said profile information is dynamically changed by a user associated with said profile information to reflect current information. As a media communication device over a hybrid network, (a) a storage unit connected to the hybrid network and storing profile information about a user; And (b) a media communication device over a hybrid network having a processor having control software that utilizes the profile information to provide fine-me-follow-me processing over the hybrid network based on profile information about the user. . 103. The method of claim 102, And the profile information is stored in a database accessible from the hybrid network. 103. The method of claim 102, And wherein said profile information is stored in a distributed database that facilitates high availability processing. 103. The method of claim 102, And the profile information is stored in a database located at a host processor connected to the hybrid network. 103. The method of claim 102, And wherein said profile information is generated in a database located in a host processor when a new customer is processed. 103. The method of claim 102, Media communication device over a network that is dynamically changed by a customer associated with the profile information such that the profile information reflects current information. A computer program stored in a computer readable medium for media communication via a hybrid network, (a) first software for storing profile information about the user; And (b) a computer for media communication over a hybrid network having second software that utilizes the profile information to provide fine-me-follow-me processing over the hybrid network based on profile information about the user. Computer programs recorded on media that can be read by 109. The method of claim 108, And the profile information is recorded on a computer-readable medium for media communication via a hybrid network stored in a database accessible from the hybrid network. 109. The method of claim 108, And the profile information is recorded on a computer-readable medium for media communication via a hybrid network stored in a distributed database that facilitates high availability processing. 109. The method of claim 108, And the profile information is recorded on a computer-readable medium for media communication via a hybrid network stored in a database located in a host processor connected to a switching network. 109. The method of claim 108, A computer program recorded on a computer-readable medium for media communication via a hybrid network in which the profile information is generated in a database located on a host processor when a new customer is processed. 109. The method of claim 108, A computer program recorded on a computer-readable medium for media communication via a hybrid network, wherein the profile information is dynamically changed by a customer associated with the profile information to reflect current information. As a media communication method through a hybrid network, (a) generating profile information about the caller; (b) utilizing the profile information to define characteristics over the hybrid network based on profile information about the caller. 119. The method of claim 114, And the profile information is stored in a database accessible from the hybrid network. 119. The method of claim 114, And wherein said profile information is stored in a distributed database that facilitates high availability processing. 119. The method of claim 114, And the profile information is stored in a database located in a host processor connected to a switching network. 119. The method of claim 114, And the profile information is generated in a database located in a host processor when a new user is processed. 119. The method of claim 114, And wherein said profile information is dynamically changed by a user associated with said profile information to reflect current information. Media communication device via a hybrid network connected to the Internet, (a) a storage unit connected to the hybrid network and storing profile information about a user; And (b) a processor with a processor having control software that utilizes the profile information to define characteristics over the hybrid network based on profile information about the user. 121. The method of claim 120, And the profile information is stored in a database accessible from the hybrid network. 121. The method of claim 120, And wherein said profile information is stored in a distributed database that facilitates high availability processing. 121. The method of claim 120, And the profile information is stored in a database located at a host processor connected to the hybrid network. 121. The method of claim 120, And wherein said profile information is generated in a database located in a host processor when a new customer is processed. 121. The method of claim 120, Media communication device over a network that is dynamically changed by a customer associated with the profile information such that the profile information reflects current information. A computer program on a computer-readable medium for media communication over a hybrid network connected to the Internet. (a) first software for storing profile information about the user; And (b) second software for utilizing the profile information to define properties over the hybrid network based on the profile information about the user. 126. The method of claim 126, And the profile information is recorded on a computer-readable medium for media communication via a hybrid network stored in a database accessible from the hybrid network. 126. The method of claim 126, And the profile information is recorded on a computer-readable medium for media communication via a hybrid network stored in a distributed database that facilitates high availability processing. 126. The method of claim 126, And the profile information is recorded on a computer-readable medium for media communication via a hybrid network, which is a database located in a host processor connected to a switching network. 126. The method of claim 126, A computer program recorded on a computer-readable medium for media communication via a hybrid network in which the profile information is generated in a database located on a host processor when a customer is processed. 126. The method of claim 126, A computer program recorded on a computer-readable medium for media communication via a hybrid network, wherein the profile information is dynamically changed by a customer associated with the profile information to reflect current information. A method of facsimile communication over a hybrid network comprising a source facsimile gateway and a source having a hybrid network interface, (a) establishing a V.29 modem session with a source facsimile gateway; (b) establishing a T.30 facsimile protocol session with a source facsimile gateway; (c) establishing a packet T.30 protocol session with a destination facsimile gateway; (d) contacting a destination facsimile transmittable device from the destination facsimile gateway; (e) establishing, by the destination facsimile gateway, a V.29 modem session with the facsimile transmittable device; (f) establishing a T.30 facsimile protocol session with the facsimile transmittable device; (g) negotiating end-to-end T.30 facsimile parameters between two facsimile transmittable devices via the source and destination facsimile gateways; (h) sending an end-to-end facsimile between two facsimile transmittable devices by receiving a data scan line, generating a packet, and transmitting the packet to the destination facsimile transmittable device; (i) detecting the completion of the facsimile transmission and handing over the communication path. 133. The method of claim 132, A method of facsimile communication over a hybrid network provided with call information for determining routing when said facsimile is sent. 133. The method of claim 133, And the call information includes a number of a called party. 133. The method of claim 133, And fax information comprises a calling party number. 133. The method of claim 133, And fax information comprises carrier identification. 133. The method of claim 133, And a facsimile communication method through a hybrid network in which the call information includes an outgoing line. A computer program recorded on a computer-readable medium for facsimile communication over a hybrid network including a source fax gateway and a source having a hybrid network interface, (a) first software for establishing a V.29 modem session with a source fax gateway; (b) second software for establishing a T.30 facsimile protocol session with a source facsimile gateway; (c) third software for establishing a packet T.30 protocol session with a destination facsimile gateway; (d) fourth software contacting a destination facsimile transfer capable device from the destination facsimile gateway; (e) fifth software for establishing a V.29 modem session with the destination facsimile transmittable device by the destination facsimile gateway; (f) sixth software for establishing a T.30 facsimile protocol session with a destination facsimile transmittable device; (g) seventh software for negotiating end-to-end T.30 facsimile parameters between two facsimile transmittable devices via a source and destination facsimile gateway; (h) eighth software for transmitting an end-to-end facsimile between two facsimile transmittable devices by receiving a data scan line, generating a packet, and transmitting the packet to the destination facsimile transmittable device; (i) a computer program comprising ninth software for detecting completion of the facsimile transmission and handing over the communication path. 138. The method of claim 138, wherein Computer program provided with call information for determining routing when said fax is sent. 140. The method of claim 139, wherein And the call information comprises a number of the called party. 140. The method of claim 139, wherein And the call information comprises a call party number. 140. The method of claim 139, wherein And the call information comprises carrier identification. 140. The method of claim 139, wherein And the call information comprises a call line. As a hybrid communication system, (a) a switching communication network; (b) a packet transport network coupled to the switching communication network; (c) a call router connected to the switching communication network and the packet transmission network; (d) having a memory connected to said call router and storing a call parameter database therein, The call router is configured to route a call through the switching communication network and the packet transport network based on at least one call parameter from the call parameter database, the call router is further configured to provide an intelligent service platform, The intelligent service platform has a plurality of service engines, each configured to execute a desired service logic, and is coupled to the service engine, the plurality of service engines for processing transactions provided by the network including the hybrid communication system. And a service selection component for selecting a service instance running one of the service engines of. 145. The method of claim 144 wherein Interact with at least some of the service characteristics for which the service logic is used, the order in which the service characteristics are called, output service data, error values and destinations of error processing, invocation of other services, and other services Hybrid communication system to check. 145. The method of claim 145, Wherein the service characteristic comprises at least one time based routing, authentication, and automatic user interaction. As a call setup and service selection method in a hybrid communication system including a switching communication network and a packet transmission network, (a) storing the call parameter database in memory; (b) receiving a call at the system; (c) accessing the call parameter database to determine at least one call parameter; (d) routing the call through the switching communication network and the packet transport network based on at least one call parameter; (e) providing a plurality of service engines each configured to execute a desired service logic; (f) a hybrid communication system comprising a switching communication network and a packet transport network comprising selecting a service instance running one of the service engines to process a transaction provided by the network having the hybrid communication system. To set up calls and select services on Windows 147. The method of claim 147, Interact with at least some of the service characteristics for which the service logic is used, the order in which the service characteristics are called, output service data, error values and destinations of error processing, invocation of other services, and other services How to check call setup and service selection. 148. The method of claim 148, wherein And wherein said service characteristic comprises at least one time-based routing, authentication, and automatic user interaction. A computer program recorded on a computer-readable medium for establishing a call and managing resources in a hybrid communication system including a switching communication network and a packet transmission network, (a) first software for storing a calling parameter database in memory; (b) second software for accessing the call parameter database when the system receives a call to determine at least one call parameter; (c) third software for routing the call through the switching communication network and the packet transport network based on at least one call parameter and the system configuration; (d) fourth software for providing a plurality of service engines, each configured to execute a desired service logic; (e) a computer program comprising fifth software for selecting a service instance running one of the service engines to process a transaction provided by the network having the hybrid communication system. 151. The method of claim 150, Interact with at least some of the service characteristics for which the service logic is used, the order in which the service characteristics are called, output service data, error values and destinations of error processing, invocation of other services, and other services Computer program to check. 151. The method of claim 151, And the service characteristic comprises at least one time based routing, authentication, and automatic user interaction. As a hybrid network, (a) a switching communication network; (b) a packet transport network coupled to the switching communication network; (c) a call router connected to the switching communication network and the packet transmission network; (d) a memory coupled to the call router and storing a call parameter database therein; Wherein the call router is configured to route a call through the switching communication network and the packet transport network based on at least one call parameter from the call parameter database, the call router is further configured to provide an intelligent service platform. The intelligent service platform comprises a plurality of media clients, and (e) a media server coupled between the plurality of media clients and the memory, the media server residing therein for coupling the first and second servers of the media client in a cooperative session; (f) logic for the media server to manage video, audio, voice, and other media based on media client capabilities to handle various types of media. 153. The method of claim 153, And wherein the intelligent service platform is configured to provide data for a plurality of services using the call parameter database. [Claim 154] 153. The method of claim 153, The intelligent service platform includes a service engine and the data client is configured to cache data obtained from the call parameters through a data server for customers serviced by the service engine. 153. The method of claim 153, The media server includes a service engine that determines how to route media through the hybrid network between the first media client and the second media client. 153. The method of claim 153, A hybrid network in which all of the plurality of media clients exchange media through the hybrid network. A call setup and service providing method through a hybrid communication network including a switching communication network and a packet transmission network, (a) storing the call parameter database in memory; (b) receiving a call at the system; (c) accessing the call parameter database to determine at least one call parameter; (d) routing the call through the switching communication network and the packet transport network based on at least one call parameter; (e) connecting a media server between a plurality of media clients and the memory; Wherein the media server resides in logic to join the first and second clients of the media clients in a collaborative session. (f) adjusting media output based on media client capabilities to process various types of media. 161. The method of claim 157, And the call parameter database is used to provide data for a plurality of services during the call. 161. The method of claim 157, And caching data from the call parameter database to route the call and provide the service during the call. 161. The method of claim 157, And a service engine that determines how the media server routes media through a hybrid network between the first media client and the second media client. 161. The method of claim 157, And all of said plurality of media clients exchange media over said hybrid network. A computer program recorded on a computer-readable medium for providing call setup and service through a hybrid communication network including a switching communication network and a packet transmission network. (a) first software for storing a calling parameter database in memory; (b) second software for accessing the call parameter database when the system receives a call to determine at least one call parameter; (c) third software for routing the call through the switching communication network and the packet transport network based on the at least one call parameter; (d) fourth software for providing data for a service provided during the call using the call parameter database; (e) fifth software for connecting a media server between the plurality of media clients and the memory; Wherein the media server resides in logic to join the first and second clients of the media clients in a collaborative session, and (f) A computer program embodied in a computer readable medium having sixth software for adjusting media output based on media client capabilities to process various types of media. 162. The method of claim 162, A computer program embodied on a computer readable medium, wherein the fourth software uses the call parameter database to provide data for a plurality of services during the call. 162. The method of claim 162, and (g) a seventh software for caching data from the call parameter database to route the call and provide the service during the call. 162. The method of claim 162, And a computer program readable by the media server to determine how to route media through a hybrid network between the first media client and the second media client. 162. The method of claim 162, And a computer program readable on a computer readable medium in which all of the plurality of media clients exchange media through the hybrid network. As a communication system, (a) a switching telephone network; (b) a packet transport network coupled to the switching telephone network; (c) a call router connected to the switching telephone network and the packet transmission network; (d) a memory coupled to the call router and storing therein a call parameter database, the call router configured to establish the switching telephone network and the packet transfer network based on at least one call parameter from the call parameter database. Configured to route telephone calls through the call router, wherein the call router is further configured to provide an intelligent service platform, the intelligent service platform comprising a master database server configured to control and protect the integrity of the database and a user access and And at least one satellite domain configured to provide update capability and including a database client coupled to said master database. 167. The method of claim 167, At least one of the master database server and the database client is divided into physical subsets such that all data items are not at one site and maintain a logical view of a single database. 167. The method of claim 167, The database server and the database client are configured to enable the database client to subscribe to data stored in the master database. A call establishment method through a hybrid communication system including a switching communication network and a packet transmission network, (a) storing the call parameter database in memory; (b) receiving a call at the system; (c) accessing the call parameter database to determine at least one call parameter; (d) routing the call through the switching communication network and the packet transport network based on at least one call parameter; (e) providing a central domain comprising a master database server configured to control and protect the integrity of the database; And (f) providing at least one satellite domain configured to provide user access and update capability and comprising a database client coupled to the master database. 172. The method of claim 170, (g) partitioning at least one of the master database server and the database client into a physical subset such that all data items are not at one site and maintain a logical view of a single database. . 172. The method of claim 170, (g) using the database client to subscribe to data stored in the master database. A computer program recorded on a computer-readable medium for managing call setup and resources through a hybrid communication network including a switching communication network and a packet transmission network, (a) first software for storing a calling parameter database in memory; (b) second software for accessing the call parameter database when the system receives a call to determine at least one call parameter; (c) third software for routing the call through the switching communication network and the packet transport network based on at least one call parameter and the system configuration; (d) fourth software providing a central domain comprising a master database server configured to control and protect the integrity of the database; And (e) a computer program embodied on a computer readable medium having fifth software providing at least one satellite domain configured to provide user access and update capability and comprising a database client coupled to the master database. 174. The method of claim 173, wherein (f) a computer further comprising sixth software for partitioning at least one of said master database server and said database client into physical subsets such that all data items are not at one site and maintain a logical view of a single database program. 174. The method of claim 173, wherein (f) a computer program comprising sixth software that uses the database client to subscribe to data stored in the master database. As a communication system, (a) a switching telephone network; (b) a packet transport network coupled to the switching telephone network; (c) a call router connected to the switching telephone network and the packet transmission network; (d) a memory coupled to the call router and storing therein a call parameter database, the call router configured to establish the switching telephone network and the packet transfer network based on at least one call parameter from the call parameter database. And route the telephone call via the call router, wherein the call router is further configured to provide an intelligent service platform, wherein the intelligent service platform is configured to obtain configuration data for the customer supported by at least one service engine. A communication system having a database coupled between at least one service engine and the at least one service engine. 176. The method of claim 176, The at least one service engine is configured such that data is cached at the service engine. 176. The method of claim 176, The at least one service engine is configured to hand-off control to another service engine during execution of a service for a customer supported by the at least one service engine. As a call setup and service selection method through a hybrid communication system including a switching communication network and a packet transmission network, (a) storing a call parameter database in memory with a general information base; (b) receiving a call at the system; (c) accessing the call parameter database to determine at least one call parameter; (d) routing the call through the switching communication network and the packet transport network based on at least one call parameter; (e) providing at least one service engine; (f) obtaining configuration data for the customer supported by the at least one service engine from the call parameter database. 178. The method of claim 179, Call setup and service selection method in which data is cached in the service engine. 178. The method of claim 179, And wherein said at least one service engine hands off control to another service engine during execution of a service for a customer supported by said at least one service engine. A computer program recorded on a computer-readable medium for managing call setup and resources through a hybrid communication system including a switching communication network and a packet transmission network, (a) first software for storing a calling parameter database in memory; (b) second software for accessing the call parameter database when the system receives a call to determine at least one call parameter; (c) third software for routing the call through the switching communication network and the packet transport network based on at least one call parameter and the system configuration; (d) fourth software for providing at least one service engine; And (e) a computer program recorded on a computer-readable medium having fifth software for obtaining configuration data for the customer supported by the at least one service engine from the call parameter database. 182. The method of claim 182, A computer program recorded on a computer-readable medium in which data is cached in the service engine. 182. The method of claim 182, Said at least one service engine hand-offs control to another service engine during execution of a service for a customer supported by said at least one service engine. A method of routing media transmissions over a hybrid network that includes a directory service, (a) transmitting media information to the hybrid network; (b) receiving the media transmission in the hybrid network; (c) parsing call information from the media information and querying the directory service based on the call information; (d) receiving the query from the hybrid network in the directory service; And (e) confirming an operation based on the call information and the directory service information. 185. The method of claim 185, A media transport routing method in which the call information includes delivery preference information 185. The method of claim 185, Retrieving stored message information based on the delivery preference information. 185. The method of claim 185, And wherein said stored message information includes support for text, audio, multimedia, video, and data. 185. The method of claim 185, And wherein said operations based on said call information comprise document delivery. The method of claim 189, wherein And the document delivery generates a billing record based on the operations. 185. The method of claim 185, And the operations based on the call information comprise an outbound call. A system for routing media transmissions through a hybrid network that includes directory services. (a) control software for transmitting media information to the hybrid network; (b) control software for receiving the media information in the hybrid network; (c) control software for parsing call information from the media information and querying the directory service based on the call information; (d) control software to receive the query from the hybrid network in the directory service; (e) control software for performing paging based on the call information and the information from the directory service. 192. The method of claim 192, And the call information includes delivery preference information. 192. The method of claim 192, Control software for retrieving stored message information based on the preference information. 192. The method of claim 192, And wherein the stored message information includes support for text, audio, multimedia, video, and data. 192. The method of claim 192, Media transport routing system, wherein operations based on the call information include document delivery. 196. The method of claim 196, And the document delivery includes generating an invoice record based on the actions. 192. The method of claim 192, And the operations based on the call information comprise an outbound call. A computer program contained on a medium readable by a computer that routes media transfers through a hybrid network including a directory service. (a) first software for transmitting media information to the hybrid network; (b) second software for receiving the media information in the hybrid network; (c) third software for parsing call information from the media information and querying a directory service based on the call information; (d) fourth software for receiving the query from the hybrid network in the directory service; (e) a computer program recorded on a computer-readable medium having fifth software for performing paging based on the call information and the information from the directory service. 200. The method of claim 199 wherein And the call information is recorded on a computer-readable medium containing delivery preference information. 200. The method of claim 199 wherein And a computer program recorded on a computer-readable medium including software for retrieving stored message information based on the delivery preference information. 200. The method of claim 199 wherein And the stored message information is recorded on a computer readable medium including support for text, voice, multimedia, images and data. 200. The method of claim 199 wherein And the operations based on the call information are recorded on a computer-readable medium including document delivery. 203. The method of claim 203, wherein And the document delivery is recorded on a computer readable medium including generation of an invoice record based on the operations. 200. The method of claim 199 wherein And the operations based on the call information are recorded on a computer readable medium including an outbound call. A method of connecting a first telephone capable device and a second telephone enabled device for media transmission through a hybrid network, (a) dialing a collect service from the first telephony device; (b) entering a destination telephone number in response to a prompt from the collect service; (c) entering a caller's name in response to a prompt from the collect service; (d) establishing a call to the destination telephone number by the collect service; (e) connecting the call to the second telephony device in response to a query for charge acceptance. 206. The method of claim 206, Calling terminates as a result of a negative response to a prompt from the calling service. 213. The method of claim 207, Wherein the destination telephone number is translated to an internet protocol address using a directory service. 206. The method of claim 206, The collect call service is automated using a voice response unit 206. The method of claim 206, And wherein said collect call service is fully or partially automated using a video answering unit. 206. The method of claim 206, The calling service is manually executed by an operator. 206. The method of claim 206, The calling service is automated through the use of a multimedia answering unit. 206. The method of claim 206, The calling service provides internet access. 206. The method of claim 206, The calling service charges a service fee to a third party. A computer program contained in a computer-readable recording medium for connecting a first telephone capable device and a second telephone capable device for media transmission over a hybrid network. (a) first software for dialing a collect service from said first telephone capable device; (b) second software for entering a destination telephone number in response to a prompt from the collect service; (c) third software for entering a caller's name in response to a prompt from the collect service; (d) fourth software for establishing a call to the destination telephone number by the collect service; (e) a computer program comprising fifth software for linking said call to said second telephone capable device in response to a query for charge acceptance. 215. The method of claim 215, And the computer program terminates the call as a result of the negative response to the prompt from the calling service. 215. The method of claim 215, And the destination telephone number is translated to an internet protocol address using a directory service. 215. The method of claim 215, And the collect call service is automated using a voice response unit. 215. The method of claim 215, And the collect call service is fully or partially automated using a video answering unit. 215. The method of claim 215, A computer program in which the calling service is executed manually by an operator. 215. The method of claim 215, And the call service is automated through the use of a multimedia answering unit. 215. The method of claim 215, A computer program in which the calling service provides Internet access. 215. The method of claim 215, And the calling service charges a service fee to a third party. As a hybrid communication system, (a) a switched network; (b) a packet transmission network coupled to the switched communication network; (c) a call router coupled to the switched telecommunication network and the packet transmission network; (d) a memory coupled to the call router and storing therein a call parameter database, the call parameter database comprising a call parameter database, the profile information belonging to the subscriber of the hybrid communication system, the call router having the call parameter database; Route a call through the switched network and the packet transport network based on at least one call parameter from the; (e) at least one service engine coupled to the calling router and configured to execute logic defined by the profile information to provide a personalized service function for the subscriber to which the profile information belongs. 224. The method of claim 224, Wherein the at least one service engine comprises a service selection service engine, the service selection service engine configured to select and execute one or more services of the hybrid communication system. 224. The method of claim 224, The at least one service engine comprises an analysis service engine, and wherein the analysis service engine is configured to perform at least one network statistic Eh based on calling context information. 226. The method of claim 226, And the detection or customer call volume statistics as defined above. 224. The method of claim 224, Wherein said at least one service engine comprises a special service engine, said special service engine configured to provide a low level functional capability or computing resource for at least one system service delivery, monitoring, or management. 224. The method of claim 224, (f) a hybrid further comprising specialized resources coupled to the calling router and at least one service engine and configured to provide network-based capabilities including at least one internet-to-speech conversion, DTMF detection, facsimile recognition or speech recognition; Communication system. 224. The method of claim 224, (f) a call communication server coupled to the call router and the at least one service engine, further comprising a call context server configured to receive network event records and service events in real time and to accept queries for the received data. . 232. The method of claim 230, (g) further comprising an import manager coupled to the call context server, wherein the call context server is configured to provide the import manager with combined event information for a call or other network transaction. 224. The method of claim 224, (f) further comprising a statistics server coupled to at least one service engine, wherein the statistical notation is configured to accept statistical events from at least one service engine and accept queries for the received data. 232. The method of claim 232, And the statistics server compiles the statistics event for a predetermined time period from the statistics event for a time increment comprising the time period. A call setup and service providing method through a hybrid communication network including a switched communication network and a packet transmission network, (a) storing in a memory a call parameter database having profile information belonging to a subscriber of said hybrid communication system; (b) receiving a call at the system; (c) accessing the call parameter database to determine at least one call parameter; (d) routing the call through the switched communication network and the packet transport network based on at least one call parameter; (e) executing the logic defined by the profile information to provide personalized service functions for a subscriber belonging to the propie information. 234. The method of claim 234 wherein And the logic selects and executes at least one service of the hybrid communication system. 234. The method of claim 234 wherein And the logic further performs a function defined based on at least one network statistic or call context information. 236. The method of claim 236 wherein The defined function includes at least one fraud detection or customer call volume statistics. 234. The method of claim 234 wherein And the logic further provides a low level functional capability or computational resource for at least one system service delivery, monitoring, or management. 234. The method of claim 234 wherein and (f) providing network-based capabilities including at least one internet-to-speech conversion, DTMF detection, facsimile recognition, or speech recognition. 234. The method of claim 234 wherein (f) receiving network event records and service events in real time from a calling context server; (g) accepting a query for data received by the call context server. 232. The method of claim 230, and (h) providing, by the call context server, the import manager with combined event information for a call or other network transaction. 234. The method of claim 234 wherein (f) accepting a statistical event; and (h) accepting a query for the accepted data. 242. The method of claim 242, Compiling a statistical event for a predetermined time period from the statistical event for a time increment comprising a time interval. A computer program stored on a medium readable by a computer that sets up a call and provides a service through a hybrid communication network including a switched communication network and a packet transport network, (a) first software for storing a calling parameter database in memory with profile information belonging to subscribers of said hybrid communication system; (b) second software for accessing the call parameter database when the system receives a call to determine at least one call parameter; (c) third software for routing the call through the switched communication network and the packet transport network based on at least one call parameter; (d) a computer program comprising fourth software for executing logic defined by the profile information to provide personalized service functions for a subscriber belonging to the profile information. 244. The method of claim 244, And the logic selects and executes at least one service of the hybrid communication system. The method of claim 21, And the logic further performs a function defined based on at least one network statistics or call context information. 246. The method of claim 246 The defined function includes at least one fraud detection or customer call volume statistic. 244. The method of claim 244, Wherein said logic further provides a low level functional capability or computational resource for at least one system service delivery, monitoring, or management. 244. The method of claim 244, (f) computer program further comprising fifth software to provide network-based capabilities including at least one internet-to-speech conversion, DTMF detection, facsimile recognition or speech recognition. 244. The method of claim 244, (f) fifth software for receiving network event records and service events in real time into a calling context server; (g) a sixth software for accepting queries for data received by the call context server. 252. The method of claim 250, (h) a seventh software for providing combined event information for a call or other network transaction from said call context server to an import manager. 244. The method of claim 244, (f) fifth software for accepting statistical events; (g) computer program further comprising sixth software for accepting a query for the received data. 252. The method of claim 252, wherein (h) computer program further comprising seventh software for compiling the statistical event for a predetermined time period from the statistical event for a time increment comprising the time period. As a media communication method through a hybrid network, (a) recording video, audio and / or data communications; (b) transmitting, through the hybrid network, the video, audio and / or data communications to one or more locations associated with one or more designated recipients; (c) storing the video, audio and / or data communications in the storage location (s) associated with the designated recipient customer (s); (d) transmitting said video, audio and / or data communications via said hybrid network to respective designated recipients at the request of each designated recipient. 253. The method of claim 254 (a) allowing a consumer to record a personnel communication comprising video, audio and / or data information; (b) sending said personnel communications via said hybrid network to a storage location associated with said consumer; (c) storing the greeting communication in a storage location associated with the consumer; (d) sending personnel communications from the storage location to other consumers attempting to communicate with the consumer associated with the personnel communications via the hybrid network. 254. The method of claim 254 And a consumer accesses said communication stored in said designated storage location from a user interface system. 254. The method of claim 254 A method of media communication via a hybrid network in which a consumer accesses the communication stored in the designated storage location with the help of a human or autoresponder operator or agent. 254. The method of claim 254 And wherein said communication is automatically sent to said storage location associated with a designated recipient consumer if the recipient consumer cannot participate in live communication. 255. The method of claim 255, And wherein said personnel communication is automatically sent to a consumer who is about to communicate with a consumer associated with said personnel communications if a consumer associated with said personnel communications cannot participate in live communications. As a media communication method through a hybrid network, (a) generating data pertaining to media communication via the hybrid network; (b) storing the data in a distributed database; (c) partitioning the data into physical subsets at a plurality of storage sites in a distributed database; (d) presenting an application for accessing or updating data with a logical view of a single coherent database despite the plurality of storage sites. 260. The method of claim 260, And the data belonging to the media communication includes information about an application inside the hybrid network. 260. The method of claim 260, And the data belonging to said media communication comprises information about an application outside said hybrid network. 260. The method of claim 260, And the data to which said media communication belongs comprises monitoring information about said hybrid network. 260. The method of claim 260, And the data belonging to said media communication comprises information used to control said hybrid network. 260. The method of claim 260, And data pertaining to a change of data stored in the database in which data belonging to the media communication is provided. 260. The method of claim 260, And data pertaining to addition of data stored in the database is data belonging to the media communication. 260. The method of claim 260, And data pertaining to deletion of data stored in the database is included in the media communication. 260. The method of claim 260, Presenting an application to access and update data in a logical view of a single coherent database (a) setting a data location; (b) allocating storage and memory; (c) loading the data store; (d) optimizing the data access and update path. As a media communication device through a hybrid network, (a) a processor having control software for generating data pertaining to media communications over a hybrid network; (b) a storage unit connected to the hybrid network in which data belonging to the hybrid network is stored; (c) control software for partitioning data into physical subsets at a plurality of storage sites in a distributed database; and (d) control software presenting an application for accessing or updating data with a logical view of a single coherent database despite the plurality of storage sites. 270. The method of claim 269, And the data belonging to the media communication includes information about an application inside the hybrid network. 270. The method of claim 269, And the data belonging to said media communication comprises information relating to an application outside said hybrid network. 270. The method of claim 269, And the data to which the media communication belongs comprises monitoring information about the hybrid network. 270. The method of claim 269, And the data belonging to the media communication comprises information used to control the hybrid network. 270. The method of claim 269, And the data pertaining to the media communication includes information regarding a change in data stored in the database. 270. The method of claim 269, And data pertaining to addition of data stored in the database in which data pertaining to the media communication. 270. The method of claim 269, And data pertaining to deletion of data stored in the database from data belonging to the media communication. 270. The method of claim 269, Control software presenting an application for accessing or updating data with a logical view of a single coherent database despite the plurality of storage sites (a) control software for setting a data location; (b) control software for allocating storage and memory; (c) control software for loading data storage; (d) a media communication device having control software for optimizing data access and update paths. A computer program stored on a medium readable by a computer for media communication via a hybrid network, (a) first software for generating data pertaining to the media communication via a hybrid network; (b) second software for storing the data in a distributed database; (c) third software for partitioning data into physical subsets at a plurality of storage sites in a distributed database; (d) a computer program comprising fourth software presenting an application for accessing or updating data with a logical view of a single coherent database despite the plurality of storage sites. The method of claim 278, And the data belonging to said media communication comprises information about an application inside said hybrid network. The method of claim 19, And the data belonging to said media communication comprises information relating to an application outside said hybrid network. The method of claim 278, And the data to which said media communication belongs comprises monitoring information about said hybrid network. The method of claim 278, Computer information comprising information used to control the hybrid network data belonging to the media communication. The method of claim 278, And the data pertaining to the media communication includes information regarding a change in data stored in the database. The method of claim 278, And the data pertaining to the media communication includes information regarding addition of data stored in the database. The method of claim 278, And data relating to deletion of data stored in the database in which data pertaining to the media communication. The method of claim 278, A fourth piece of software that presents an application to access or update data in a logical view of a single coherent database (a) fifth software for setting a data location; (b) sixth software for allocating storage and memory; (c) seventh software for loading data storage; (d) a computer program comprising eighth software for optimizing data access and update paths. As a hybrid communication system, (a) a switching communication network; (b) a packet transport network coupled to the switching communication network; (c) a call router coupled to the switching communication network and the packet transport network; (d) a gateway in communication with the calling router, the gateway configured to provide a file transfer service to a user connected to the switching communication network. 282. The method of claim 287, wherein And an authentication server, wherein the identity of the user is authenticated by the authentication server. 282. The method of claim 287, wherein Further comprising an outer packet filter coupled to the calling router, wherein the gateway server is coupled to the outer packet filter, where the outer packet filter is configured to only accept communications originating from a set of addresses. . 282. The method of claim 287, wherein The gateway server is configured to provide only read-only transport services. 282. The method of claim 287, wherein And a process token ring network in communication with the gateway server. 303. The method of claim 291 wherein And an inner packet filter coupled to the process token ring network, wherein the gateway server is coupled to the inner packet filter, wherein the inner packet filter is configured to only accept communications originating from a set of addresses. . A method of establishing a call through a hybrid communication system comprising a switching communication network and a packet transport network, (a) storing the call parameter database in memory; (b) setting a system configuration of the hybrid communication system; (c) receiving a call at the system; (d) accessing the call parameter database to determine at least one call parameter; (e) routing the call to a gateway server via the switching communication network and the packet transport network based on at least one call parameter. 303. The method of claim 293 wherein (f) communicating with the authentication server to authenticate the origination of the call. 303. The method of claim 293 wherein (f) selectively filtering communications through an outer packet filter, wherein the outer packet filter is configured to only accept communications originating from a predetermined set of addresses. 303. The method of claim 293 wherein The gateway server is configured to provide only read-only file transfer services. A computer program contained in a computer readable medium for establishing a call and providing a service through a hybrid communication system including a switching communication network and a packet transmission network. (a) first software for storing a calling parameter database in memory; (b) second software for setting a system configuration of the hybrid communication system; (c) third software for receiving a call in the system; (d) fourth software for accessing the call parameter database to determine at least one call parameter; (e) a fifth program for routing said call based on at least one call parameter to said gateway server through said switching communication network and said packet transfer network. 297. The method of claim 297, (f) computer program further comprising sixth software in communication with the authentication server to authenticate the origination of the call. 297. The method of claim 297, (f) further comprising sixth software for selectively filtering communications through an outer packet filter, wherein the outer packet filter is configured to only accept communications originating from a set of addresses. 297. The method of claim 297, The gateway server is configured to provide only read-only file transfer services. As a hybrid switch for communication systems, (a) at least one switching network interface; (b) at least one internet interface; (c) a bus coupling said at least one switching network interface and said at least one internet interface; (d) a hybrid switch for a communication system having a host processor coupled to the bus. 301. The method of claim 301, wherein At least one of the interfaces is received at the at least one interface to the host processor to select one of the at least one interface as an output interface for a call associated with the call processing instruction and received at the at least one interface. Hybrid switch configured to send scheduled call processing instructions. 302. The method of claim 302 The host computer is further configured to query an Internet service control point coupled to the at least one internet interface for a routing indication. 302. The method of claim 302 And the host computer is further configured to locally derive routing instructions. 301. The method of claim 301, wherein And at least one digital signal processor coupled to the bus. As a hybrid communication system, (a) the hybrid switch of claim 301; (b) at least one switching network coupled to the hybrid switch; (c) a hybrid communication system having at least one internet coupled to the hybrid switch. 307. The method of claim 306, (a) at least one echo canceller coupled to the hybrid switch. 307. The method of claim 306, (a) at least one signal demultiplexer coupled to the hybrid switch. 307. The method of claim 306, At least one optical fiber cable coupled to the hybrid switch. 307. The method of claim 306, (a) at least one modem coupled to the hybrid switch. 307. The method of claim 306, (a) further comprising at least one full switching matrix coupled to the hybrid switch, wherein the system is configured to dynamically establish a connection through the full switching matrix based on characteristics of a call received at one of the at least one interface. Hybrid communication system configured. 307. The method of claim 306, (a) a hybrid communication system, further comprising a plurality of plug and play modules for coupling communication peripherals in one call. As a communication processing method in a hybrid switch, (a) receiving a call processing instruction associated with a particular port of the hybrid switch; (b) receiving communication at a port of the hybrid switch associated with the call processing instruction; (c) coupling a suitable plug and play module specific to the call processing instruction to a particular port of the hybrid switch to process the communication. 313. The method of claim 313 wherein (a) sending the call processing instruction to a host processor to select a particular port of the hybrid switch as an output port for a call associated with the call processing instruction; (b) routing the call to an output port. 314. The method of claim 314 wherein (a) querying an internet service control point coupled to the hybrid switch with the host processor for a routing instruction. 314. The method of claim 314 wherein And the host processor locally derives routing instructions. 314. The method of claim 314 wherein A port for receiving the call and one of the output ports is coupled to a switching network and to a port for receiving the call or another of the output ports. 314. The method of claim 314 wherein At least one fiber optic cable coupled to the port receiving the call or to the output port. 313. The method of claim 313 wherein And said plug and play module is a digital signal processor. 313. The method of claim 313 wherein And the plug and play module is an echo canceller. 313. The method of claim 313 wherein And said plug and play module is a signal demultiplexer. 313. The method of claim 313 wherein And said plug and play module is a modem. 313. The method of claim 313 wherein And the plug and play module is dynamically coupled to a particular port of the hybrid switch by a full switching matrix. A computer program on a computer readable medium for processing communication in a hybrid switch, (a) first software to receive call processing instructions associated with a particular port of the hybrid switch; (b) second software for receiving communication at a port of the hybrid switch associated with the call processing instruction; (c) computer program comprising third software for coupling a suitable plug and play module specific to the call processing instruction to a particular port of the hybrid switch to process communication. 325. The method of claim 324 wherein (a) fourth software for transmitting said call processing instruction to a host processor for selecting a particular port of said hybrid switch as an output port for a call associated with said call processing instruction; (b) further comprising fifth software for routing the call to an output port. 325. The method of claim 325 wherein (a) a sixth software for querying an internet service control point coupled to the hybrid switch with the host processor for routing instructions. 325. The method of claim 325 wherein (a) computer program further comprising sixth software for locally directing routing instructions to the host processor. 325. The method of claim 325 wherein Wherein the first and fifth software are configured to receive the call and route the call from / to a switching network or the Internet, respectively. 325. The method of claim 325 wherein Wherein the first and fifth software are configured to receive a call from and to a fiber optic cable and to route the call. 325. The method of claim 325 wherein The third software is configured to couple a digital signal processor to the specific port. 325. The method of claim 325 wherein The third software is configured to couple an echo canceller to the particular port. 325. The method of claim 325 wherein The third software is configured to couple a signal demultiplexer to the specific port. 325. The method of claim 325 wherein The third software is configured to couple a modem to the specific port. 325. The method of claim 325 wherein The third software is configured to dynamically couple the plug and play module to the specific port via a full switching matrix. As a communication system, (a) one or more switching communication networks; (b) one or more packet transport networks; (c) a prioritized access router coupled to the switching communication network and the packet transport network; (d) a memory coupled to the prioritized access router and having a service control parameter database stored therein, wherein the prioritized access router includes a plurality of functions, each function of the service control parameter database; And route data through the switching communication network and the packet transport network based on at least one service control parameter from the network, wherein the prioritized access router is based on at least one control parameter from the service control parameter database. Communication system that delivers some data on each network interface before other data. 335. The method of claim 335 The plurality of functions includes an arrangement of modulation / demodulation (modem) equipment for transmitting and receiving data over a standard telephone line. 335. The method of claim 335 The multiple functions include 10BaseT Ethernet, 100BaseT Ethernet, Coaxial Ethernet, Gigabit Ethernet, Isochronous Ethernet, Fiber Distributed Data Interface (FDDI), Asynchronous Transfer Mode (ATM), X.25, Frame Relay and Switching. A communication system comprising an array of standard data network interface equipment, including but not limited to multimegabart data services. 335. The method of claim 335 The plurality of functions includes the use of a conversion function capable of converting a packet utilizing a Point-to-Point Protocol (PPP) to Internet Protocol (IP) and vice versa. 335. The method of claim 335 The plurality of functions includes the use of a packet classification function capable of classifying packets into groups according to a criterion. 344. The method of claim 339 wherein The packet classification function classifies a packet according to a destination IP address. 344. The method of claim 339 wherein The packet classification function classifies packets according to originating IP addresses. 344. The method of claim 339 wherein The packet classification function classifies a packet according to a destination user datagram protocol (UDP) port number. 344. The method of claim 339 wherein The packet classification function classifies a packet according to an outgoing UDP port number. 343. The communication system according to claim 339, wherein said packet classification function classifies packets according to a destination Telnet control protocol port number. 344. The method of claim 339 wherein The packet classification function classifies the packet according to the originating Telnet control protocol port number. 344. The method of claim 339 wherein The packet classification function classifies packets according to flow levels. 344. The method of claim 339 wherein The packet classification function classifies a packet according to a tag. 344. The method of claim 339 wherein The packet classification function classifies a packet according to an originating user ID. 344. The method of claim 339 wherein The packet classification function classifies a packet according to an originating user ID. 344. The method of claim 339 wherein The packet classification function classifies a packet according to a destination user ID. 344. The method of claim 339 wherein The packet classification function classifies a packet according to some defined data field in the packet. 335. The method of claim 335 Wherein the plurality of functions comprises an arrangement of a packet scheduler. 352. The method of claim 352 wherein The packet scheduler is configured to queue the packet first according to packet classification and service control parameters. 354. The method of claim 353, wherein Wherein said priority queue orders packets for transmission over a network interface. 354. The method of claim 353, wherein Wherein said priority queue orders packets for transmission over a modem interface. 335. The method of claim 335 Wherein said plurality of functions comprises a control function. 356. The method of claim 356, And the control function receives a control command through an application program interface. 356. The method of claim 356, And the control function can accept or reject a control command based on a defined policy. 356. The method of claim 356, And the control function may accept or reject a control command based on resource availability. 356. The method of claim 356, And the control function may accept or reject a control command based on a privilege granted to the requesting entity. A computer program contained on a computer readable medium for prioritizing and routing media transmissions through a hybrid network comprising one or more switching networks coupled to one or more packet transport networks, (a) first software for prioritizing access and routing between the switching communication network and the packet transmission network; (b) storing a service control parameter database in a memory coupled to the first software including a plurality of functions, wherein each function is based on at least one service control parameter from the service control parameter database. Configured to route data through a switching communication network and the packet transport network, the logic including delivering some data of each network interface before other data based on at least one service control parameter from the service control parameter database. Computer programs. As a communication system, (a) a switching communication network; (b) a packet transmission network coupled to the switching communication network; (c) a user terminal coupled to the switching communication network, the packet transport network, or both; (d) one or more calling routers coupled to the switching communication network and the packet transport network; (e) a memory coupled to each call router, the memory having a call parameter database stored therein, each call router configured to communicate with the switching communication network based on at least one call parameter from the call parameter database. Configured to route calls through the packet transport network, the call router is configured to provide an intelligent service platform, the intelligent service platform having a plurality of functions available from a single connection, (f) a gateway for coupling the packet transmission network with the switching communication network; (g) a call queue manager coupled to the packet transmission network; (h) an automatic call distributor (ACD) coupled to the switching communications network; (i) an ACD controller coupled to the ACD; (j) an agent workstation coupled to the switching communication network via the ACD and coupled to the packet transport network. 372. The method of claim 362, wherein Wherein the plurality of functions include at least one of user profile management, information service profile management, address translation, admission control, resource management, topology tracking, statistics collection, utilization, billing data logging, message retrieval, and message distribution. 372. The method of claim 362, wherein The user terminal configured to browse the World Wide Web. 372. The method of claim 362, wherein And wherein said user terminal is comprised of software and hardware that enable an attempt to interactive voice or multimedia conversation. The method of claim 365, And a calling router routes the interactive voice or multimedia conversation to a gateway. 366. The method of claim 366, wherein And the gateway attempts a corresponding interactive voice or multimedia conversation over the switching communication network. 367. The method of claim 367, wherein And a calling router routes the corresponding interactive voice or multimedia conversation to an ACD. 375. The method of claim 368, wherein Gateway signal information to the ACD may include confirmation of the originator of the conversation, verification of the originating user terminal, verification of the originating gateway, verification of one or more browsed web pages, verification of the intended destination address, verification of the intended destination user, and interactive voice. At least one of a unique confirmation of the conversation. 369. The method of claim 369, wherein And the ACD delivers signal information to the ACD controller. 370. The method of claim 370 wherein The ACD controller using any available resources on the packet transport network or the switching communication network forms a display screen. 374. The method of claim 371, And the ACD controller delivers the display screen to an agent workstation. 374. The method of claim 371, And the ACD controller sends the interactive voice or multimedia conversation to the agent workstation. 373. The method of claim 373, wherein And the agent workstation enables voice or multimedia interaction with the originating user terminal via the packet transfer network and the switching communication network. As a communication system, (a) a switching communication network; (b) a packet transmission network coupled to the switching communication network; (c) a user terminal coupled to the switching communication network, the packet transport network, or both; (d) one or more calling routers coupled to the switching communication network and the packet transport network; (e) a memory coupled to each call router, the memory having a call parameter database stored therein, each call router configured to communicate with the switching communication network based on at least one call parameter from the call parameter database. Configured to route calls through the packet transport network, the call router is configured to provide an intelligent service platform, the intelligent service platform having a plurality of functions available from a single connection, (f) a gateway for coupling the packet transmission network with the switching communication network; (g) a call queue manager coupled to the packet transmission network; (h) an automatic call distributor (ACD) coupled to the switching communications network; (i) an ACD controller coupled to the ACD; (j) a voice response unit coupled to the ACD; (k) an agent workstation coupled to the switching communication network via the ACD and coupled to the packet transport network. 375. The method of claim 375, Wherein the plurality of functions include at least one of user profile management, information service profile management, address translation, admission control, resource management, topology tracking, statistics collection, utilization, billing data logging, message retrieval, and message distribution. 375. The method of claim 375, The user terminal configured to browse the World Wide Web. 375. The method of claim 375, And wherein said user terminal is comprised of software and hardware that enable an attempt to interactive voice or multimedia conversation. 378. The method of claim 378, wherein And a calling router routes the interactive voice or multimedia conversation to a gateway. 379. The method of claim 379, wherein And the gateway attempts a corresponding interactive voice or multimedia conversation over the switching communication network. 380. The method of claim 380, And a calling router routes the corresponding interactive voice or multimedia conversation to an ACD. 383. The method of claim 381; And the ACD connects the interactive voice or multimedia conversation to a voice response unit (VRU). 383. The method of claim 382 Gateway signaling information to the VRU may include confirmation of the originator of the conversation, verification of the originating user terminal, verification of the originating gateway, verification of one or more browsed web pages, verification of the intended destination address, verification of the intended destination user, and interactive voice. A communication system comprising at least one of a unique confirmation of a conversation. 383. The method of claim 383, And the VRU delivers signal information to the ACD controller. 384. The method of claim 384, The ACD controller using any available resources on the packet transport network or the switching communication network forms a display screen. 385. The method of claim 385, wherein And the ACD controller delivers the display screen to an agent workstation. 383. The method of claim 381; The ACD controller sends the interactive voice or multimedia conversation to the agent workstation. 387. The method of claim 387, wherein And the agent workstation enables voice or multimedia interaction with the originating user terminal via the packet transfer network and the switching communication network.