Patent Application
20050041642
1. Field of the Invention
This invention relates broadly to telephone systems and methods. More particularly, this invention relates to telephone systems that employ both traditional PSTN-based calls and Internet-based VOIP calls.
2. State of the Art
Internet-based VOIP calls are typically less expensive to a user than traditional PSTN-based calls, especially so for long distance calls and international calls. However, the technology utilized to realize the Internet-based VOIP network currently has limitations. For example, the quality-of-service of the Internet-based VOIP network can vary as a result of wide dynamic changes in latency, jitter and/or packet loss of the network, and the connection to the Internet-based VOIP network is unavailable in the event of power failure. Thus, in certain instances, it is preferable to place the call over the traditional public switched telephone network (PSTN).
In order to leverage the lower costs associated with Internet-based VOIP calls and maintain the guaranteed quality-of-service and reliability of the traditional PSTN calls, systems have been developed that enable customers to place and receive Internet-based calls (i.e., voice over Internet Protocol (VOIP) calls) as well as traditional public switched telephone network (PSTN) calls. An example of such a system is described in U.S. Pat. No. 6,404,764 to Jones et al. In this system, a network premises gateway provides an interface between the POTS telephones of the premises and the PSTN and Internet. When placing a call, the DTMF detection and call progress generator of the gateway detects an off-hook condition with a POTS telephone, receives a sequence of signals generated by the POTS telephone, and buffers this sequence. The gateway processes the sequence to detect a predetermined sequence that signify a VOIP-based call. Upon detection, the gateway enters VOIP mode whereby the call is placed over the Internet. If the predetermined sequence is not detected, the gateway enters a POTS mode whereby the buffered sequence is transmitted to the PSTN (i.e., redialed) such that call is placed over the PSTN. For VOIP calls, the gateway system provides analog-to-digital conversion functionality, digital-to-analog conversion functionality and protocol conversion functionality.
In these systems, circuitry is required to intercept and store the dialed number in addition to circuitry to seize the PSTN phone line and redial the number. Such circuitry adds unwanted complexity and costs to the systems. The complexities stem from the fact that the North American and European dialing conventions are highly irregular and frequently subject to change.
Moreover, it is imperative that in the advent of a power failure, the POTS telephones of the premises continue to operate. In such systems, because the POTS lines are intercepted, this can cause a problem during a power failure.
It is therefore an object of the invention to provide an apparatus/methodology/system that routes voice calls over diverse networks (such as the PSTN, one or more Internet-based VOIP networks, and/or a WATS line) in a manner that does not require interception, storing and redialing the dialed number.
It is another object of the invention to provide such an apparatus/methodology/system that routes voice calls over diverse networks but which maintains a connection of analog telephone lines of the premises to the PSTN such that the POTS service provided by the PSTN enables the telephones to operate in a normal manner in the event of power failure.
It is a further object of the invention to provide such an apparatus/methodology/system that routes calls over the diverse networks in accordance with one or more routing tables.
It is also an object of the invention to provide configuration of such routing tables to minimize telephone usage costs that are attributable to calls placed over the diverse networks.
It is an additional object of the invention to provide flexible routing of an inbound voice call over a particular trunk to one or more lines in a premises.
It is still another object of the invention to provide such flexible routing in accordance with one or more routing tables and/or caller ID information that is part of the inbound voice call.
In accord with these objects, which will be discussed in detail below, a telephony system for a premises includes lines operably coupled to telephony devices, and trunks operably coupled to diverse networks (such as the PSTN network, one or Internet-based VOIP networks, and a WATS line). The lines may be directly connected to the telephony devices, or coupled thereto via a Public Branch Exchange (PBX) or key telephone system (KTS). A voice router includes a switch matrix operably coupled between the lines and trunks. In processing an outgoing voice call placed on a particular line, switch control means (e.g., a programmed microprocessor) controls the switch matrix to connect the particular line to at least two trunks (preferably in accordance with at least one routing table). The switch control means analyzes DTMF digit data (corresponding to DTMF digit tone(s) generated on the line) to determine a classification tag for the outgoing voice call, and disconnects (drops) the particular line from at least one trunk (which is preferably accomplished prior to completion of dialing) based upon the classification tag to enable the outgoing voice call to proceed over another one of the at least two trunks. An incoming voice call received over a particular trunk is connected to one or more lines by the switch matrix (preferably in accordance with at least one routing table).
It will be appreciated that this architecture does not intercept, store and redial the dialed number, thereby providing advanced routing functionality with lower costs.
According to one embodiment of the invention, one or more VOIP trunks couple the voice router to an external VOIP gateway. According to another embodiment of the invention, the voice router is integrated with VOIP gateway functionality within a common system housing. In such applications, the voice router may preferentially route local calls (as well as toll-free calls and emergency-911 calls) over the PSTN trunks, and preferentially route long distance calls (as well as international calls and site-to-site calls) over the VOIP trunks, to thereby minimize telephone usage costs that are attributable to calls placed over these networks.
Optionally, the voice router is adapted to directly connect the telephony devices in there idle state to the PSTN, thereby ensuring that all of the local signaling between the central office and the premise are preserved. This removes any conformance issues and greatly increases the reliability of the installation.
Additional objects and advantages of the invention will become apparent to those skilled in the art upon reference to the detailed description taken in conjunction with the provided figures.
Turning to
The premises 10 is equipped with a number of analog telephony devices (such as analog telephones, fax machines or modems) that produce and/or receive analog signals typically carried over a POTS connection. In the illustrative embodiment shown, there are two analog telephones shown as 22a and 22b. A PSTN Network Interface Unit (NIU) 24 provides a connection point for one or more trunks (e.g., a copper twisted pair) that are operably coupled to the local central office 26 of the public-switched telephone network (PSTN) 28. The NIU 24, which is typically found on the outside of a residence in the United States, is the demarcation point between the telephone company's equipment and the subscriber's equipment. In the exemplary embodiment shown, the Network Interface Unit 24 provides a connection point to two copper twisted pair, trunk 0 and trunk 1. Traditional POTS-based calls are placed/received over the trunk(s) of the NIU 24 and PSTN. Such POTS-based calls can include local calls which connect to a local subscriber's premises equipment (shown as premises 30, NIU, 32 and analog telephone equipment 34), long distance calls which connect to a remote subscriber's premises equipment (shown as premises 36, NIU 38 and analog telephone 40 coupled to the remote central office 42 of the PSTN 28), toll-free calls, and/or emergency-911 calls. Note that a multi-channel T1 trunk may be used to couple the premises 10 to the local central office 26. In this configuration, a T1 channel service unit and channel bank may be used to provide a plurality of trunks that interface to the analog telephony devices of the premises 10 via the voice router 58.
The premises 10 is also equipped with a VOIP gateway 44 operably coupled to the LAN 12. The VOIP gateway 44 provides an interface between one or more analog telephony devices and the Internet-based VOIP network. The VOIP gateway 44 cooperates with the router/firewall 16 and Internet Access Device 18 to place/receive VOIP calls over the Internet-based VOIP network. Such VOIP calls can include long distance calls (or international calls or site-to-site) which connect to a remote subscriber's premises equipment. For example, a VOIP call can connect to subscriber's premises equipment at remote premises 46 as shown in
With respect to outbound VOIP calls, the VOIP gateway 44 is responsible for IP-based call origination, analog-to-digital conversion of voice signals (and other analog signals) provided by the analog telephony device(s) coupled thereto, the creation of voice packets that represent such voice signals, and the forwarding of such voice packets to the Internet-based VOIP network via the router/firewall 16 and Internet Access Device 18. With respect to inbound VOIP calls, the VOIP gateway 44 is responsible for IP-based call detection, reception of voice packets from the to the Internet-based VOIP network via the router/firewall 16 and Internet Access Device 18, and digital-to-analog conversion of the voice signals represented by the packets for supply to the analog telephony device(s) coupled thereto. In addition, the VOIP gateway 44 may optionally include additional features, such as voice (analog and/or digital) compression, echo cancellation, silence suppression, and statistics gathering and reporting. Typically, each conversation (call) is a single IP session transported by a Real-time Transport Protocol (RTP) that runs over User Datagram Protocol (UDP) as is well known in the communication arts. In addition, signaling that sets up the call is typically provided by one or more protocols, such as H.323, Session Initiation Protocol (SIP) and/or Media Gateway Control Protocol (MGCP), which are well known in the communication arts.
In accordance with the present invention, a voice router 58 is provided that interfaces between the analog telephony devices (e.g., analog telephones 22a, 22b) and the trunk(s) operably connected to the PSTN via the NIU 24 to support the origination and reception of traditional POTS-based calls over such trunk(s). In addition, the voice router 58 interfaces between the telephony devices (e.g., analog telephones 22a, 22b) and the VOIP gateway 44 to support the origination and reception of VOIP calls over the Internet-based VOIP network. With respect to outbound calls placed from a given analog telephony device, the voice router 58 carries out an improved parallel dialing methodology that is triggered by the detection that the given analog telephony device has gone off-hook. This condition is indicated by the flow of line current that results from the device going off-hook. This line current is supplied to the voice router 58 over a line (e.g., a copper twisted pair) operably coupled between the given analog telephony device and the voice router 58. As part of the parallel dialing methodology, two or more trunks (preferably including a PSTN trunk and a VOIP trunk) are seized and one or more DTMF dial tones (which are generated by the given analog telephone device and supplied to the voice router 58 over the line therebetween) are simultaneously routed over the two or more seized trunks. Note that the DTMF tones are preferably routed over the two or more seized trunks without storage (and subsequent redialing) of such DTMF tones. These operations ensure compliance to the local signaling specifications of the central office, which is difficult to accomplish with a store and redial approach. The dial digit(s) corresponding to the DTMF tone(s) are analyzed by the voice router 58 (preferably utilizing a pattern matching operation as described herein) to select a preferred route classification corresponding thereto. In the preferred embodiment of the present invention, the preferred route classifications include a first value that indicates that the call should be preferably routed over the PSTN, and a second value that indicates that that the call should be preferably routed over the Internet-based VOIP network. In order to minimize costs to the subscriber, the first value is typically assigned to local calls (and possibly toll-free calls and emergency-911 calls) and the second value is typically assigned to long distance calls (and possibly international and site-to-site calls). In alternate embodiments of the present invention, the preferred route classifications can include values that indicate preferential routing over other networks (such as a WATS line or one of a plurality of Internet-based VOIP networks. After determining the preferred route classification, the unwanted seized trunk(s), which does not correspond to the preferred route classification, is released from the line of the given analog telephony device in order to terminate the dialing operations (and associated call signaling operations, if any) that occur over the unwanted trunk(s). The connection between the line of the given analog telephony device and the preferred trunk (that trunk which corresponds to the preferred route classification) is maintained such that the dialing operations (and associated call signaling operations) and subsequent communication (if the call is successful) occur over the preferred trunk.
The voice router 58 is also preferably configured to connect “idle” lines to “idle” trunks in accordance with an inbound call routing preferences tables (referred to herein as the Inbound Routing Table). This feature enables the voice router 58 to provide miscellaneous idle-time signaling (such as message waiting indications or billing information) from the “idle” trunks to the “idle” lines. Note that the protocols for such idle-time signaling vary widely over the PSTN. The automatic connection of “idle” lines to “idle” trunks provided by the voice router 58 affords an efficient mechanism to support such protocol variations.
In addition, the voice router 58 is preferably configured to operate in case of power failure such that the lines for one or more of the analog telephony devices (e.g., analog telephones 22a, 22b) are electrically connected to the PSTN trunk line(s) via the NIU 24. This enables the analog telephony devices to draw power from the POTS service (i.e., line current) provided by the PSTN trunk to ensure normal operation in the case of power failure.
Advantageously, the parallel routing operations carried out by the voice router 58 do not require local number storage, redial circuitry, and circuitry to determine that the dial is successful and thus provides a low cost solution. In addition, these operations ensure compliance to the local signaling specifications of the central office, which is difficult to accomplish with local number storage and redial circuitry. In addition, the omission of such circuitry enables improved fidelity of connection, which can enhance the speed at which modems, faxes and other analog telephony devices can connect over the voice router 58. Moreover, these operations are intrinsically more robust and facilitate pass-through routing in case of power failure whereby the lines for the analog telephony devices are electrically connected to the PSTN trunk line(s) via the NIU 24. Additionally, if the voice router 58 is used in a facility in which the speed at which calls can be placed is important (such as an outbound call center), these operations provide for minimal delay in placing the outbound call while maintaining the cost advantages of selective call routing over the PSTN and Internet-based VOIP network.
Note that the local central office 26 (via the NIU 24) and the VOIP gateway 44 provide a Foreign Exchange Station (FXS) interface that delivers POTS service (including line current, ring voltage, dial tone) over the trunks 0-4 to the analog telephony devices coupled thereto via the switch matrix 108. The FXS interface also performs off-hook detection (i.e., detection of line current indicating that the trunk has been seized). In addition, the analog telephony devices (e.g., analog telephones 22a, 22b) include a Foreign Exchange Office (FXO) interface that receives POTS service (e.g., line current, ring voltage, dial tone) from the trunks 0-4 coupled thereto via the switch matrix 108.
In this configuration, an inbound PSTN call triggers the FXS interface of the local Central Office 26 to initiate a call by presenting a ring voltage over the PSTN trunk (trunk 0 or trunk 1). The switch matrix 108, which is configured to connect the PSTN trunk to one or more lines, passes the ring voltage over these line(s) to the attached analog telephony device(s). The FXO interface of the attached analog telephony device(s) detects the ring voltage (which triggers the phone to ring). When the telephone goes off-hook (i.e., “activated/picked up” by the user), line current flows through the loop coupled to the analog telephony device(s). This line current is detected by the FXS interface of the local Central Office 26. Similarly, an inbound VOIP call triggers the FXS interface of the VOIP gateway 44 to initiate a call by presenting a ring voltage over the VOIP trunk (trunk 2 or trunk 3). The switch matrix 108, which is configured to connect the VOIP trunk to one or more lines, passes the ring voltage over these line(s) to the attached analog telephony device(s). The FXO interface of the attached analog telephony device(s) detects the ring voltage (which triggers the phone to ring). When the telephone goes off-hook (i.e., “activated/picked up” by the user), line current flows through the loop coupled to the analog telephony device(s). This line current is detected by the FXS interface of the VOIP gateway 44.
Preferably, the switch matrix 108 is configured to operate in case of power failure such that the lines for one or more of the analog telephony devices (e.g., analog telephones 22a, 22b) are electrically connected to the PSTN trunk line(s) via the NIU 24. This feature can be realized by using normally-open relays for the interconnection means of the switch matrix 108 except on the diagonal where normally closed relays are employed. This arrangement ensures that in the absence of power, every trunk will be connected to its corresponding line. This feature enables the analog telephony devices to draw power from the line current provided by the PSTN trunk lines to ensure normal operation of these devices in the case of power failure.
The microprocessor system 116 includes a voice routing control routine 118 that carries out a parallel dialing methodology in accordance with the present invention. Note that the switch matrix 108 is configured in its idle state to connect idle line(s) to corresponding idle trunk(s) such that inbound/outbound calls can be placed and received over these connections. An outbound call is initiated when a given analog telephone device goes off-hook (i.e., “activated/picked up” by the user) and line current flows through the loop coupled to the given analog telephony device. This local loop can be terminated at the local Central Office 26 in the event that the “idle state” configuration connects the line for the given analog telephone device to a PSTN trunk. Alternatively, this local loop can be terminated at the VOIP Gateway 44 in the event that the “idle state” configuration connects the line for the given analog telephone device to a VOIP trunk. In either case, the line interface circuitry 112 of the voice router 58 detects this line current and provides an off-hook detect control signal to the microprocessor system 116 in response thereto. The routine 118 is triggered by this off-hook detect control signal. As part of the parallel dialing methodology, the routine 118 identifies two or more idle trunks, and seizes these two or more idle trunk(s) by controlling the switch control 110 to adjust the switch matrix 108 to connect the line port for the given analog telephone device to the trunks ports corresponding to these two or more idle trunk(s). Line current flows through these idle trunk(s) for detection by the FXS interface that terminates such trunk(s). In this manner, multiple trunks are connected to the line for the given analog telephony device and seized by the device. Preferably, these multiple trunks include a PSTN trunk and a VOIP trunk as will be described hereinafter.
Subsequent thereto, the FXO interface of the given analog telephone device dials the DTMF digits, which identify the destination to be called. One or more of these DTMF digits are simultaneously routed to the multiple trunks connected thereto by the switch matrix 108. In the event that a PSTN trunk is coupled to the given analog telephone device by the switch matrix 108, the FXS interface of the local Central Office 26 that terminates the PSTN trunk receives these DTMF digits. Based upon these DTMF digits, the local Central Office 26 performs signaling operations that sets up the voice circuit path through the PSTN for the call, and routes the call over the voice circuit path. Similarly, in the event that a VOIP trunk is coupled to the given analog telephone device by the switch matrix 108, the FXS interface of the VOIP gateway 44 that terminates the VOIP trunk receives these DTMF digits. Based upon these DTMF digits, the VOIP gateway 44 performs signaling operations that sets up the route through the Internet-based VOIP network, and routes the call over this path.
As the DTMF dial digit(s) pass through the voice router 108, the line interface circuitry 112 detects the DTMF dial digit(s) and supplies signals representing the DTMF dial digits to the routine 118. The routine 118 utilizes a pattern matching operation that analyzes the DTMF dial digit(s) and selects a preferred route classification that corresponds to the DTMF dial digits. The preferred route classifications preferably include a first value that indicates that the call should be preferably routed over the PSTN in addition to a second value that indicates that that the call should be preferably routed over the Internet-based VOIP network. In order to minimize costs to the subscriber, the first value is typically assigned to local calls (and possibly toll-free calls and emergency-911 calls) and the second value is typically assigned to long distance calls (and possibly international calls and site-to-site calls). After determining the preferred route classification, the routine 118 releases the unwanted trunk(s) (trunk(s) which do not correspond to the preferred route classification) by controlling the switch control 110 to adjust the switch matrix to decouple the trunk port for the unwanted trunk(s) from the line port of the given analog telephony device, thereby terminating the dialing operations (and associated call signaling operations, if any) that occur over the unwanted trunk(s). The routine 118 maintains the connection between the line port of the given analog telephony device and the trunk port for the preferred trunk (that trunk which corresponds to the preferred route classification) such that the dialing operations (and associated call signaling operations) and subsequent conversation (if the call is successful) occur over the preferred trunk. After the release of the unwanted trunk(s), the routine 118 preferably updates the idle connections of the switch matrix 108 in accordance with the preferences of a routing table as is discussed in detail below.
The microprocessor system 116 also maintains a call log 120 that stores information (such as origination number, destination number, start time, duration, and/or call type (e.g., PSTN or VOIP)) related to the inbound and/or outbound calls that are routed through the voice router 58. Such information is collected by the microprocessor system 116 as the calls are originated, received and terminated. Preferably, the call log is accessible to users over an Ethernet link to the LAN 12 as provided by an Ethernet interface 122. For example, access to the call log 120 can be provided by a network-based utility executing on the client machine 14 operably coupled to the LAN 12. Alternatively, the microprocessor system 116 can include an embedded web server that serves up the call log such that it can be accessed by users executing a standard web browser on the client machine 14.
The microprocessor system 116 also provides a configuration routine 124 that enables users to configure operational parameters (e.g., network parameters, routing tables, QOS parameters, feature enablement/disablement, etc). Preferably, the configuration routine is accessible to users over an Ethernet link to the LAN 12 as provided by the Ethernet interface 122. For example, access to the configuration routine 124 can be provided by a network-based utility executing on the client machine 14. Alternatively, the microprocessor system 116 can include an embedded web server that enables web-based configuration of the operational parameters by users executing a standard web browser on the client machine 14.
Turning now to
As shown in
As shown in
Note that the Outbound Routing Tables may be used to carry information that inhibits the routing of outbound calls over one or more trunks. For example, the “least preferred trunk assignment” (column 4) in the exemplary “Local” Outbound Routing Table of
As shown in
As shown in
Turning now to
In block 703, the “Local” Outbound Call Routing Table and Trunk Ownership bytes for the four trunks are accessed to identify a first inactive trunk (bit 7 is set to ‘0’) in accordance with the preferences of the “Local” Outbound Call Routing Table. Preferably, these operations involve sequencing through the cells of the row of the “Local” Outbound Call Routing Table that corresponds to the particular line. The cells are accessed from most preferred to least preferred. If the trunk identified by the cell is inactive (bit 7 is set to ‘0’), the trunk ID of the cell is used to identify the first inactive trunk. Note that a trunk ID of ‘FF’ indicates that no trunk is available for “local” routing.
In block 705, the “Long Distance” Outbound Call Routing Table and Trunk Ownership bytes for the four trunks are accessed to identify a second inactive trunk (bit 7 is set to ‘0’) in accordance with the preferences of the “Long Distance” Outbound Call Routing Table. Preferably, these operations involve sequencing through the cells of the row of the “Long Distance” Outbound Call Routing Table that corresponds to the particular line. The cells are accessed from most preferred to least preferred. If the trunk identified by the cell is inactive (bit 7 is set to ‘0’), the trunk ID of the cell is used to identify the second inactive trunk. Note that a trunk ID of ‘FF’ indicates that no trunk is available for “long distance” routing.
In block 707, the Line Ownership byte pertaining to the particular line is modified such that the outbound call object OCOi claims ownership of the line. This is accomplished by setting the Active Status field (bit 7) to ‘active’, the Optimization Status field (bit 6) to ‘NOP’, and bits 5-0 to the call object identifier for the outbound call object OCOi.
In block 709, the Trunk Ownership byte pertaining to the first and second inactive trunks identified in blocks 705 and 707 are modified such that the outbound call object OCOi claims ownership of these two trunks. For the Trunk Ownership byte pertaining to the first inactive trunk, this is accomplished by setting the Active Status field (bit 7) to ‘active’, the Optimization Status field (bit 6) to ‘NOP’, and bits 5-0 to the call object identifier for the outbound call object OCOi. Similar operations are performed with respect to the Trunk Ownership byte pertaining to the second inactive trunk. Note that the switch matrix update operations of block 607 periodically scan (for example, every 30 ms) the Line Ownership bytes and Trunk Ownership bytes to ascertain whether the bits 5-0 match (and the optimization status field is ‘NOP’). If so, switch matrix update operations cooperate with switch control 110 to update the switch matrix to connect the matching trunk and line. In this manner, the scan of the Line Ownership bytes and Trunk Ownership bytes that occurs subsequent to blocks 707 and 709 will control the switch matrix to connect the particular line to the first and second trunks owned by the outbound call object OCOi. When the switch matrix connects the particular line to the first and second trunks owned by the outbound call object OCOi, line current flows through these two trunks such that they are seized by the telephone device.
Note that in the event that there is no trunk available for “local” routing (i.e., the ID for the first inactive trunk in block 705 is FF), the modification of the Trunk Ownership byte for the first inactive trunk is omitted. In this case, the subsequent scan of the Line Ownership bytes and Trunk Ownership bytes will not control the switch matrix to connect the particular line to a ‘local’ trunk. Similarly, in the event that there is no trunk available for “long distance” routing (i.e., the ID for the second inactive trunk in block 707 is FF), the modification of the Trunk Ownership byte for the second inactive trunk is omitted. In this case, the subsequent scan of the Line Ownership bytes and Trunk Ownership bytes will not control the switch matrix to connect the particular line to a ‘long distance’ trunk.
In block 711, DTMF digits (which are detected by the line interface circuitry 112 signals in response to DTMF digit tones generated by the FXO interface of the analog telephone device on the particular line) are monitored and processed to determine whether the call is classified as a “local” call or a “long distance” call. Preferably, such operations utilize pattern matching operations with respect to the DTMF digits as they are generated to identify the correct classification of the call. In block 713, it is determined whether the class classification is long distance (or local).
If the classification is “long distance” in block 713, the operations continue to block 715 to modify the Trunk Ownership byte for the particular trunk such that outbound call object OCOi releases ownership of the first trunk-that trunk identified in block 703. This is accomplished by setting the Active Status field (bit 7) to ‘inactive’, the Optimization Status field (bit 6) to ‘NOP’, and bits 5-0 to the default trunk identifier. In this manner, the scan of the Line Ownership bytes and Trunk Ownership bytes that occurs subsequent to block 715 will control the switch matrix to disconnect the particular line from the unwanted first trunk, thereby terminating the dialing operations (and associated call signaling operations, if any) that occur over the unwanted trunk. The operations of block 715 maintains the connection between the particular line and the preferred “long distance” trunk identified in block 705 such that the dialing operations (and associated call signaling operations) and subsequent conversation (if the call is successful) occur over the preferred trunk.
If the classification is “local” in block 713, the operations continue to block 717 to modify the Trunk Ownership byte for the particular trunk such that outbound call object OCOi releases ownership of the second trunk-that trunk identified in block 705. This is accomplished by setting the Active Status field (bit 7) to ‘inactive’, the Optimization Status field (bit 6) to ‘NOP’, and bits 5-0 to the default trunk identifier. In this manner, the scan of the Line Ownership bytes and Trunk Ownership bytes that occurs subsequent to block 717 will control the switch matrix to disconnect the particular line from the unwanted second trunk, thereby terminating the dialing operations (and associated call signaling operations, if any) that occur over the unwanted trunk. The operations of block 717 maintain the connection between the particular line and the preferred “local” trunk identified in block 703 such that the dialing operations (and associated call signaling operations) and subsequent conversation (if the call is successful) occur over the preferred trunk.
After blocks 715 and 717, the operations continue to blocks 719 whereby information regarding the call (such as destination number and start time) are added to the call log 120. In addition, the connections of the switch matrix are updated to best meet the preferences of the Inbound Routing Table. These switch matrix update operations are set forth in detail in
In block 721, the operations wait unit the call has been terminated and then continue to block 723 to modify the Trunk/Line Ownership bytes such that the outbound call object OCOi releases ownership for the line/trunk seized for the call. This is accomplished by setting the Active Status field (bit 7) to ‘inactive’, the Optimization Status field (bit 6) to ‘NOP’, and bits 5-0 to the default trunk identifier. In this manner, the scan of the Line Ownership bytes and Trunk Ownership bytes that occurs subsequent to block 717 will control the switch matrix to disconnect the particular line from the trunk used for the call.
After block 723, the operations continue to block 725 whereby information regarding the call (such as end time and/or call duration) is added to the call log 120. In addition, the connections of the switch matrix are updated to best meet the preferences of the Inbound Routing Table. These switch matrix optimization operations are set forth in detail in
In block 803, Caller ID information (which is provided by the trunk interface circuitry 114) and the Line Ownership bytes are used to access a Caller ID Routing Table and identify an inactive line (bit 7 is set to ‘0’) in accordance with the preferences of the Caller ID Routing Table. The Caller ID Routing Table is similar in nature to the Inbound Call Routing Table yet assigns a preferred line (or group(s) of lines) to calls from a particular Caller ID. Preferably, these operations involve sequencing through the cell(s) of the row of the Caller ID Routing Table that corresponds to the particular caller ID. The cells are accessed from most preferred to least preferred. If the line(s) identified by the cell is inactive (bit 7 is set to ‘0’), the line ID(s) of the cell is used to identify the inactive line(s). If the Caller ID route processing fails (or is omitted), the operations of block 803 may utilize the Line Ownership Data Structures and Inbound Call Routing Table to identify an inactive line (or group of lines) (bit 7 is set to ‘0’) in accordance with the preferences of the Inbound Call Routing Table. Preferably, these operations involve sequencing through the cell(s) of the row of the Inbound Call Routing Table that corresponds to the particular trunk. The cells are accessed from most preferred to least preferred. If the line(s) identified by the cell is inactive (bit 7 is set to ‘0’), the line ID(s) of the cell is used to identify the inactive line(s).
Note that in the preferred embodiment of the present invention, the idle state of the switch matrix is updated to best meet the preferences of the Inbound Routing Table. In this configuration, the inbound call will automatically ring on the telephone device connected to the “idle state” line. Thus, if the Caller ID route processing identifies the same “idle state” line, the reconfiguration of the switch matrix in blocks 805 and 809 can be omitted.
In block 805, the Trunk Ownership byte pertaining to the particular trunk is modified such that the inbound call object ICOx claims ownership of the trunk. This is accomplished by setting the Active Status field (bit 7) to ‘active’, the Optimization Status field (bit 6) to ‘NOP’, and bits 5-0 to the call object identifier for the inbound call object ICOx.
In block 807, the Line Ownership byte pertaining to the inactive line(s) identified in block 803 is modified such that the inbound call object ICOx claims ownership of such line(s). This is accomplished by setting the Active Status field (bit 7) to ‘active’, the Optimization Status field (bit 6) to ‘NOP’, and bits 5-0 to the call object identifier for the inbound call object ICOx. In this manner, the scan of the Line Ownership Bytes and Trunk Ownership Bytes that occurs subsequent to blocks 805 and 807 will control the switch matrix to connect the particular trunk to the line(s) owned by the inbound call object ICOx. When the switch matrix connects the particular trunk to the line(s) owned by the inbound call object ICOx, line current flows through these line(s) such that the line(s) and particular trunk are seized by the telephone device.
In block 809, the operations may connect answering machine functionality to the particular trunk in parallel with the connection to the line(s) owned by the inbound call object. This may be accomplished by connecting an answering machine device to one of the lines (e.g., line 4) and configuring the Inbound Routing Table to connect the answering machine line (line 4) to the inbound trunk in parallel to the connection of the inbound trunk to one or more analog telephone lines (e.g., lines 1 and 2). Alternatively, answering machine functionality can be integrated into the routing device 58 itself. In this case, the voice messages stored therein may be stored in digital form and made accessible to the user(s) via dialing predetermined DTMF digits over one of the lines (and possibly made accessible over the LAN 12).
In block 811, information regarding the call (such as origination number and start time) is added to the call log 120. In addition, the connections of the switch matrix are updated to best meet the preferences of the Inbound Routing Table. These switch matrix update operations are set forth in detail in
In block 813, the operations wait until the call has been terminated and then continue to block 815 to modify the Trunk/Line Ownership bytes such that the inbound call object ICOx releases ownership for the line/trunk seized for the call. This is accomplished by setting the Active Status field (bit 7) to ‘inactive’, the Optimization Status field (bit 6) to ‘NOP’, and bits 5-0 to the default trunk identifier. In this manner, the scan of the Line Ownership bytes and Trunk Ownership bytes that occurs subsequent to block 813 will control the switch matrix to disconnect the particular trunk from the line used for the call.
After block 815, the operations continue to block 817 whereby information regarding the call (such as end time and/or call duration) is added to the call log 120. In addition, the connections of the switch matrix are updated to best meet the preferences of the Inbound Routing Table. These switch matrix update operations are set forth in detail in
In block 903, a preference scan is made through the Trunk Ownership bytes to identify idle trunks whose Optimization Status Field is set to ‘OP’. For each one of these trunks, the operations of blocks 905 through 911 are performed.
In block 905, the Inbound Routing Table is accessed to identify the “preferred” line for the given trunk. This is accomplished by sequencing through the preference levels for the given trunk. If the line at the preference level is available, then it is the “preferred” line; otherwise move on to the next preference level.
In block 907, the Line Ownership byte for the “preferred” line is accessed to determine if its Optimization Status Field is set to ‘OP’. If not, the operations return to block 905 to identify the next “preferred” line in accordance with the preferences of the Inbound Routing Table. If, in block 907, the Line Ownership byte for the “preferred” line includes an Optimization Status Field set to ‘NOP’, the operations continue to block 909.
In block 909, bits 5-0 of the Line Ownership byte for the “preferred” line is set to the trunk ID for the given trunk. In this manner, the scan of the Line Ownership bytes and Trunk Ownership bytes that occurs subsequent to block 909 will control the switch matrix to connect the “preferred” line to the given trunk.
In block 911, it is determined whether the scan over the trunks whose Optimization Status Field is set to ‘OP’ is complete. If not, the operation returns to block 903 to perform the operations of blocks 905 through 909 for another idle trunk. If the scan is complete, the operation ends. In this manner, the connections of the switch matrix for the idle trunks and lines are updated for inbound call processing.
If, in block 1007, it is determined that the user has not disabled routing over connections for the class corresponding to the heuristic, the operations continue to block 1011. In block 1011, the Outbound Routing Table(s) are modified, if need be, to enable VOIP-based call routing over the VOIP trunks coupled to the voice router 58, and the operations return to block 1001 to continue monitoring the QOS of the VOIP network.
There have been described and illustrated herein several embodiments of a system, method and apparatus that provide improved voice routing capabilities. While particular embodiments of the invention have been described, it is not intended that the invention be limited thereto, as it is intended that the invention be as broad in scope as the art will allow and that the specification be read likewise. Thus, while particular data structures and processing operations have been disclosed, it will be appreciated that other data structures and processing operations can be used to realize the improved voice routing capabilities of the present invention as described herein. In addition, while particular applications of the improved voice routing mechanisms and systems based thereon have been disclosed, it will be understood that such mechanisms can be similarly used in other applications and systems. For example, the voice routing mechanisms can be used to route calls over the PSTN Network and calls over a Wide Area Telephone Service (WATS) trunk. The WATS trunk provides a bulk savings plan for companies with a high volume of toll calls, such as telemarketing companies. In another example, the voice routing mechanisms can be used to route calls over different VOIP networks such as first VOIP network (with guaranteed QOS, reliable service but relatively expensive) and a second VOIP network (with no guaranteed QOS but relatively inexpensive). In another example, the voice routing mechanisms described herein need not interface to POTS-based analog telephony device, but can readily interface to a wide variety of telephony devices (and lines), such as IP telephony devices, in order to provide for intelligent call routing for such devices. Moreover, while particular configurations of lines, trunks, and multi-channel trunks have been disclosed, it will be appreciated that other configurations could be used as well. Furthermore, while the present invention as described above utilizes a microprocessor system to realize call/route processing and switch control, it will be appreciated that other logic means, including an application specific integrated circuit, programmable logic device or other logic device, can be used. It will therefore be appreciated by those skilled in the art that yet other modifications could be made to the provided invention without deviating from its spirit and scope as claimed.
