U.S. patent application number 08/971095 was filed with the patent office on 2001-08-23 for telephony signal transmission over a data communications network.
Invention is credited to DUTRA, ANTONIO, KAMEN, BENJAMIN, NANDYAL, OMPRASAD S., STORCH, RANDY S., WEGNER, MARTIN T..
Application Number | 20010015987 08/971095 |
Document ID | / |
Family ID | 27063145 |
Filed Date | 2001-08-23 |
United States Patent
Application |
20010015987 |
Kind Code |
A1 |
WEGNER, MARTIN T. ; et
al. |
August 23, 2001 |
TELEPHONY SIGNAL TRANSMISSION OVER A DATA COMMUNICATIONS
NETWORK
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.
Inventors: |
WEGNER, MARTIN T.;
(BARRINGTON, IL) ; NANDYAL, OMPRASAD S.;
(BLOOMINGDALE, IL) ; DUTRA, ANTONIO; (BUFFALO,
NY) ; STORCH, RANDY S.; (HIGHLAND PARK, IL) ;
KAMEN, BENJAMIN; (DEERFIELD, IL) |
Correspondence
Address: |
DAVID C. ISAACSON
SHAW PITTMAN
2300 N. STREET, N.W.
WASHINGTON
DC
20037
US
|
Family ID: |
27063145 |
Appl. No.: |
08/971095 |
Filed: |
November 14, 1997 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
08971095 |
Nov 14, 1997 |
|
|
|
08582475 |
Jan 4, 1996 |
|
|
|
5712907 |
|
|
|
|
08582475 |
Jan 4, 1996 |
|
|
|
08529923 |
Sep 18, 1995 |
|
|
|
Current U.S.
Class: |
370/503 ;
370/522 |
Current CPC
Class: |
H04M 15/00 20130101 |
Class at
Publication: |
370/503 ;
370/522 |
International
Class: |
H04L 012/66 |
Claims
What is claimed is:
1. A system for controlling transmission of a digitally encoded
message (DEMs), comprising: a first message communicating device
(MCD) for generating the DEM; a first node coupled to said first
message communicating device having one or more ports into which
said DEM can be transmitted for transmitting the DEM over a
network; a first control process executing on said first node; a
second node having one or more ports for receiving a DEM that has
been transmitted by said first node over the network; a second
control process executing on said second node; a second message
communicating device for receiving said the DEM from said second
node; and a protocol by which said first and second control
processes establish a communication path over which the DEM is
transmitted so as to establish and maintain synchronization between
said first and second control processes.
2. The system of claim 1, wherein said first control process,
further comprises: a detector to determine the presence of a
request for service caused by the DEM; a locator to locate and
reserve an available port on said first node; and wherein the
communication path is established by said first control process
through said available port.
3. The system of claim 2, wherein said first control process
comprises: a parent process to perform network functions; and a
child process to perform hardware and telephony functions.
4. The system of claim 3, wherein said second control process
comprises: a second parent process to perform network functions;
and a second child process to perform hardware and telephony
functions.
5. The system of claim 4, wherein said communication path is
established between said first and second child processes.
6. The system of claim 2, wherein the first control process further
comprises: a caller to place an outbound call to the second control
process; a second detector to determine when said communication
path with said second control process has been established; and
wherein said second controller sends said DEM to said first
controller over said communication path.
7. The system of claim 6, wherein said first control process
determines that said second node is the destination of the DEM
through a least-cost routing determination.
8. The system of claim 1, wherein at least one of said first and
second MCDs is a facsimile machine.
9. The system of claim 1, further comprising a user interface by
which a system administrator can access maintenance information
corresponding to system performance.
10. The system of claim 1, further comprising: a secondary path for
transmission of DEMs; and wherein said protocol further determines
whether the DEM can be transmitted over the network or over the
secondary path.
11. The system of claim 1, wherein said first MCD comprises said
first node.
12. The system of claim 1, wherein said second MCD comprises said
second node.
13. The system of claim 1, wherein said network is one of an
intranet and the Internet.
14. The system of claim 1, wherein said network is one of a
wide-area network and a local-area network.
15. A method for transmitting a digitally encoded message (DEMs)
over a network, comprising the steps of: (a) generating the DEM in
a message communication device (MCD); (b) sending the DEM to a
transmitter node attached to a network for subsequent transmission
of the DEM over the network; (c) determining a suitable receiver
node attached to the network for the DEM; (d) establishing a
communication path between the transmitter node and the receiver
node; (e) synchronizing the transmission of the DEM between the
transmitter and receiver nodes; (f) transmitting the DEM from the
transmitter node to the receiver node, while maintaining
synchronization required to transmit the DEM; and (g) receiving the
DEM at the receiver node.
16. The method of claim 15, wherein said synchronization step
further comprises the step of receiving a confirmation for each
portion of the DEM transmitted.
17. The method of claim 15, wherein said establishing step further
comprises the steps of passing messages between the transmitter and
receiver nodes.
18. The method of claim 15, wherein said determining step, further
comprises the steps of: (a) choosing to transmit the DEM over a
network or a secondary path; (b) transmitting the DEM over the
network when synchronization required for the DEM transmission can
be maintained; and (c) transmitting over the secondary path when
there is not synchronization between the transmitter and receiver
nodes.
19. The method of claim 18, wherein said determining step, further
comprises the step of determining the least cost route over which
to transmit the DEM.
20. The method of claim 15, wherein said transmitting step
comprises the step of transmitting said DEM over one of a wide-area
network and a local-area network.
21. The method of claim 15, wherein said transmitting step
comprises the step of transmitting said DEM over one of an intranet
and the Internet.
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] 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'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] FIG. 1 is a schematic diagram of a prior art system for
real-time transmission of DEMs using a PSTN.
[0028] FIG. 2 is a schematic diagram of a prior art system for
transmitting DEMs over a data communication network
[0029] FIG. 3 is a schematic representation of a system operating
in accordance with the present invention.
[0030] FIG. 4 is a schematic diagram of a control process for
transmitting DEMs over a DCN.
[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] 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] FIG. 7 is a schematic diagram of the interconnections on a
local lineman
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0034] FIG. 3 is a schematic representation of a system 301
operating in accordance with the present invention. An MCD 3s 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 3r. 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 3s. MCD 3s
transmits the DEM to DEM server 304. In the preferred embodiment,
MCD 3s 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 3r.
[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 3s and 3r are fax
machines. To communicate correctly MCD 3s and MCD 3r must maintain
synchronization. If synchronization is lost, the communication link
between MCD 3s and MCD 3r 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] 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'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] 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] 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'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] 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:
1 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.
2 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's ID within the service provider'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's account is active and inbound connections from this
user will be accepted 2 Disabled - this user's account is inactive
and inbound connections from this user will be rejected. firstName
char 24 NOT NULL - The user's first name. lastName char 32 NOT NULL
- The user's last name. companyName char 64 NOT NULL - The user'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.
3 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 .vertline. 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 .vertline. 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 3r when MCD 3r 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
3r 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's inter-site
network for the transport of a DEM from MCD 3s to MCD 3r. Because
the lineman parent and child processes operating on the DEM servers
are made aware of the protocol employed by MCDs 3s and 3r, 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.
* * * * *