Method and Apparatus for Routing Voice Calls over Voice Over Internet Protocol Networks

Abstract

A method is provided for improving voice quality of Voice over IP networks in which a highest-quality routing protocol is interposed between a local IP PBX exchange and a cloud-based Internet service provider server to which calls are to be routed, wherein the highest-quality routing protocol detects the quality of the voice channel between the local IP PBX exchange and cloud-based Internet service provider servers and routes voice calls to that cloud-based Internet service provider server exhibiting the highest voice call quality, with the highest voice quality server connection determined by detecting lost packets and packet delay between the local IP PBX exchange and a server.

Claims

1. A system for connecting Voice over IP calls, the system comprising: one or more premise-based telephones; a local IP PBX exchange coupled to said one or more premise-based telephones and configured to be connected to one of a number of cloud-based Internet service provider servers through session border controller switches associated with the cloud-based servers based on the quality of the voice channel between the local IP PBX exchange and a cloud-based Internet service provider server; and a highest-quality routing protocol installed on the local IP PBX exchange, wherein the highest-quality routing protocol is configured to detect voice channel quality between the local IP PBX exchange and a cloud-based Internet service provider server and to route a voice call to a cloud-based Internet service provider server exhibiting the highest voice call quality.

2. The system of claim 1, and for generating a score reflective of said lost packets and packet delays, wherein a lower score reflects a lower number of lost packs and lower packet delays, said local IP PBX exchange including a comparator for comparing the scores associated with each of said cloud-based Internet service provider servers and for routing voice calls from and to said premise-based telephones to a cloud-based Internet service provider server having the lowest score.

3. The system of claim 2, and further including a load factor detector at said local IP PBX exchange for detecting the load at each of said cloud-based Internet service provider servers and for adjusting the score of a server based on the load at said server.

4. The system of claim 2, wherein said local IP PBX exchange initiates said packet string every 20 to 40 seconds.

5. The system of claim 4, wherein said packet string is generated automatically and without regard to voice over IP calls processed by said local IP PBX exchange.

6. The system of claim 5, wherein once said local IP PBX exchange is connected to a cloud-based server, the voice call stays connected to the selected server until the voice call is terminated.

7. The system of claim 5, wherein said packet string is transmitted utilizing a user datagram protocol.

8. The system of claim 3, wherein a load request is transmitted independently of said packet string.

9. The system of claim 8, wherein said load request is timed so as not to interfere with the transmission or receipt of said packet string.

10. The system of claim 1, wherein said cloud-based Internet service provider servers include multiple remotely located servers in different geographic locations such that an outage of one server does not affect the operation of other servers.

11. The system of claim 1, wherein the quality of said voice channel is determined by the number of lost packets and packet delay.

12. The system of claim 1, wherein the quality of said voice channel is determined by a history of lost packets and packet delays to introduce hysteresis.

13. A method for improving voice quality of Voice over IP networks, the method comprising: installing a highest-quality routing protocol on a local IP PBX exchange, wherein the highest-quality routing protocol detects the quality of a voice channel between the local IP PBX exchange and a cloud-based Internet service provider server and routes a voice call to a cloud-based Internet service provider server exhibiting the highest voice call quality.

14. (canceled)

15. The method of claim 13, wherein the highest voice call quality is determined by detecting lost packets and packet delay between the local IP PBX exchange and a cloud-based Internet service provider server.

16. The method of claim 13, wherein the highest voice call quality is determined by a history of lost packets and packet delay between the local IP PBX exchange and a cloud-based Internet service provider server to introduce hysteresis.

17. The method of claim 13, wherein the highest voice call quality is additionally determined by the load on a cloud-based Internet service provider server.

18. The method of claim 13, wherein highest voice call quality is provided by probing of the Internet service provider servers with a packet string and reflecting the packet string as an echo back to the local IP PBX exchange.

19. The method of claim 18, wherein the local IP PBX exchange determines a highest voice quality server connection based on the echo reflected back packet strings.

20. The method of claim 19, wherein the highest voice quality server connection is determined by the lost packets and packet delays associated with the echo reflected back packet strings.

