Abstract:
A control process controls transmission of digitally encoded messages (DEMs) over a data communications network to allow real-time performance. The control process establishes a communication path which DEMs are sent. The control process can operate according to any data communications protocol, including the protocol native to the communicating device. The control process can establish communication paths based upon least-cost routing determinations. When there is insufficient bandwidth or excessive latency, the control process can choose a secondary path over which to transmit a DEM.

Description:
[0001]    This application is a continuation-in-part of application Ser. No. 08/582,475, filed on Jan. 4, 1996, which is a continuation of application Ser. No. 08/529,923, filed on Sep. 18, 1995, which is hereby incorporated by reference in its entirety.  
     
    
     
       COPYRIGHT  
         [0002]    A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.  
           [0003]    The portion subject to copyright protection has been defined by placing one copyright notice just prior to the beginning of the copyrighted portion, and placing a second copyright notice just after the end of the copyrighted portion.  
         BACKGROUND  
         [0004]    1. Field of the Invention  
           [0005]    The present invention relates to real-time distribution of digitally encoded messages over a data network, such as the Internet. More specifically, the present invention relates to a system and method for controlling transmission of digitally encoded messages using any desired communication protocol, including the native protocol of the communicating devices.  
           [0006]    2. Background of the Invention  
           [0007]    [0007]FIG. 1 is a schematic diagram of a prior art system  101  for real-time transmission of digitally encoded messages (DEMs). Where MCDs  102  and  106  are fax machines, for example, the DEMs are fax messages. MCD  102  sends a DEM to MCD  106 . MCD  102  sends telephony data representative of a DEM to a public-switched telephone network (PSTN)  104  over line  108  using the T.30 protocol. Likewise, the PSTN transmits the telephony data to MCD  106  over line  110  using the T.30 protocol.  
           [0008]    The PSTN  104  of system  101  has two attributes that facilitate transmission of DEMs. First, the PSTN  104  provides a guaranteed bandwidth. Once a connection is made, MCD  102  and MCD  106  communicate using the full bandwidth allocated to the telephony connection provided by the PSTN  104 . Second, there is a guaranteed latency between the time that MCD  102  sends the telephony data and the time MCD  106  receives the telephony data.  
           [0009]    The PSTN-based transmission of DEMs suffers from several disadvantages. First, long distance charges must often be incurred in completing the DEM transmission from MCD  102  to MCD  106 . Second, the bandwidth of the telephony connection is limited relative to other forms of communication such as communication over data networks. Third, even with full bandwidth of the telephony connection available, many data transfer protocols (for example, fax) can be conducted using less than one tenth—and are designed to use no more than one half—of the full bandwidth available.  
           [0010]    To avoid the disadvantages associated with system  101 , DEMs have been transmitted over data communication networks, for example, the Internet. FIG. 2 illustrates a schematic of a prior art system  241  for transmitting DEMs over a data network. In system  241 , MCD  242  transmits telephony data representative of a DEM to a server  244  over line  250  using the T.30 protocol. Server  244  is assumed to be equipped with a data conversion card (not shown) to convert the telephony data to computer data. Server  244  transmits the computer data to a server  246  over line  252  using the TCP/IP protocol. Line  252  represents a computer network, for example the Internet. The server  246  converts the computer data to telephony data using a card (not shown). The telephony data is transmitted to MCD  248  over line  254  using the T.30 protocol.  
           [0011]    There are two disadvantages associated with system  241 . First, there is no guaranteed bandwidth. Although a computer network is capable of providing greater bandwidth than a telephony-based system, there is no guarantee that any bandwidth will be available when it is needed, unless, possibly, the network is dedicated to the transmission of DEMs. Second, there is no guaranteed minimum latency. Thus, there is no guarantee that a DEM sent by MCD  242  will reach MCD  248  within any minimum delay. This is problematic with many DEM transmissions because the MCD  242  and MCD  248  generally must maintain synchronization with one another. For example, where MCDs  242  and  248  are fax machines, they must resynchronize with one another at the end of each transmitted page. For fax machines, this resynchronization must occur within 5 to 7 seconds. If the required resynchronization does not occur within the required time frame, MCDs  242  and  248  will assume that the connection has been lost and they will hang up. Unfortunately, latency over a data network such as the Internet can be on the order of 30 seconds or more. Thus, the prior art system  241  will likely cause disrupted DEM delivery due to lost connections resulting from loss of synchronization because no minimum latency can be guaranteed.  
         DEFINITIONS  
         [0012]    “DEM,” as used herein, shall mean digitally encoded message.  
           [0013]    “MCD,” as used herein, shall mean message communicating device. A facsimile machine is one example of an MCD.  
           [0014]    “PSTN,” as used herein, shall mean public-switched telephone network.  
           [0015]    “DCN,” as used herein, shall mean data communications network, including, but not limited to, wide area networks, intracompany networks, intercompany networks and other internodal networks such as the Internet.  
         SUMMARY OF THE INVENTION  
         [0016]    The present invention solves the problems associated with conventional systems by providing a control process to handle the protocol among nodes transferring DEMs over a data communications network. The control processes on the various nodes communicate with one another to determine any particular node&#39;s availability for message communication. If a connection is made for message communication, the control processes on the communicating nodes control message transfer according to a particular protocol, and transfer the DEMs over the DCN in real time. The protocol can be any data communications protocol, including the data communications protocol native to the communicating devices.  
           [0017]    The control process in the preferred embodiment includes a parent process and a child process. The parent process is responsible for managing communication between nodes, i.e., the parent process is responsible for managing the DCN aspects of a DEM communication. DEM communication is also referred to herein as a DEM transaction. Thus, the parent process isolates the child process from DCN related functions. The child process controls the hardware aspects of a DEM communication. This control includes managing telephony hardware and performing any telephony related functions. The child process, therefore isolates the parent process from the hardware aspects of DEM communication. Preferably, the child process communicates with a particular MCD using its native protocol. The parent and child work together according to a protocol to ensure that DEM communications are established within the latency time required to maintain synchronization.  
           [0018]    When DEMs cannot be transmitted over the data communications network, the control process attempts to route DEMs over a secondary path. The secondary path is also a data network. Thus, the bandwidth and cost advantages associated with transmitting DEMs using data networks rather than telephony lines are preserved. In addition, the secondary path provides an auxiliary route for DEMs when they cannot be immediately transmitted over the primary DCN.  
           [0019]    The secondary path of the preferred embodiment includes two store-and-forward servers. The first store-and-forward server is operatively coupled to a DEM server on the sending side of the data network. The second store-and-forward server is operatively coupled to a DEM server on the receiving side, and also to the first store-and-forward server. In operation, when the primary path is unavailable, the sending-side DEM server transmits DEMs from the sender MCD to the first store-and-forward processor, where they are stored. Subsequently, the first store-and-forward processor delivers the DEM to the second store-and-forward processor. The second store-and-forward processor then sends the DEM to the receiver-side DEM server where it will be delivered to a receiver MCD.  
           [0020]    The secondary path for DEM transmission allows the present invention to complete DEM transmission in real-time when the primary path is unavailable for DEM transmission.  
           [0021]    Thus, one objective of the present invention is to provide a minimum guaranteed latency between the time that a digitally encoded message is sent over a DCN and the time that it is received.  
           [0022]    Another object of the present invention is to provide real-time transmission of digitally encoded messages.  
           [0023]    Yet another object of the present invention is to provide cost-efficient digitally encoded message transmission in real-time using least-cost routing techniques.  
           [0024]    Another object of the present invention is to provide communications over a DCN using any desired protocol, including the native protocol of the communicating devices.  
           [0025]    Another objective of the present invention is to provide a backup communications option, such that it the real-time attempt fails for any reason, the sender has the option to allow a store-and-forward attempt to deliver a message along a secondary path.  
           [0026]    These and other objects of the present invention are described in greater detail in the detailed description of the invention, the appended drawings and the attached claims.  
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0027]    [0027]FIG. 1 is a schematic diagram of a prior art system for real-time transmission of DEMs using a PSTN.  
         [0028]    [0028]FIG. 2 is a schematic diagram of a prior art system for transmitting DEMs over a data communication network  
         [0029]    [0029]FIG. 3 is a schematic representation of a system operating in accordance with the present invention.  
         [0030]    [0030]FIG. 4 is a schematic diagram of a control process for transmitting DEMs over a DCN.  
         [0031]    [0031]FIG. 5 is a state diagram of the states that a lineman child assumed when a lineman child is given notification that a call is inbound.  
         [0032]    [0032]FIG. 6 is a state diagram of the states which lineman child assumes when lineman parent notifies the child that an outbound call is required.  
         [0033]    [0033]FIG. 7 is a schematic diagram of the interconnections on a local lineman  
     
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0034]    [0034]FIG. 3 is a schematic representation of a system  301  operating in accordance with the present invention. An MCD  3   s  is operatively coupled to a DEM server  304  over connection  310 . The DEM server  304  is operatively coupled to a store-and-forward server  316  over connection  320 . The store-and-forward server  316  is operatively coupled to a store-and-forward server  318  over connection  324 . The store-and-forward server  318  is operatively coupled to a DEM server  306  over connection  322 . The DEM server  306  is operatively coupled to DEM server  304  and MCD  3   r.  DEM servers  304  and  306  are preferably general purpose computers that have processes executing thereon to carry out the functions of the present invention. It would be apparent to those skilled in the art how to program such general purpose computers to carry out the functions described herein. The data connections  312 ,  320 ,  322  and  324  can conform to any communications protocol for digital data. Such communication protocols include TCP/IP and T.30.  
         [0035]    In operation, a DEM is generated using MCD  3   s.  MCD  3   s  transmits the DEM to DEM server  304 . In the preferred embodiment, MCD  3   s  is a fax machine. Thus, the transmitted data can be telephony data. In such case, the telephony data must first be converted to digital data. In the preferred embodiment, DEM server  304  converts the telephony data to digital data for transmission over a data network. The conversion can be performed by well-known hardware and/or software designed to convert telephony data to digital data. The DEM is transmitted over the data network to DEM server  306 . If required, the DEM server  306  converts the DEM data to telephony data representative of the DEM. The telephony data is then transmitted to MCD  3   r.    
         [0036]    More sophisticated MCDs can convert the telephony data representative of the DEM internally or can communicate digitally by directly using digital representations of the DEM. These more sophisticated DEMs can transmit the DEM data directly over the network without the DEM server  304 . Similarly, more sophisticated MCDs have the capability to receive the DEM without prior conversion to telephony data representative of the DEM. The functions described herein can be programmed into more sophisticated MCDs, which precludes the need for a separate DEM servers  304  and  306 .  
         [0037]    In the preferred embodiment, MCDs  3   s  and  3   r  are fax machines. To communicate correctly MCD  3   s  and MCD  3   r  must maintain synchronization. If synchronization is lost, the communication link between MCD  3   s  and MCD  3   r  is broken and the fax machines hang up. Any fax transmission occurring at the time of the hangup is lost. There is no guaranteed minimum latency time for DEM transmission over the connection  312 . Connection  312  is representative of a DCN. For example, where connection  312  is the Internet, a DEM transmitted by DEM server  304  can take seconds, minutes, or hours to reach DEM server  306 . As a result connections are often lost.  
         [0038]    The present invention executes a novel control process alternately referred to as a lineman herein. The lineman is a process that executes on each DEM server in the system to control transmission of DEMs over the DCN. Using the lineman, the present invention allows communication using any data communications protocol, including the protocol native to the communicating devices. Where the communicating devices are fax machines, for example, the protocol can be the well-known T.30 protocol.  
         [0039]    [0039]FIG. 4 is a schematic of the lineman control process of the present invention. As illustrated in FIG. 4, lineman  401  includes a lineman parent  402 , a lineman child  404  and a lineman director  406 . In the preferred embodiment, the control process  401  can include a hardware API  407 , a message handler  408 , a Web server  410  and a monitor process  412 .  
         [0040]    Lineman director  406  is the controls allocation of available data communication ports on the DEM server on which it resides. Lineman director  406  determines which, if any, local data communication port is available to handle the outbound portion of a real-time DEM transaction. Lineman director  406  must make this determination quickly to avoid loss of synchronization during the DEM transaction.  
         [0041]    In the preferred embodiment, lineman director  406  executes the following procedure to make its determination. The lineman  406  monitors a request port for incoming connection requests. In the preferred embodiment, this is a dedicated TCP/IP port to which remote linemen attempt to connect when they desire to initiate a DEM transaction with the local lineman. Remote linemen decide which local linemen is the correct lineman based on the output of their routing tables (described below). Lineman director  406  does not challenge this decision. Rather, it attempts to complete the transaction.  
         [0042]    Once lineman  406  detects an incoming connection request on the dedicated request port, it must locate and reserve an available data communications port. It must locate and reserve the available data communications port quickly to avoid a synchronization loss to some other activity and must configure the available data communications port for outbound service.  
         [0043]    If there is an available data communications port, lineman director  406  passes the new connection to the lineman parent  402 . After the “pass off,” lineman director  406  is no longer responsible for the connection. In the preferred embodiment, this “pass off” is handled by passing a file handler from lineman director  406  to lineman parent  402 .  
         [0044]    If there is no data communications port available, lineman director  406  must signal the calling lineman to inform it that there are no available data communication ports. Lineman director  406  then drops the connection. The calling lineman can then route the DEM using the secondary path described below to complete the transaction.  
         [0045]    Lineman parent  402  controls the network side of a real-time DEM transaction. Lineman parent  402  separates the lineman child  404  from the network portion of the system. Lineman parent  402  is responsible for managing communications between itself and a like lineman parent of a remote lineman executing on a remote DEM server. The two lineman parents work in conjunction with one another to conduct the network half of a real-time DEM transaction. In the preferred embodiment lineman parent  402  communicates with lineman child  404  using conventional pipes.  
         [0046]    Lineman child  404  controls the physical side of the real-time DEM transaction. Lineman child  404  separates lineman parent  402  from the hardware specific portion of the system. Lineman child  404  is responsible for conducting communication with the hardware using any protocol, including the hardware&#39;s native protocol. In the preferred embodiment, where the communicating MCDs are fax machines, lineman child  404  performs telephony control according to the well-known T.30 protocol. In the preferred embodiment, this telephony control includes detecting inbound ring, managing the telephony interface, making outbound calls and conducting the T.30 protocol. Any other required hardware control is performed by lineman child  404 .  
         [0047]    The preferred embodiment includes a Hardware API  407 . The hardware API  407  contains all of the code and drivers necessary to interface with the resident fax/telephony hardware. In the preferred embodiment, lineman child  404  uses hardware API  407  to manage the physical fax channel. Hardware API  407  performs the following functions: (1) port selection, (2) inbound call direction; (3) outbound call generation; (4) DTMF tone generation and detection; (5) T.30 protocol negotiation; and (6) fax data transmission.  
         [0048]    The message handler  408  is a local daemon responsible for interacting with the main message server. In the preferred embodiment, the main message server is a centralized message server which is responsible for maintaining system-wide activity logs and trouble reports. One key advantage of the present invention is that it can be used in a scalable architecture, while maintaining efficient DEM transmission over a DCN. As a result, it is not practical, nor desirable, for every process running on the lineman node to talk directly to the message server.  
         [0049]    The message handler  408  is a local process running on the lineman that buffers and filters messages and information directed to the message server. It forwards only those messages and information that meet desired criteria to the message server. By doing so, the message handler controls the content of information passed to the centralized message server, thereby limiting the amount of traffic. The message handler also multiplexes the various messages generated by the lineman processes onto a single pipe, thereby limiting the amount of networking resources required by it and the message server.  
         [0050]    In the preferred embodiment, message handler  408  is pre-configured to perform content thinning of messages to be sent to the message server. For example, a local administrator can enable or disable filters on each lineman process to limit the information that is sent to the message server. By default, in the preferred embodiment only error messages and transaction milestone messages are sent. For debugging purposes, however, more detailed messages can be enabled and sent.  
         [0051]    The monitor  412  is a local daemon that performs monitoring and housekeeping services for a particular lineman. In the preferred embodiment, monitor  412  performs two functions: (1) system state monitoring, and (2) local SNMP agent functionality. In system state monitoring, monitor  412  tracks the state of each configured component running on the lineman. Should any component fail, monitor  412  records this action and then attempts to restart the failed component. Monitor  412  also provides local SNMP functionality for those configurations where direct SNMP agent functionality is required on the lineman.  
         [0052]    The web server  410  in the preferred embodiment can be any conventional web server. Web server  410  is used to configure and troubleshoot the local lineman. Web server  410  provides a web-based view into the lineman. Using web server  410 , administrators can access logging, tracking, and trouble shooting interfaces from any conventional web browser, such as Netscape and Apache.  
         [0053]    The lineman parent  402  and lineman child  404  coordinating DEM transactions. In general, lineman parent  402  and lineman child  404  can allow DEM communication using any protocol to carry out the communication. This protocol can be the native protocol of the devices communicating with one another, for example two fax machines. Such protocols include the well-known T.30 and CCITT protocols.  
         [0054]    [0054]FIGS. 5 and 6 illustrate schematically a process by which DEMs are transmitted according to a preferred embodiment of the present invention in which DEMs are fax messages. FIG. 5 illustrates the states that the lineman child  404  assumes when a user initiates sending a DEM, and is connected to the hardware within the lineman. Initially, the lineman child  404  is in the idle state  502 . Upon an incoming call event, signified by a ringing signal, the lineman child  402  transitions to state  504 . From state  504 , lineman child  404  can answer the call by transitioning to state  506  or not answer the call by transitioning to state  518 . If the lineman child answers the call by transitioning to state  506 , it will then attempt to conduct a communication session using the T.30 protocol. After the session is set-up under the T.30 protocol, the lineman child  404  transitions to state  510  to begin acceptance of DEM transmissions. In the preferred embodiment, where the DEMs are facsimiles, the lineman child  404  transitions between states  510  and page confirmation state  512  until all pages of the facsimile have been accepted. When all pages of the facsimile have been accepted, i.e., acceptance of the DEM transmission is complete, the lineman child  404  transitions to state  514  to send an end of reception signal to indicate the end of DEM reception. The lineman child  404  then transitions to state  516  to terminate the telephone call. The lineman child  404  drops the call in state  518 , performs any necessary cleanup in state  520  and returns to idle state  502  to await the next incoming or outbound call to be processed. At any point in states  506 - 514 , an error or other event may cause communication to be disrupted resulting in a dropped call. If such an event should occur, the lineman child  404  drops the call in state  518 , performs any necessary cleanup in state  520  and returns to idle state  502  to await the next incoming or outbound call to be processed.  
         [0055]    [0055]FIG. 6 illustrates the states which lineman child  404  assumes when lineman parent  402  notifies the child that an outbound call is required. Initially, lineman child  404  is in idle state  602 . Upon lineman parent&#39;s  402  notification to place an outbound call, lineman child  404  transitions to state  604  where lineman child  404  attempts to place the required call. After dialing a connection is established in which case lineman child  404  transitions to state  606 , or the call is dropped in which case lineman child  404  transitions to state  618 . If a connection is established, lineman child  404  transitions to step  608  where it begins a T.30 communication session. Upon successful initiation of the T.30 session, lineman child  404  begins the DEM transmission. Transmission of each portion of the DEM transmission can be confirmed. For example, in the preferred embodiment, where the DEM is a facsimile, each page of the DEM is sent followed by a confirmation. Thus, lineman child  404  repeatedly executes states  610  and  612  until all of the pages in the DEM have been transmitted. When the entire DEM has been transmitted (e.g., all pages of a facsimile transmission), lineman child  404  transitions to state  614  in which it transmits an end of transmission signal. Lineman child  404  then terminates the call in state  616 , drops the call in state  618 , performs any required cleanup in state  620 , and transitions to idle state  602  to await the next incoming or outbound call to be processed. At any point in states  606 - 614 , an error or other event may cause communication to be disrupted resulting in a dropped call. If such an event should occur, the lineman child  404  drops the call in state  618 , performs any necessary cleanup in state  610  and returns to idle state  602  to await the next incoming or outbound call to be processed.  
         [0056]    [0056]FIG. 7 is a schematic diagram of the preferred interconnections on a local lineman  701 , and how the local lineman preferably connects to a remote lineman  703 . Remote lineman  703  contains a remote director  716  and a remote lineman parent  718 . In the preferred embodiment, remote lineman also contains at least a child lineman (not shown). As described above, the local lineman  701  contains a lineman child  404 , a lineman parent  402 , a lineman director  406 , and preferably a hardware API  407 . Referring to FIG. 3, for example, the local lineman executes on the sending DEM server  304  and the remote lineman executes on the receiving DEM server  306 .  
         [0057]    Referring back to FIG. 7, in the preferred embodiment, the lineman director  406  communicates with the lineman parent via a named-pipe  702 . A “pipe” is a well-known construct for interprocess communication. The lineman parent  402  communicates with the lineman child  409  through pipes  705 . In addition, lineman parent  402  can signal lineman child  404  about certain events, including, for example, detection of an inbound call, by sending signal  704  to a signal handler  706  running on lineman child  404 .  
         [0058]    Local lineman  701  also accesses to several files and tables, which it uses to process inbound and outbound DEMs. In the preferred embodiment, there is a routing table  708 , a user registration table  710 , a state file  712  and a spool file  714 .  
         [0059]    The data tables  708  and  710  contain various information required by lineman  701 . In the preferred embodiment, both data tables  708  and  710  are designed to be located somewhere on the network.  
         [0060]    The routing table  708  is used by an inbound lineman to determine a suitable outbound lineman with which to conduct a DEM transaction. In the preferred embodiment, the routing table  708  contains the following information:  
                                                 Copyright, 1997, Open Port Technology, Inc. All Rights Reserved.       Routing Table            FIELD TYPE   FIELD SIZE   FIELD FLAGS   DESCRIPTION               segNumber   int   N/A   NOT NULL - A unique, server maintained sequence number. This can be used by                   an administration utility.       routingPattern   char   64   N/A - This is used to match against a given phone number. The pattern should be                   constructed so as to match/not match a fully qualified phone number. In the                   preferred embodiment, this feature is implemented using the CLIKE function found                   in MimSQL and should thus be portable       hostName   char   64   NA - This is the name of the host that services this pattern. The hostName may be                   followed by an optional parentheses delimited list of port numbers, which if                   present, informs the inbound Lineman to request only a channel from that list, if                   the port number list is not present or is empty then the inbound lineman will                   request the next available port. The syntax of this field is:       matchPriority   int   N/A   hostName [(a,b,c,d)]                   N/A - This field is used to sort out multiple pattern matches. Matches with a                   higher priority are processed before matches with lower priorities. If two or more                   patterns have the same priority then the order in which they are processed is                   undefined (and probably random).       startTimeOfDay   int   N/A   N/A - A value of zero denotes that this hostName will service the routingPattern at                   all times of the day. Any other value denotes, in military time, the time of day                   after which this hostName will service the pattern. The time of service is                   terminated by the value in endTimeOfDay. The time must be stored adjusted to                   UTC.       endTimeOfDay   int   N/A   N/A - This field denotes, in military time, the time of day after which this                   routingPattern is no longer serviced by hostName. if startTimeOfDay is not zero                   and this field is zero then the pattern will be ignored. If this field is less than                   startTimeOfDay then this pattern will he ignored as well. The time must be stored                   adjusted to UTC.       comment   char   64   N/A - A text comment       status   int   N/A   NOT NULL - This is the status of the pattern. It must be one value from this                   table:                   Value Meaning                   1 Enabled- this is an active pattern.                   2 Disabled - this is an inactive pattern.                   3 New - this is an inactive pattern that is currently under testing.                  
 
         [0061]    Copyright, 1997, Open Port Technology, Inc. All Rights Reserved.  
         [0062]    The user registration table  710  contains data concerning the user service provision side of the system incorporating the present invention. In the preferred embodiment, the user registration table  710  contains the following information:  
         [0063]    Copyright, 1997, Open Port Technology, Inc. All Rights Reserved.  
                                                 User Registration Table            FIELD TYPE   FIELD SIZE   FIELD FLAGS   DESCRIPTION               userId   char   64   KEY, NOT_NULL - This is the main user identification within the preferred                   embodiment. It is assigned by a configuration utility. It is generated based on a                   unique sequence number and the name of the host where the configuration Utility                   is currently running. This can allow for domains ts be introduced at a later time                   without impacting existing systems.       nspUserId   char   64   KEY, NOT_NULL - This is the user&#39;s ID within the service provider&#39;s own billing                   system.       status   intr   N/A   NOT NULL - This is the status of the pattern. It must be one value from this                   table:                   1 Enabled - this user&#39;s account is active and inbound connections from                   this user will be accepted                   2 Disabled - this user&#39;s account is inactive and inbound connections from                   this user will be rejected.       firstName   char   24   NOT NULL - The user&#39;s first name.       lastName   char   32   NOT NULL - The user&#39;s last name.       companyName   char   64   NOT NULL - The user&#39;s company name.       configFile   char   128    N/A - The URL of an optional text file containing user specific configuration                   parameters.       comment   char   64   N/A - A text comment.                  
 
         [0064]    Copyright, 1997, Open Port Technology, Inc. All Rights Reserved.  
         [0065]    The state data file  712  and spool data file  714  are preferably located locally on lineman  701 . State data file  712  contains the current state of each DEM channel and lineman. In the preferred embodiment, the state data file  712  is a binary flat file, which contains the current state of each fax channel and lineman.  
         [0066]    Local lineman  701  communicates with remote lineman devices, for example lineman  703  using conventional socket communication. Lineman parent  402  receives information from remote lineman parents, for example, remote lineman parent  718 . The following table illustrates the communication steps between the child and parent lineman processes during an inbound request of the preferred embodiment.  
         [0067]    Copyright, 1997, Open Port Technology, Inc. All Rights Reserved.  
                                           CHILD       PARENT           ACTION   PARENT STEP   ACTION   CHILD STEP                   1   Phone rings. Can I answer it?                       1   Look in state file and update record. Send                   back ANSWER_PHONE acknowledgement.       2   Answer the phone. Collect TDR data. Send           all of that to parent. Can I do T.30 now           and at what connection speed?               2   Validate USER ID. Perform LCR on                   destination phone number. Establish                   connection with remote lineman director.                   Wait for remote lineman parent to return                   T.30 success data. Send back                   T30_PROCEED acknowledgement.       3   Initiate T.30 with appropriate connect speed           and other T.30 data from receive end. Send           CONVERSATION_STARTED message to           parent.       4   Collect data block n for page m. Send data           block to parent.               3   Receive data block n for page m. Forward                   data block to remote lineman parent.       5   Receive EOP (end of page). Can I           acknowledge the new EOP?               4   Send EOP to remote lineman parent. Wait                   for acknowledgement of page. Send                   EOP_PROCEED.       6   Acknowledge EOP. Continue with next           page.               5   Continue processing pages sent up from                   lineman child.       7   Receive EOT (end of transmission). Can I           ACK the new EOT?               6   Send EOT to remote lineman parent. Wait                   for acknowledgement of ROT. Send                   EOT_PROCEED.       8   Acknowledge EOT.       9   Cleanup.   7   Cleanup.                  
 
         [0068]    Copyright, 1997, Open Port Technology, Inc. All Rights Reserved.  
         [0069]    One important aspect of the present invention indicated by the table is that the lineman parent can issue acknowledge messages immediately in order to achieve immediate store-and-forward processing. It should be noted that the present invention is not limited to DEM communication of fax messages, or DEM communication using the T.30 protocol. Rather, the present invention can be used to transmit any DEM using any desired protocol over a data communications network.  
         [0070]    In the preferred embodiment, several operating system level commands are available to control the Lineman process.  
         [0071]    Copyright, 1997, Open Port Technology, Inc. All Rights Reserved.  
         [0072]    rtf lineman start [all | range-of-lines]  
         [0073]    Starts a lineman parent.  
         [0074]    Each lineman parent is its own master, and is started separately.  
         [0075]    The Lineman Parent creates the Lineman Child to control the appropriate fax channel.  
         [0076]    Each Parent can die or rebirth child on child death (this is controlled via signal handler and the configuration for that particular channel).  
         [0077]    rtf lineman stop [all | range-of-lines]  
         [0078]    Stops one or more lineman parents.  
         [0079]    The lineman parents are responsible for stopping their children at the appropriate time.  
         [0080]    rtf director start  
         [0081]    Starts a lineman director daemon.  
         [0082]    The lineman director has access to current line availability information and grants access to available linemen and their fax channels.  
         [0083]    A binary flat file, called the state file, contains the current state of each fax channel and lineman.  
         [0084]    rtf director stop  
         [0085]    Stops a lineman director.  
         [0086]    Stopping the lineman director prevents the local lineman from participating in any outbound DEM transactions.  
         [0087]    A stopped lineman director does not prevent the local lineman from initiating outbound DEM transactions.  
         [0088]    rtf message start  
         [0089]    Starts a message handler daemon.  
         [0090]    The message handler listens on a named pipe or FIFO for connections from processes on the local host.  
         [0091]    The message handler also connects to the configured central message server and forwards messages based on a current configuration.  
         [0092]    The message handler conducts all logging to disk, SNMP traps, etc.  
         [0093]    rtf message stop  
         [0094]    Stops a message handler daemon.  
         [0095]    Once the message handler is stopped, all log messages are sent to the local syslog daemon.  
         [0096]    rtf monitor start  
         [0097]    Starts the monitor daemon.  
         [0098]    Lock file keeps more than one monitor from running.  
         [0099]    rtf monitor stop  
         [0100]    Stops a monitor daemon.  
         [0101]    Certain important activities are associated with the monitor daemon and stopping the monitor daemon will have an adverse affect on the performance of the node.  
         [0102]    rtf start  
         [0103]    This command attempts to start every non-running component on the node.  
         [0104]    rtf [-force] stop  
         [0105]    This command attempts to stop every running component on the node. The -force flag causes a more vicious form of stop: all processes that do not stop on their own accord are forced to stop via kill ( 1 ). This flag is used as a last resort.  
         [0106]    rtf state  
         [0107]    This command reports on the state of every configured component on the node.  
         [0108]    Copyright, 1997, Open Port Technology, Inc. All Rights Reserved.  
         [0109]    The present invention also provides a secondary path for DEM transmission using store-and-forward servers  316  and  318 . If the primary path over the DCN (through DEM servers  304  and  306 ) is not available for some reason, the DEM is sent through the secondary path. The secondary path is itself a DCN. The secondary path includes two store and forward servers  316  and  318 . Referring to FIG. 3, store-and-forward server  316  is operatively coupled to DEM server  304  and store-and-forward server  318 . Store-and-forward server  318  is operatively coupled to DEM server  306  and store-and-forward server  316 .  
         [0110]    When a DEM cannot be transmitted over the primary DCN  312 , the DEM is sent to store-and-forward server  316 . Store-and-forward  316  stores the DEM. It then attempts to establish communication with store-and-forward server  318 . Once communication is established, store-and-forward server  316  transmits the DEM to store-and-forward server  318 . Store-and-forward server  318  transfers the DEM to DEM server  306 . DEM server  306  sends the DEM to MCD  3   r  when MCD  3   r  is available to receive it. Using the secondary path, real-time performance is achieved because the store-and-forward devices can transfer the DEM as soon as the MCD  3   r  is available to receive it.  
         [0111]    Store-and-forward servers  316  and  318  can be any computer system that can be configured to perform the functions described herein. Such configuration would be well within the knowledge of those skilled in the art using the disclosure contained herein.  
         [0112]    In the preferred embodiment of the present invention, a TCP/IP-based network replaces the phone company&#39;s inter-site network for the transport of a DEM from MCD  3   s  to MCD  3   r.  Because the lineman parent and child processes operating on the DEM servers are made aware of the protocol employed by MCDs  3   s  and  3   r,  the present invention allows for message communication according to any communication protocol, including the native protocol of the devices performing the communication.  
         [0113]    It should be noted that the present invention is not limited to telephony connections using a PSTN. Rather, the present invention is equally applicable to any telephony connection from point to point. Thus, in addition to being applicable to PSTN telephony communication, the present invention is applicable to any private network, direct connect (e.g., PBX-to-PBX) network, or any combinations thereof.  
         [0114]    Using the least cost routing techniques described in the U.S. patent application Ser. No. 08/529,923 the flexibility of the present invention is increased. With such techniques, the various remote lineman can better select the correct node to which to transmit a particular DEM.  
         [0115]    The foregoing disclosure of embodiments of the present invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many variations and modifications of the embodiments described herein will be obvious to one of ordinary skill in the art in light of the above disclosure. The scope of the invention is to be defined only by the claims appended hereto, and by their equivalents.