Patent Application
20080095144
The following description, given with respect to the attached drawings, may be better understood with reference to the non-limiting examples of the drawings, wherein:
The bandwidth manager includes a bandwidth monitor for monitoring the available bandwidth of plural routes within the corresponding network. As illustrated, a primary, higher bandwidth link (HBL), and a secondary, lower bandwidth link (LBL) are monitored by the bandwidth monitor. When the bandwidth monitor determines that the primary, higher bandwidth link is experiencing a failure or a degradation in bandwidth (e.g., the link is performing at less than a threshold bandwidth), the bandwidth monitor notifies a call filter of the failure or degradation. In response, the call filter can deny additional voice channel requests unless the requests are for higher priority calls (e.g., calls to or from emergency services or emergency service answering points).
In the embodiments of
Returning to
Later, as shown in
As illustrated in
In an alternate embodiment, additional levels of similar or different bandwidth links may be monitored by a bandwidth monitor (rather than just the two levels depicted in
A bandwidth manager can be interposed between a telephony client and a telephony backend in a number of ways. First, the telephony clients can be configured to make all call connection requests to the Call Filter directly. For example, instead of configuring a telephony client to request call connections via the softswitch at softswitch.sharedsoftswitch.com, the telephony client instead is configured to request call connections via the Call Filter at callfilter.localnetwork1.com. (It is anticipated that with good programming practices, the configuration can be done by storing the name of the Call Filter in a configuration file internal to the telephony client rather than requiring reprogramming of the telephony client. However, the storing of the name may be done through reprogramming as well. e.g., by updating flash memory.)
When the bandwidth monitor determines that the higher bandwidth link is not experiencing a failure or degradation, the Call Filter (at callfilter.localnetwork1.com) passes the call request on to the softswitch (at softswitch.sharedsoftswitch.com) and provides any responses to the telephony client. When the bandwidth monitor determines that the higher bandwidth link is experiencing a failure or degradation and the call request is for a higher priority call, the Call Filter passes the call request on to softswitch.sharedsoftswitch.com and provides any responses to the telephony client. However, when the bandwidth monitor determines that the higher bandwidth link is experiencing a failure or degradation and the call request is not for a higher priority call, the Call Filter blocks the call request from being sent on to the softswitch and instead notifies the telephony client of the unavailability, as described above. In such an embodiment, the Call Filter is designed and programmed to be able to understand the format of the call request sufficiently well to be able to determine whether or not the call request is for a higher priority call. For example, the Call Filter may be programmed to understand SIP, MGCP or other protocols in sufficient detail to know where the telephone number is stored in the request, and the telephone number would then be compared against a list of higher priority numbers to determine if a match exists.
A second method of interposing the bandwidth manager between a telephony client and a telephony backend is to intercept DNS inquiries. In such a case, if a telephony client has been configured to request call connections via the softswitch at softswitch.sharedsoftswitch.com, the Call Filter receives the DNS inquiry to convert the name softswitch.sharedsoftswitch.com into an Internet address. In response, instead of providing the telephony client with the IP address of softswitch.sharedsoftswitch.com, the Call Filter provides the telephony client with the IP address of the Call Filter at callfilter.localnetwork1.com. Like in the first method, when the bandwidth monitor determines that the higher bandwidth link is not experiencing a failure or degradation, the Call Filter passes the call request on to softswitch.sharedsoftswitch.com and provides any responses to the telephony client. When the bandwidth monitor determines that the higher bandwidth link is experiencing a failure or degradation, the Call Filter passes or blocks the call request depending on whether or not the call request is for a higher priority call. In such an embodiment, the Call Filter is designed and programmed to be able to understand the format of the call request sufficiently well to be able to determine whether or not the call request is for a higher priority call.
A third method of interposing the bandwidth manager between a telephony client and a telephony backend is to intercept packets for known IP addresses. In such a case, if a telephony client has been configured to request call connections via the softswitch at softswitch.sharedsoftswitch.com, the Call Filter uses a DNS inquiry to convert the name softswitch.sharedsoftswitch.com into an Internet address and begins examining packets for that IP address. Like in the first and second methods, when the bandwidth monitor determines that the higher bandwidth link is not experiencing a failure or degradation, the Call Filter passes the call request on to monitored IP address of softswitch.sharedsoftswitch.com and provides any responses to the telephony client. When the bandwidth monitor determines that the higher bandwidth link is experiencing a failure or degradation, the Call Filter passes or blocks the call request depending on whether or not the call request is for a higher priority call. In such an embodiment, the Call Filter is designed and programmed to be able to understand the format of the call request sufficiently well to be able to determine whether or not the call request is for a higher priority call.
The list of higher priority numbers may be a global list (i.e., the same for all telephony clients) or a client-specific list of higher priority telephone numbers (either PSTN-style telephone numbers or IP-address style telephone numbers) matched to telephony client identifiers such that the same telephone number may be a high priority call for some telephony clients but not others, or a combination of both such that the client-specific list if checked first and if there is no match then the global list is checked. Either the global list or the client-specific list (or both) may further include times-of-day or time ranges in which the call blocking or call passing should occur. Furthermore, the list of high priority numbers may be stored either locally or remotely, and in one embodiment queries are made to a remote server to determine if a number is a high priority number.
While the above discussion has focused on requests coming from the telephony clients and going to the back-end, requests can be controlled in the opposite direction as well. Thus,
In addition to or instead of filtering in the telephony protocols described above, it is also possible for the Filter to be configured to filter other requests other than telephony requests. For example, connections to specific IP addresses or server names and/or connections to specific services/ports at specific IP addresses or server names can be filtered or redirected as well. In one such embodiment, a bandwidth manager detects a request for an HTTP port connection at a known address. Because a network administrator is trying to reduce bandwidth on the network (e.g., when the bandwidth monitor determines there is congestion), the filter begins filtering out requests by specified criteria (e.g., by site name or by request type such as videos which are known to consume bandwidth). Thus, the filter is programmed to know a sufficient amount of information about the protocol being filtered to know where the relevant protocol-specific field is (e.g., where the site address or URL name is in an HTTP request).
The filter (like the Call Filter) may additionally be configured to perform filtering based on times-of-day such that bandwidth is controlled to avoid congestion (e.g., by limiting sites or types of content during peak hours).
In addition to the above, call filtering may also be performed by configuring the telephony clients themselves with a list of higher priority numbers (or lower priority numbers) that should be treated differently than numbers not on the list. For example, the telephony clients may be programmed to check an internal list and, if the number to be called is on the list, then the client connects to a corresponding softswitch without needing further filtering. In this way, a telephony client need not connect to the Call Filter when trying to reach higher priority numbers (e.g., emergency services) and instead will connect to the softswitch directly. However, when the number is not on the list, then the telephony client is programmed to connect to the Call Filter instead. The Call Filter can then, as described above, either accept or reject the call request depending on the status of the available connections.
In the embodiment of
Furthermore, although the above description has been given with respect to centralized media gateways at a single physical or logical location, the method of the present invention is also possible with distributed media gateways as well, where connections to those locations are independently “bandwidth monitored.”
While certain configurations of structures have been illustrated for the purposes of presenting the basic structures of the present invention, one of ordinary skill in the art will appreciate that other variations are possible which would still fall within the scope of the appended claims.