21. The method of claim 20, wherein the highest voice quality server connection is determined by a history of the lost packets and packet delays.

22. The method of claim 20, wherein the highest voice quality server connection is additionally determined by the load on a cloud-based Internet service provider server.

23. A system for connecting Voice over IP calls, the system comprising: one or more premise-based telephones; and a local IP PBX exchange coupled to said one or more premise-based telephones and configured to be connected to one of a number of cloud-based Internet service provider servers, the local IP PBX exchange comprising: a load factor detector for detecting a load at each of said cloud-based Internet service provider servers; a packet string generator for periodically generating packet strings and transmitting the packet strings to said cloud-based Internet service provider servers; detectors for detecting a number of lost packets and packet delay to each of the cloud-based Internet service provider servers; and a highest-quality routing protocol installed on the local IP PBX exchange, wherein the highest-quality routing protocol is configured to detect voice channel quality between the local IP PBX exchange and a cloud-based Internet service provider server and to route a voice call to a cloud-based Internet service provider server exhibiting the highest voice call quality, wherein the cloud-based Internet service provider server exhibiting the highest voice call quality is determined based on the load at the cloud-based Internet service provider server, the number of lost packets from the cloud-based Internet service provider server, and packet delay from the cloud-based Internet service provider server.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0023] These and other features of the subject invention will be better understood in connection with the Detailed Description in conjunction with the Drawings of which:

[0024] FIG. 1 is a diagrammatic illustration of an enterprise which is adapted to receive voice calls over a number of different lines utilizing a Voice over IP service;

[0025] FIG. 2 is a diagrammatic illustration of a prior art VoIP network which suffers from packet loss, delay and jitter that results in the late packets, lost packets and in general a lack of audio quality;

[0026] FIG. 3 is a diagrammatic illustration of a prior art over the top VoIP service provider interposed between the customer and a backbone carrier serving as a public switch telephone network;

[0027] FIG. 4 is a diagrammatic illustration of the subject VoIP system in which a premise layer is coupled to a switch layer that is in turn coupled to a PSTN link, in which the premise layer includes a premise-based local exchange updated with the subject HQRP recall that is utilized in measuring call path quality and switching the voice call to a path which offers optimal reliability;

[0028] FIG. 5 is a system architecture diagram illustrating a premise-based application layer, switching layer and a server layer;

[0029] FIG. 6 is a diagrammatic illustration of an updated premise-based local exchange that functions to send out a packet string probe every 20 to 40 seconds and is and adapted to measure the echo in terms of packet delay, jitter and packet loss plus load, which measurements are utilized in an HQRP algorithm to calculate a score reflecting call path quality used to select the best server to which to route a voice call; and,

[0030] FIG. 7 is a block diagram illustrating the interposition of the HQRP protocol between multiple ISPs in the cloud to route to multiple pairing partitions having geographic diversity in which the voice call is routed by selecting the best switch in the network.

DETAILED DESCRIPTION

[0031] Prior to describing the subject invention and by way of further introduction, in the subject invention, a Highest Quality Routing Protocol (HQRP) utilizes Total Connect Now, TCN, updated IP PBX exchanges and switches to make dynamic decisions about outbound voice calls, i.e. TCNs-to-switches, and inbound voice calls i.e. PSTN trunk-to-switch-TCN call routing based on current and recent network conditions. The protocol determines the current “best” destination for a call and adjusts that determination as conditions change.

[0032] As will be discussed, the protocol works in three phases: an active measurement phase where network conditions are probed, a scoring phase where the results of the measurements are scored and a comparison phase where the best route is determined.

[0033] Referring now to FIG. 1, what is shown is an enterprise 10 to which a number of voice call lines 12 couple voice calls from a number of different individuals 14 through TCP/IP networks carried in the cloud 16. It is important that the quality of these voice calls both from callers from outside the enterprise and voice calls from the enterprise to the incoming callers be of high quality. There is nothing which turns off the customer faster than not being able to communicate one's order to a call taker and then not to understand the call taker and furthermore not to be understood. Not only are dropped calls and the like counterproductive for an enterprise receiving inbound calls, there is more frustration than necessary when trying to understand an inbound caller or for the inbound caller not to be able to understand the call taker. It is for this reason that enterprises are not inclined to use VoIP services, despite the lower cost of some of these services versus dedicated landline systems.

