Source: https://patents.google.com/patent/US8457000B2/en
Timestamp: 2018-11-18 23:10:16
Document Index: 283888991

Matched Legal Cases: ['Application No. 60', 'Application No. 60', 'Application No. 07797624', 'Application No. 2003', 'Application No. 07797624', 'Application No. 07797624']

US8457000B2 - Call quality monitoring - Google Patents
Call quality monitoring Download PDF
US8457000B2
US8457000B2 US11751355 US75135507A US8457000B2 US 8457000 B2 US8457000 B2 US 8457000B2 US 11751355 US11751355 US 11751355 US 75135507 A US75135507 A US 75135507A US 8457000 B2 US8457000 B2 US 8457000B2
US11751355
US20080063149A1 (en )
Communications Acquistions LLC
This patent, application claims the benefit of, and priority to, U.S. Provisional Application No. 60/809,063 filed on May 26, 2006. The contents of U.S. Provisional Application No. 60/809,063 are hereby incorporated by reference into this patent application as if set forth herein in full.
Problems can arise during transmission of telephone calls over a network. For example, excessive network traffic can create a bottleneck at a node on the network, thereby affecting the quality of telephone calls transmitted through the node. Also, a node on the network can fail or function improperly, which can also have a deleterious effect on telephone calls transmitted through the network. These problems are not unique to telephone calls that are implemented using. VoIP (e.g., telephone calls routed over a computer network), bin rather such problems can occur in any network over which telephone calls are routed.
The metric may comprise at least one of data, packet loss and jitter of the data packets. The method may comprise performing a traceroute through the network to obtain the metric, increasing a frequency of the traceroute if the metric exceeds the threshold, obtaining a second metric after increasing the frequency of the traceroute, determining whether the second metric exceeds the threshold, and adjusting a frequency at which the traceroute is performed based on whether the metric exceeds the threshold.
The method may comprise receiving information from nodes of the network, and rooting subsequent telephone calls based on the information. The information may comprise one or more records associated with telephone calls routed through different paths of the network. The method may comprise using the information and other information relating to routing of other telephone calls through the network to locate a problem on the network. The subsequent telephone calls may be rented to attempt to avoid the problem. The metric may relate to degradation in call quality. The degradation represented by the metric may not be detectable by a human ear. The metric may be weighted. The weight may correspond to a system that initiates the telephone call.
The method may include using real-time transfer protocol (RTP) data and/or real-time transfer control protocol (RTCP) data to identify the fault in the network or to identify a limit is another network that is inbound or outbound to the network. The RTP data and/or the RTCP data may be used to identify faults in the network by time based on a condition of the network.
The details of one or more examples are set form in the accompanying drawings and the description below. Further features, aspects, and advantages will become apparent from the description, the drawings, and the claims.
FIG. 1 shows a network 10, over which devices 11 a to 11 e, such as telephones, communicate. Devices 11 a to 11 e (which are hereinafter referred to as “communication devices”) may be VoIP-enabled, or non-VoIP-enabled. For example, the communication devices may be standard telephones, cellular telephones, VoIP-enabled telephones, or any combination thereof. The communication devices may also include processing devices, such as computers or any other data processing apparatus including, but not limited to, desktop or laptop computers, personal digital assistants (“PDAs”), and gaming devices.
For the purposes of this description, network 10 can be conceptualized as a set of nodes. These nodes include endpoint devices (or simply, “endpoints”) 12 a to 12 e and intermediary devices 14 a to 14 h for routing data, including telephone calls, between the various endpoints. Examples of intermediary devices include, but are not limited to, routers, switches, gateways, or the like. Examples of endpoints include servers for routing telephone calls, monitoring call quality, and adjusting routing based on call quality, as described in more detail below. Other examples of endpoints include servers or other computers that are maintained by services provides including, but not limited to, long-distance providers, such as MCI® and Sprint®, or VoIP providers.
Each of endpoints 12 a to 12 e may be identical in structure and function, or at least have certain structure and functionality in common. This common structure and functionality is described with respect to endpoint 12 a (FIG. 2). Since the other endpoints contain this structure and functionality, detailed descriptions thereof are omitted.
Endpoint 12 a may include one server 15 a or multiple server 15 a to 15 c (servers 15 b and 15 c are depicted using dashed lines to indicate that they are optional). Each of servers 15 a to 15 c may have the same, or similar, hardware and/or software, configuration. In this implementation, servers 15 a to 15 c act together to perform, the various functions described below, in other implementations, a single server may perform all of the server functions. In the case of multiple servers, server 15 a may act as a controller or “load balancer” for the remaining servers 15 b and 15 c. In this role, server 15 a may route, data, requests, and instructions between a client (e.g., a VoIP communication device) and a “slave” device, such as server 15 b. Server 15 a may store information locally, then route data to another device, such as device 15 b. For the purposes of the following, such internal communications between server 15 a and any slave devices will be assumed.
Server 15 a may be any type of processing device that is capable of receiving and storing data, and of communicating with VoIP clients. As shown in FIG. 2, server 15 a includes one or more processors 16 and memory 17 that stores computer programs that are executed by processor(s) 16. In this regard, memory 17 stems a computer program 19 for communicating with other devices using, e.g., session initiation protocol (SIP). Memory 17 also contains one or more computer programs 20 for executing process 25 described herein, and one or more storage areas 21 for use as data storage.
As shown in FIG. 1, in this implementation, each communication device 11 a to 11 e communicates over network 10 via an endpoint. For example, VoIP-enabled communication device 11 a communicates through endpoint 12 a; VoIP-enabled communication device 11 b communicates through endpoint 12 b; non-VoIP-enabled communication device 11 d communicates through endpoints 12 e and/or 12 d; and so on. In other implementations, one or more of communication devices may sot go through an endpoint to reach network 10.
Referring to FIG. 3, process 25 is shown which may be performed by computer program 20 in one or more endpoints to monitor the quality of one or more telephones call transmitted across network 10, and/or to re-route one or more subsequent telephone calls based on information obtained via the monitoring. Process 25 will be described in the context of endpoint 12 a (here, a computer, such as a server), however, process 25 may be performed by any and all endpoints or other devices on network 10.
According to process 25, endpoint 12 a makes (30) a telephone call over network 10. That is, endpoint 12 a receives call data from a communication device 11 a, such as a telephone. Endpoint 12 a may then formulate a call, e.g., to another endpoint 12 d, such as a server for a long distance provider. In this implementation, the call is established using SIP and data packets for the call are transferred using RTP. Real-time transfer control protocol (RTCP) is used to provide out-of-band control information RTP. RTCP provides feedback on the quality of service (QoS) being provided by RTP. QoS may also be based on evaluation of the RTP packets. One feature of RTCP is that it provides for monitoring of lost data packets and jitter at the source of a call at the destination of a call, and at one or more nodes between the source and destination. Jitter is a variation in packet transit delay, which may be caused by several factors including, but not limited to, queuing, contention and serialization effects. With respect to monitoring lost data packets, data packets are typically sequential. RTCP is able to identity lost data packets based on a break in the packet sequence.
By using RTP and RTCP collected data, faults can be associated wits a local network, an inbound network, or an outbound network. Furthermore, changes in call quality may vary by time-of-day, e.g., times with greater amounts of traffic may experience lower call quality. The RTP and RTCP may be used to identify the times of day that provide lowest call quality for given network conditions.
Process 25 obtains (32), via the traceroute, one or more metrics associated with the call. That is, in response to the ping, the device that initiated the traceroute receives information (the metrics) from the device that was “pinged”. In this implementation, the metrics include, but are not limited to, amounts of jitter and packet loss between the source and destination of the call. As indicated above, RTCP provides for monitoring of lost data packets and jitter from the source of a call. The traceroute obtains this RTCP-maintained information. The traceroute also enables identification of nodes of network 10 that have failed or that are not working properly. Referring to FIG. 1, for example, process 25 may receive no information beyond node 14 c (between, source 12 a and destination 12 e) in response to the traceroute. From this, process 25 may infer that one or more nodes beyond node 14 c has either failed, or is not working properly.
In this implementation, a threshold may correspond to an acceptable QoS, and may relate, e.g., to an acceptable amount of jitter and/or an acceptable packet loss (e.g., twenty packets lost in a live second interval). The amount of call degradation represented by the threshold may not be detectable by the human ear. Thus, routing corrections may be made, as described below, before call degradation on a route reaches an audible level.
Process 25 continues to perform trace-routes as described above during the course of the call. The information obtained via the traceroutes may be stored in endpoint 12 a. As explained above, this information defines the QoS associated with the call, and may include the number of packets lost during the call or during a predefined period of the call, the amount of jitter during the call or during a predefined period, and information indicating problems in network 10, such as which network nodes are disabled.
More specifically, the central monitoring system receives the QoS information from the various endpoints (or other devices) on network 10 and, based on that information, designates call routes through network 10. The central monitoring system may designate routes that have the fewest number of packets lost, routes that have the least jitter, routes in which no device are inoperable or disabled, routes that have the shortest path to a destination, or some combination thereof.
In designating its routes, the central monitoring system may use information from the various endpoints to identify, with greater precision, faults on network 10. Since the central monitoring system receives information from endpoints that have used different routes through the network, the central monitoring system is able to use triangulation to identify faults on network 10. For example, the central monitoring system may receive information from device 12 d that it does not receive traceroute information beyond node 14 e. The central monitoring system may also receive information from device 12 e that it is able to access endpoint 12 b. Knowing this, and the configuration of network 10, the central monitoring system is able to ascertain that node 14 d is not operating properly and, as such, designate routes that do not include node 14 d in an attempt to avoid network faults. Factors other than those described above may also be taken into consideration by the central monitoring system when designating routes through network 10. For example, the central monitoring system may correlate data packet loss and jitter over the network based on a sequence of traceroutes (or pings) to determine loss over the network. The correlation may also be over time, and from a single or multiple nodes, in order to determine the location of a fault on the network.
The designated routes may be distributed from the central monitoring system to the various endpoints. Updates to these routes may be made via process 25, which may be performed on a continuous basis in order to keep the routes up-to-date. Each endpoint may then route subsequent telephone calls in accordance with its designated route(s). For example, the subsequent telephone calls may be routed to avoid problems on network 10.
The central monitoring system may designate routes that are advantageous for each device given the device's location on network 10. Also, weights may be assigned to QoS information from different endpoints. As a result, some endpoints (e.g., predefined trusted endpoints) may have a greater effect on the routes designated by the central monitoring system than others. In like manner, a group or groups of endpoints may be given greater weight man others endpoints.
Process 25 and its various modifications (hereinafter referred to as “the processes”) can be implemented, at least in part, via a computer program product, i.e., a computer program tangibly embodied in one or more information carriers, e.g., in one or more machine-readable storage media, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers.
Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only storage area or a random access storage area or both. Elements of a computer (including a server) include one or more processors for executing instructions and one or more storage area devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from, or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Information earners suitable for embodying computer program instructions and data include all forms of non-volatile storage area, including by way of example, semiconductor storage area devices, e.g., EPROM, EPROM, and flash storage area devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.
performing a traceroute through the network;
obtaining a plurality of metrics associated with the telephone call, the plurality of metrics being obtained via the traceroute, and the plurality of metrics being based on data packets that are transmitted during the telephone call;
determining whether the plurality of metrics exceeds a corresponding plurality of thresholds;
increasing a frequency of the traceroute when at least one of the plurality of metrics exceeds its corresponding threshold;
after increasing the frequency of the traceroute, re-obtaining the plurality of metrics;
determining whether the re-obtained plurality of metrics exceeds the corresponding plurality of thresholds;
decreasing the frequency of the traceroute when the re-obtained plurality of metrics is determined to be below the corresponding plurality of thresholds;
receiving information from nodes of the network using the trace route, the information based on the metric exceeding the threshold;
using the information and other information relating to routing of other telephone calls through the network to locate a problem on the network, the problem comprising at least one of a bottleneck, a failed node, or a node not functioning properly; and
routing subsequent telephone calls based on the information to avoid the problem.
2. The method of claim 1, wherein the metric comprises at least one of data packet loss and jitter of the data packets.
3. The method of claim 1, wherein the information comprises records associated with telephone calls routed through different paths of the network.
4. The method 1, wherein the metric relates to a degradation in call quality, the degradation represented by the metric not being detectable by a human ear.
5. The method of claim 1, wherein the metric is weighted, the weight corresponding to a system that initiates the telephone call.
6. One or more non-transitory machine-readable media for storing instructions that are executable to monitor quality of a telephone call transmitted over a network, the instructions for causing one of more processing devices to:
perform a traceroute through the network;
obtain a plurality of metrics associated with the telephone call, the plurality of metrics being obtained via the traceroute, and the plurality of metrics being based on data packets that are transmitted during the telephone call;
determine whether the plurality of metrics exceeds a corresponding plurality of thresholds;
increase a frequency of the traceroute when at least one of the plurality of metrics exceeds its corresponding threshold;
decrease the frequency of the traceroute when the re-obtained plurality of metrics is determined to be below the corresponding plurality of thresholds;
receive information from nodes of the network using the trace route, the information based on the metric exceeding the threshold;
use the information and other information relating to routing of other telephone calls through the network to locate a problem on the network, the problem comprising at least one of a bottleneck, a failed node, or a node not functioning properly; and
route subsequent telephone calls based on the information to avoid the problem.
7. The one or more non-transitory machine-readable media of claim 6, wherein the metric comprises at least one of data packet loss and jitter of the data packets.
8. The one or more non-transitory machine-readable media of claim 6, wherein the information comprises records associated with telephone calls routed through different paths of the network.
9. The one or more non-transitory machine-readable media of claim 6, wherein the information is limited to records associated with telephone calls routed through different paths of the network.
10. The one or more machine-readable media 6, wherein the metric relates to a degradation in call quality, the degradation represented by the metric not being detectable by a human ear.
11. The one or more machine-readable media of claim 6, wherein the metric is weighted, the weight corresponding to a system that initiates the telephone call.
US11751355 2006-05-26 2007-05-21 Call quality monitoring Active 2030-06-17 US8457000B2 (en)
US11751355 US8457000B2 (en) 2006-05-26 2007-05-21 Call quality monitoring
US13872681 US8913506B2 (en) 2006-05-26 2013-04-29 Call quality monitoring
US13872681 Continuation US8913506B2 (en) 2006-05-26 2013-04-29 Call quality monitoring
US20080063149A1 true US20080063149A1 (en) 2008-03-13
US8457000B2 true US8457000B2 (en) 2013-06-04
ID=38779318
US11751355 Active 2030-06-17 US8457000B2 (en) 2006-05-26 2007-05-21 Call quality monitoring
US13872681 Active US8913506B2 (en) 2006-05-26 2013-04-29 Call quality monitoring
US (2) US8457000B2 (en)
EP (1) EP2033420A4 (en)
WO (1) WO2007140164A3 (en)
US20030142633A1 (en) 2002-01-25 2003-07-31 Level (3) Communications Automated installation of network service in a telecommunications network
Action and Response History in U.S. Appl. No. 11/751,391.
EP Communication dated Mar. 22, 2010 in EP Application No. 07797624.9.
Extended Search Report in Application No. EP 07797624.9, dated Nov. 24, 2009.
International Search Report and Written Opinion in Application No. PCT/US07/69375, dated Jul. 17, 2008.
International Search Report and Written Opinion in Application No. PCT/US07/69378, dated Jul. 3, 2008.
Int'l Preliminary Report on Patentability (incl. Written Opinion Jul. 3, 2008) in Application No. PCT/US2007/069378, dated Nov. 27, 2008.
Int'l Preliminary Report on Patentability in Application No. PCT/US2007/069375, dated Mar. 3, 2009.
Machine Translation of Korean Patent Application No. 2003-0023898 (Pub. Date: Mar. 26, 2003).
Reply to EP Examination Report in EP Application No. 07797624.9, filed Sep. 1, 2010.
Reply to Final Office Action of Jun. 9, 2011, in U.S. Appl. No. 11/751,391, filed Dec. 8, 2011.
Supplementary Search Report in European Patent Application No. 07797624, dated Nov. 9, 2009.
Varela et al., "Multi-Service Routing-A New QoS Routing Approach Supporting Service Differentiation", Telecommunications 2005, Advanced Insutrial Conference on Telecom / Service Assurance with Partial and Internmitted Resources Conference / E-Learning on Telecom. Workshop. AICT/SAPIR/ELETE 2005, Proc. Jul. 17-20, 2005.
Varela et al., "Multi-Service Routing—A New QoS Routing Approach Supporting Service Differentiation", Telecommunications 2005, Advanced Insutrial Conference on Telecom / Service Assurance with Partial and Internmitted Resources Conference / E-Learning on Telecom. Workshop. AICT/SAPIR/ELETE 2005, Proc. Jul. 17-20, 2005.
EP2033420A2 (en) 2009-03-11 application
US20130308760A1 (en) 2013-11-21 application
WO2007140164A3 (en) 2009-04-16 application
US8913506B2 (en) 2014-12-16 grant
US20080063149A1 (en) 2008-03-13 application
EP2033420A4 (en) 2009-12-23 application
WO2007140164A2 (en) 2007-12-06 application
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:WEST, JULIAN WRAY;DIETZ, DARRYL;REEL/FRAME:019415/0006