[0034] Referring to FIG. 2, in prior art VoIP systems a customer 20 is connected to the cloud 22 at which VoIP servers reside which then connect a customer to an enterprise. Because of packet loss, delay or jitter, the net result is delayed packets and lost packets which contribute to lack of intelligibility of those voice calls that are in fact completed, to say nothing of the loss of a connection between the customer and the enterprise.

[0035] Referring to FIG. 3, the situation is shown in which a customer 20 is connected to a VoIP provider 24, namely an Internet service provider connected to a public switched telephone network, PSTN, 26 that functions as a backbone carrier. Such carriers are in general MSOs. In FIG. 3, the use of VoIP servers is called over-the-top service, in which there is no direct link to the public switch.

[0036] Referring to FIG. 4, in the subject system there is a premise layer 30 having telephone equipment within the enterprise which is connected to a switch layer 32 in the cloud that switches voice calls from the premise layer to various servers 34 that serve as PSTN links from the equipment at the premise to callers seeking to communicate with the enterprise.

[0037] Referring to FIG. 5, from an architecture point of view, a premise-based application layer 40 having a number of individual telephones 42 is connected to a switching layer 44 in the cloud 46. The switching layer in turn is coupled to a server layer 48 in the cloud 46 in which the servers are owned by Internet service providers, in the subject case, VoIP service providers. When voice communication is coupled to a particular server, this server is connected to an MSO. It is the purpose of the subject invention to be able to organize calls from the application layer by switching calls to VoIP servers in the cloud that constitute the most robust connection.

[0038] As will be seen, this is accomplished by a premise-based IP PBX updated with the HQRP algorithm that is located at the enterprise and which interfaces all telephones at the enterprise with switches and VoIP servers in the cloud so that routing of voice calls can be accomplished utilizing the most reliable call path. How the most reliable call path is ascertained will be described hereinafter. What is important to remember is that in the subject system the routing system is based at the enterprise's premise and it is to this routing system that all telephones at the premise are coupled. The routing system includes a probing system to be able to measure the voice call quality between the premise and the cloud-based servers, with the probe being echoed back. In one embodiment, the probe is a packet string together with a load level probe that ascertains packet loss and delay as well as the load on a particular switch and thus the load on a particular VoIP server.

[0039] During the probing process not only is the load on a server ascertained, the quality of the call path between the enterprise and the switch is measured by measuring lost or delayed packets which are echoed back. The results of these two probing exercises are used to develop a score that is utilized to select to which VoIP server the calls are to be routed. In one embodiment, the lower the score, the lower the amount of lost packets and the lower the amount of delay such that the VoIP server having the lowest score is selected for the call. How this is accomplished is now described in FIG. 6.

[0040] Referring to FIG. 6, a telephone 50 is used for the receipt and transmission of calls along a call path 52 which is routed through switches 54 to a selected VoIP server 56 depending on the state of the switch. These switches are in general cloud-based session border controllers which are coupled to cloud-based servers. The servers themselves are connected to MSOs 58 for completion of a voice call between a caller and the particular enterprise involved.

[0041] All voice calls from phone 50 are routed through a premise-based local exchange 60 or TCN IP PBX updated with the HQRP software. The Total Connection Now PBX 60 at the enterprise serves to connect multiple phone lines through cloud 62 based VoIP servers to the MSOs. It will be appreciated that all of the routing intelligence is contained within the TCN IP PBX 60 such that by providing the enterprise with such a premise-based local exchange one can quickly adapt telephone service at an enterprise to connect to the best VoIP server.

[0042] It will be noted that the TCN IP PBX 60 has a function first to send a packet string every 20 to 40 seconds as illustrated at 64 over trunk line 66 to all of the VoIP server switches 54. These packet strings are diagrammatically illustrated as being transmitted over lines 68 to echo modules 70, one each associated with a server. Incoming packet strings are reflected back by echo modules 70 back to the TCN IP PBX 60 over trunk 66 at which point packet delay, jitter and packet loss are measured at 72. It is also a feature of TCN IP PBX 60 to transmit probes from a load level probe 76 to probe the load level on each of the servers and to report back the load level to measurement module 72. The probing of the voice call channel conditions by the packets from probe 64 can occur independently of the load level probe packets sent by load level probe 76. Regardless, the channel conditions and the load levels are transmitted back to the TCN IP PBX where the aforementioned measurements are made.

[0043] Having made these measurements, the results are applied to an HQRP algorithm 80 that is used to calculate a score as illustrated at 82 which is then utilized to select the best server as illustrated at 84 that results in activating a particular switch 54 having the best call path characteristics. The switches 54 are actuated from the output of the best server selection module 84 over lines 86. Note that the packet string probing can be done over a user datagram protocol, UDP which is one of the simplest communications models available. On the other hand, load level probing can be accomplished utilizing a specialized UDP packet sent to the switch load port, with a daemon listening to that port to read the incoming messages and respond to them.

[0044] What is now described in detail are the functional characteristics of the parts of the subject routing protocol.

TCN Configuration

[0045] Each TCN IP PBX 60 is assigned a pool of switches to use as possible candidates for outbound and inbound calls. The optimal size of this pool must be large enough to contain sufficient geographical and provider diversity to prevent “shared fate” events from disrupting all switches in the pool while also being small enough to prevent a significant load on the switches from the active measurements they receive.

Measurement Phase

[0046] The measurement phase includes active probing at 64 of the network conditions from the originating TCN 60 to each switch 54 in its pool and determining at load probe 76 the load level of each switch in its pool.

Network Probing

[0047] A node 64 probes the network conditions between itself and a routing candidate by periodically emitting a burst of echo packets. For TCNs, these echo packets are in the udpping.php format. The emitting node records the transmit time of each packet and then listens for returned packets and records the receive time of each packet received. After a suitable period of time, the node examines the returned packets and determines the maximum round trip time and the number of lost packets.

[0048] After determining the results from a burst, the node schedules a next burst at a randomly chosen time between the minimum and maximum burst times.

Switch Load Measurement

[0049] Periodically, TCN IP PBX 60 determines the current load level of its switches by sending a load request packet at 76 to each switch 54. Each switch runs a daemon that is a computer program that runs as a background process that responds to these packets by returning the current number of calls being served divided by a configured maximum calls value (times 100 to make it a percent load). After sending the load request packet to a switch, TCN IP PBX 60 schedules the next request at a randomly selected time between minimum and maximum load request times.

[0050] In one embodiment, the load request protocol employs the User Datagram Protocol, UDP, which uses a simple connectionless transmission model with a minimum of protocol mechanism that does not require a handshake. In so doing, requests and responses may be lost in the network. If a packet is lost, that measurement is effectively skipped and there are no retries.

Scoring Phase

[0051] After each measurement is complete, the current state of data for the upstream node is scored at 82. The scoring process uses the following parameters from the current measurements:

lostpkts—the number of packets from the burst that were not received.
maxrtt—the maximum round-trip-time experienced by received packets.
loadLevel—the most recently received load level

[0052] Scoring uses the following parameters from the recent history of measurements:

cumlostpkts—a history of lost packets that increases with lost packets and slowly decays during periods of no packet loss.
cummaxrtt—a maximum recently seen round trip time that decays as “low” maximum round trip times are seen.
Also, scoring uses configurable constant values shown in all caps in the pseudo-code.

[0053] The scoring algorithm process proceeds as in the following pseudo-code:

If lostpkts is greater than cumlostpkts, set cumlostpkts to lostpkts
If lostpkts is zero, decrement cumlostpkts (do not go below zero) [0054] If cumlostpkts is zero set score to zero, else set score to floor(cumlostpkt/SCORELPKTSTEP)+1
If maxrtt is less than cummaxrtt, subtract SCORERTTSTEP from cummaxrtt (do not go below zero)
If maxrtt is greater than cummaxrtt, set cummaxrtt equal to maxrtt
Add floor(cummaxrtt/SCORERTTSTEP) to score
If loadLevel is greater than SWLOADHIGH add SWLOADHIGHPENALTY to score
Else if loadLevel is greater than SWLOADMED add SWLOADMEDPENALTY to score
Once a score has been computed, the process enters the comparison phase.

Comparison Phase

[0055] In the comparison phase, the scores from all the monitored targets are compared at 84 to determine primary and backup destinations for outbound calls. Simplistically, the primary is the target with the lowest score and the backup is the target with the second lowest score.

[0056] The comparison phase operates as in the following pseudo-code:

Create a selection list
Extract the targets with the lowest score
If the current primary target is in this group, select it as the primary
Else randomly select a primary from the group
Remove the selected primary target from the selection list
Extract the targets with the lowest score
If the current backup target is in this group, select it as the backup
Else randomly select a backup from the group

Inbound HQRP

[0057] Inbound HQRP allows TCNs to choose the switch that will receive inbound calls that are destined for it. Periodically (120 seconds+-20 seconds by default), TCNs running HQRP send their current primary switch choice to the inbound HQRP daemon (inhqrpd, running on tcn2.uotcn.net by default). When inhqrpd receives an update that has a different switch choice than the last update received (or if no previous update), it finds all Direct Inbound Dialing, DIDs, that belong to that TCN (using the ‘ownertcn’ column of the DirectInwardDialNumbers table) and then uses the Vitelity API to update routing for those numbers to the new switch.

[0058] Switch updates are not sent immediately after a change in chosen switch in order to reduce unnecessary fluctuations in the routing and to reduce the load on the Vitelity API.

[0059] Updates are sent via UDP and there is only one copy of inhqrpd running in the network. The effect of updates being lost is to freeze the routing at the current state until the next update. The effect of inhqrpd failing is to freeze the routing until inhqrpd can be restarted. Neither of these are serious failures since the network continues to operate, albeit perhaps sub optimally, during the failures.

[0060] Protocol Configuration Values

HQRP uses the following configurable values:
BURSTCHECKTIME (default 2): The time (in seconds) to accumulate receive packets after a burst is sent.
BURSTPORT (default 5080): The destination port for updping echo packets.
BURSTLENGTH (default 50): The number of packets in a burst.
BURSTTIMEMIN (default 20):
BURSTTIMEMAX (default 40): The minimum and maximum times (in seconds) between burst measurements.
SCORERTTSTEP (default 0.1): The round trip time scoring step time (in seconds).
SCORELPKTSTEP (default 5): The packet loss scoring step size (in packets).
SWLOADTIMEMIN (default 30):
SWLOADTIMEMAX (default 60): The minimum and maximum time between switch load requests (in seconds).
SWLOADHIGH (default 80): The switch load level considered “high” (in percent).
SWLOADHIGHPENALTY (default 50): The value to add to score when the load level is above

SWLOADHIGH.

[0061] SWLOADMED (default 50): The switch load level considered “medium” (in percent).
SWLOADMEDPENALTY (default 10): The value to add to score when the load level is between SWLOADMED and SWLOADHIGH.
SWLOADPORT (default 5090): The destination port for load requests.
INHQRPPORT (default 5095): The destination port for the inbound HQRP server
INHQRPTARGET (default tcn2.uotcn.net): The host for the inbound HQRP server
INHQRPMINTIME (default 100): Minimum time (seconds) between inbound HQRP reports
INHQRPMAXTIME (default 140): Maximum time (seconds) between inbound HQRP reports

[0062] In summary and referring to FIG. 7, the customer 90 is routed by the HQRP protocol 92 to multiple ISPs 94 which in turn couple a voice call from the customer to a PSTN 96. The purpose of the HQRP protocol is to provide robust voice calls through multiple pairing at partitions, to provide geographic diversity and to implement the HQRP protocol to select the best switch and network.

[0063] While the present invention has been described in connection with the preferred embodiments of the various figures, it is to be understood that other similar embodiments may be used or modifications or additions may be made to the described embodiment for performing the same function of the present invention without deviating therefrom. Therefore, the present invention should not be limited to any single embodiment, but rather construed in breadth and scope in accordance with the recitation of the appended claims.