Systems and methods for improving media data communications over a network

Systems and methods are disclosed for improving transmission of media data contained in data packets in a media session established over a network. According to certain embodiments, a first server can determine that at least one media quality metric associated with the media session is below one or more pre-determined thresholds, the at least one media quality metric being indicative of a media quality. The first server can also obtain identification information associated with the media session, provide the identification information to a second server, receive, from the second server data, related to a transmission of data packets, and media data contained in the data packets. The first server can determine configurations based on the received data related to a transmission of data packets. At least one of the first and second servers can be configured based on the determined configurations to provide a pre-determined media quality.

FIELD

The present disclosure relates to data communications systems, and more specifically, to systems and methods for improving media data communications over a network.

BACKGROUND

There are many existing network services that require real-time communication of data over a network. For example, packet-based communication service, such as media-over-IP services, typically include the real-time delivery of voice, and possibly other media data types such as video data, on a network using a Real-Time Transport Protocol (RTP) to exchange information required to control the delivery of data. Many different network conditions and data processing configurations (e.g., choice of codec) can adversely affect the communication of data, and the quality of the communications service. Besides, those network conditions and data processing configurations can also affect different data streams (e.g., associated with different transmission protocols, different media sessions, different users, etc.) differently.

SUMMARY

The present disclosure arises from the realization that many different network conditions and data processing configurations can cause, in different degrees for different data streams, degradation of the quality of the communications services. In order to manage the quality of service associated with a media stream, for example, various network metrics indicative of quality of service, such as latency, jitter, packet loss rate, video quality, frame rate, etc., can be determined by intercepting and analyzing data packets being transmitted over a network. However, due to the volume of data packets, it is virtually impossible to intercept and analyze all of the data packets being transmitted over the network. On the other hand, while legacy systems allow participants to a communications session (e.g., a media-over-IP session) to record media data (e.g., voice data) of the session, the media data typically does not contain sufficient information for determining the aforementioned network metrics indicative of quality of service.

With the embodiments of the present disclosure, a first server (e.g., an application server) can determine that at least one media quality metric associated with a media session is below one or more pre-determined thresholds, or receive an indication from a participant of the media session that the media quality of the session falls below one or more pre-determined thresholds. The application server can then obtain identification information associated with the media session. The application server can provide the identification information to a second server (e.g., a media server), and receive from the media server data related to a transmission of data packets after the identification information is provided. The application server can determine configurations for both the application server and the media server based on the received data related to a transmission of data packets, the configurations being related to transmission of data packets by the application server and the media server. At least one of the application server and the media server can then, based on the determined configurations, provide a pre-determined media quality.

With embodiments of the present disclosure, data packets for a particular media session of which one or more media quality metrics falls below a threshold, which may be predetermined or set dynamically, can be identified and analyzed. Based on the data packets, various network metrics associated with that media session can be determined. Accordingly, remedial actions (e.g., configurations for at least one of the application server and media server) specific for improving or maintaining a media quality of the media session can be determined, which can enable more effective and efficient management of data transmission over a network.

The foregoing general description and the following detailed description are explanatory only and are not restrictive of the claims.

DETAILED DESCRIPTION

The embodiments disclosed herein concern improving media data communications over a network. In some embodiments, a first server (e.g., an application server) having one or more processors can determine that at least one media quality metric of a media session over the network is below one or more thresholds. The at least media quality metric is indicative of a media quality, and the one or more thresholds can be pre-determined or set dynamically. The first server, after the determination that at least one metric is below the one or more thresholds, can obtain identification information associated with the media session, and provide control data including the identification information to a second server (e.g., a media server) to receive data related to a transmission of data packets based on the identification information. The first server can then determine configurations for at least one of the first and second servers based on the received data, and configure at least one of the first and second servers based on the determined configurations, to provide a pre-determined media quality, and an improved user experience.

In some embodiments, the at least one media quality metric can include at least one of: mean opinion score (MOS), jitter, packet loss, and latency. In some embodiments, the at least one metric can also be associated with a codec, and the identification information can include information related to the codec.

In some embodiments, based on the received data from the first network element, the first server can determine configurations for at least one of the first server and second server including, for example, selection of a second codec and a second bit rate for transcoding the data packets, data packet queuing policy, etc.

With embodiments of the present disclosure, data packets for a particular media session of which one or more media quality metrics falls below the one or more thresholds can be identified and analyzed. Based on the data packets, various network metrics associated with that media session can be determined. Accordingly, remedial actions (e.g., configurations for network elements that transmit the data packets) specific for improving or maintaining a media quality of the media session can be determined, which can enable more effective and efficient management of data communications over a network.

Reference will now be made in detail to methods and specific implementations that seek to overcome the previously mentioned shortcomings of current systems for processing network requests. Examples of these implementations are illustrated in the accompanying drawings. It should be noted that these examples are described for illustrative purposes and are not intended to limit the scope of this disclosure. Rather, alternatives, modifications, and equivalents of the described implementations are included within the scope of this disclosure as provided by the appended claims. In addition, specific details may be provided in order to promote a thorough understanding of the described implementations. Some implementations within the scope of this disclosure may be practiced without some or all of these details. Further, well known features may not have been described in detail for the sake of clarity.

The example embodiments herein include computer-implemented methods, non-transitory computer-readable mediums, and systems. The computer-implemented methods can be executed, for example, by at least one processor that receives instructions from a non-transitory computer-readable storage medium. Similarly, systems consistent with the present disclosure can include at least one processor and memory, and the memory can be a non-transitory computer-readable storage medium. As used herein, a non-transitory computer-readable storage medium can include, for example, a memory stick or card, a flexible disk, hard disk, solid state drive, optical data storage medium such as a CD-ROM or DVD-ROM, or any other data storage medium a RAM, a PROM, and EPROM, a FLASH-EPROM or any other flash memory, NVRAM, a cache, a register, any other memory chip or cartridge, and networked versions of the same. Singular terms, such as “memory” and “computer-readable storage medium,” can additionally refer to multiple structures, such a plurality of memories or computer-readable storage mediums. As referred to herein, a “memory” can comprise any type of computer-readable storage medium unless otherwise specified.

A computer-readable storage medium can store instructions for execution by at least one processor, including instructions for causing the processor to perform steps or stages consistent with the embodiments described herein. Additionally, one or more computer-readable storage mediums can be utilized in implementing a computer-implemented method. The term “computer-readable storage medium” should be understood to include tangible items and exclude carrier waves and transient signals.

FIG. 1depicts an example of a communications system100in which the management of network resources for multimedia communication as described herein may be implemented. System100can be, for example, a telephony system such as a hosted Private Branch Exchange (PBX) platform that provides voice and video over IP, fax services, etc. In some examples, one or more components of communication system100, such as data centers101,102, and103, can be used to implement computer programs, applications, methods, processes, or other software to perform the described techniques and to realize the structures described herein. Communications system100includes data centers101,102, and103. Each data center is a point of presence (POP) that includes the network computing resources (e.g., servers, routers, switches, network connections, storage devices, etc.) for supporting the services provided by communication system100. Each data center is typically located in a different geographical region.

In the example embodiment depicted inFIG. 1, communication system100includes three user points of data (pods), i.e., pods1,2and3, each of which is a logical grouping of two or more pod units situated in different data centers. Of course the number of pods may be greater or fewer in different configurations. Each pod serves a different subset of users. In this example, each pod unit (e.g., unit2A) can serve the same subset of users as the other pod units within the same pod (e.g., pod units2B and2C). Each pod unit includes servers119A-119D configured to provide communication services for the subset of users. Each pod unit1A-3B can also include an account database121A-G configured to support the respective servers for a corresponding subset of users.

It should be noted that the term “user” is being employed in the interest of brevity and may refer to any of a variety of entities that may be associated with a subscriber account such as, for example, a person, an organization, an organizational role within an organization, a group within an organization, etc. As to be described later, servers119A-119D can be configured to implement techniques described herein for managing media data transmission over a network.

FIG. 2shows various components of communication system100ofFIG. 1. In some examples, one or more components of communication system100, such as data centers101and102, and/or communication endpoints243A-243F can be used to implement computer programs, applications, methods, processes, or other software to perform the described techniques and to realize the structures described herein. Specifically,FIG. 2shows the various interconnections within and between data centers101and102. Both data centers101and102are in communication with example network217. AlthoughFIG. 2shows that network217as a single entity, it is understood that network217can include multiple sub-networks of different types, such as packet-based IP networks and public switched telephone network (PSTN). Service requests from various communication endpoints243A-243F are routed through network217to either or both of the data centers. Communication endpoints243A-243F represent a diversity of client devices that connect with a services system designed in accordance with one or more implementations as described herein. Such client devices include electronic devices, such as, cell phones, smart phones, tablets, laptop and desktop computers, conventional telephones, phones that support media-over-IP (e.g., voice-over-IP), teleconferencing devices, videoconferencing devices, set top boxes, gaming consoles, etc. Reference to specific client device types should therefore not be used to limit the scope of the present disclosure.

Data center101includes pod units1A and2A, a common database (CDB)207A, a message storage system (MSS)211A, a router213A, and a global user directory (GUD)215A. Additional pod units (not shown) may also be included in data center101. Data center102is similarly configured and includes components that operate substantially the same as those in data center101. Data centers101and102provide backup and redundancy to one another in the event of failure,

Servers119A-119D may provide multimedia services to subsets of users. In a case where packet-based communications service (e.g., media-over-IP service) is provided, servers119A-119D can be configured to process and transmit data packets associated with a media session (e.g., an RTP session). For example, some of the servers119A-119D (e.g., servers119B and119C) can be configured as an application server for transmitting and processing signaling data packets for the media session, and some of the servers (e.g., servers119A and119D) can also be configured as a media server transmitting and processing media data packets for the media session.

In some embodiments, application server119B (and/or application server119C) may receive a service request231A (e.g., a HTTP request, a SIP request, a RTP request, etc.) routed from router213A, and in response, transmit and process signaling data packets to establish a connection for the service request. The signaling data can include data used to set up a connection in a telephone network, which can include routing information (e.g., the IP address and port number for transmission of media-over-IP data). Application server119B may also determine a mapping between the routing information and a specific media session. As to be discussed below, in a preferred embodiment, application server119B can obtain a media session identifier associated with a media session, and provide the media session identifier to a media server (e.g., media servers119A and119D) configured to process the media data of the media session. The media server can, based on the media session identifier, extract routing information associated with the media session (e.g., IP address, port number, etc.), and perform capture of media data associated with that media session based on the routing information. The application server may analyze the media data to determine a source of degradation of media quality, and to provide remedial actions to improve or maintain a media quality for the media session.

Application server119B may receive a trigger for capture of media data. As to be discussed below, such a trigger can be generated automatically based on certain network metrics that reflect a media quality associated with a media session. Such a trigger can also be generated based on a users input. For example, a user may file a ticket reporting media quality problem with a media session. After receiving the trigger (either generated automatically or from a user), application server119B may transmit a command to the media server to perform the media capture,

In some embodiments, as discussed before, media servers119A and119D can be configured for transmitting and processing media data packets for the media session. The media data packets may include audio and video data contents being transmitted as part of the media session. Media servers119A and119D may perform processing of the media data packets, such as buffering incoming data packets in a queue before processing the packets, transcoding audio packets using different codecs to reduce size of audio packets in light of network conditions, adding application-specific effects to the audio data (e.g., by adding a dial-tone to mimic a telephone call), encrypting the data, and transmitting the media data packets according to the routing information associated with a media session.

In a preferred embodiment, media server119A (and media server119D) may also capture media data packets based on a command from an application server (e.g., application server119C). For example, based on the IP address and port number information provided by application server119C, media server119A can capture media data packets associated with the IP address and the port number. The capturing may include, for example, duplicating the data contents of the media data packets, and performing various measurements on the data packets (e.g., arrival time and transmission time of each packets, inter-packet delay, percentage of packets dropped, etc.). Media server119A may then provide the captured data back to the application server119C for analysis.

In some cases, the application server, and the media server that receives the command from the application server for media data capture, can be of the same data center (e.g., media server119A and application server119C of data center101). In some cases, an application server may transmit a command to a media server of a different data center for media data capture (e.g., application server119C of data center101transmits the command to media server119D of data center102). For example, the media server may be located in a data center that is at vicinity of network217to reduce transmission distance for the media data packets. While the present disclosure describes an application server and a media server as examples, other components could be used to provide similar functionality as described herein.

Each pod unit also includes an account database (e.g., any one of account databases121A-121G) to support the server(s) for that particular pod unit, storing configuration details and other information regarding each user's account. For example, the account databases121A-121G can store a mapping between users to a communications session and information that identify a media session which, as to be discussed later, can be used by an application server to identify data packets associated with the media session for a determination of network metrics for that media session. The network metrics information can then be used to determine a set of configurations to improve or maintain a media quality for the media session.

Pod units1A and1B are in communication with one another so that the data on their respective account databases are synchronized across data centers, Data center101includes router213A to receive incoming service request231A from network217. Router213A parses the incoming service request to identify or extract a user key which can be used to identify a user. The incoming service can also include other information. For example, in a case where the incoming service request231A includes a SIP request, the SIP request can include a telephone number of the called party, and router213A can parse the service request to extract the telephone number. From the telephone number, router213A can determine, for example, a geographical location associated with the requested service.

Using the extracted information, router213A can query GUD215A to determine which pod is associated with the user key and/or with the geographical location. Depending on the querying result, router213A may route the service request to data center101, or another data center (e.g., data center102as indicated by the arrow241A).

Each pod unit of the data center101is also coupled to MSS211A which stores files for the users served by pod units1A and2A. These files may include, for example, messages (e.g., voicemails and facsimiles), user logs, system messages, system and user call prompts (e.g., auto-attendant or user-recorded greetings), and other types of call-related or electronic messages. The contents of MSS211A are synchronized with other data centers (e.g., synchronized with MSS211B of data center102).

In some embodiments, data centers101and102are configured to provide a predetermined quality of service for a media session. As an example, in a case where a media-over-IP service is provided, data centers101and102can provide a predetermined quality of the media-over-IP service between at least two of communication endpoints243A-243F. The quality of the media-over-IP service can be defined as, for example, a measurable level of telephony service delivered to the communication endpoints, depending on system and/or network configuration. In some examples, the quality can be affected by various metrics, such as digital signal processing capability of media servers119A and119D. Moreover, network217can contribute to certain probability of packet loss, latency (or latency variation), jitter, burstiness of loss, or the like, which can be determined by the standards (e.g., LTE, 3G, etc.) and protocols (e.g., TCP/IP, ATM, etc.) associated with network217. Moreover, the physical distances from data centers101and102to the communication endpoints243A-243F can further exacerbate packet loss and latency, when the data packets are routed through a relatively long distance and through a large number of network elements. Furthermore, the processing capacity of media servers119A and119D, as well as communication endpoints243A-243F, also affect the speed of processing of the data packets transmitted through network217. All of the aforementioned properties can influence the loss rate of data packets and perceived latency in transmission of audio/video data, which in turn affect the perceived quality of the media-over-IP service.

Moreover, typically audio and video information are digitized and compressed with a particular coder into data packets for transmission over the network217. As described above, media servers119A and119D can transcode audio data using different coders. The choice of coder can be driven by a tradeoff between quality and bandwidth requirement. As illustrative examples, G.729 coder operates at a lower bit rate and has low network bandwidth requirement, but offer inferior audio quality than, for example, 0.711 and 0.722 coders, which operate at higher bit rates and offer better audio quality (e.g., higher sampling rate, higher frame rate, etc.), but have higher network bandwidth requirements. Also, the 0.729 coder typically is more computation intensive than G.711 and G.722 codecs, and can introduce additional latency in processing and transmission of data packets at the servers. Based on network metrics (e.g., packet loss, latency, etc.) that indicate a certain availability of network resources, media servers119A and119D can be configured to use a coder associated with a bit rate that can be supported by the available network resources indicated by the network metrics, while the media quality provided by that coder can still satisfy a certain threshold.

Further, data centers101and102can be configured to provide a pre-determined quality of media-over-IP service for a particular user. For example, a user who operates one of communication endpoints243A-243F can subscribe to a specific calling plan under which the user is to be provided with a pre-determined quality of media-over-IP service. Different users may subscribe to different calling plans. As a result, media sessions associated with different users can also be associated with different media quality thresholds. The calling plan and associated media quality information can be part of user account information stored in account databases121A-121D.

As discussed above, there are multiple network elements (e.g., network217, data centers101and102etc.) that can affect the quality of the provided service, and that different media sessions can be associated with different media quality thresholds. Therefore, to improve the quality of a particular media session, an application server and a media server of data centers101and102(e.g., application servers119B and119C, media servers119A and119D) can identify media data packets associated with that media session as these packets are transmitted along a network path comprising the media server. The application server can then transmit a command to a media server to cause the media server to capture information associated with the identified media data packets (e.g., arrival time and transmission time of each packets, inter-packet delay, percentage of packets dropped, the data content, etc.). The application server can perform analysis on the media data packets to determine metrics that reflect a media quality, such as latency, jitter, packet loss rate, etc., and determine configurations for these network elements to provide a pre-determined quality for that media session. The configurations can include, for example, selecting a certain coder for transcoding media data for that media session at the media server to achieve a certain bit rate, implementing a certain queue policy to prioritize transmission and processing of data packets associated with that media session at the media server, etc.

However, given that there can be a large number of media sessions underway over the network217at the same time, and that a huge volume of data traffic can be involved, the applications server can identify the media session to be captured based on, for example, certain network metrics that reflect a media quality associated with a media session falling below a predetermine threshold, and/or based on a user's input.

In some embodiments, the identification of a media session of which the media quality falls below a predetermined threshold can be based on a weighted average of metrics associated with a particular coder. Reference is now made toFIG. 3A, which depicts a data structure300for storing a set of metrics related to the network and the servers, consistent with disclosed embodiments. As shown inFIG. 3A, data structure300includes example tables301and302. Tables301and302associate a set of network and server metrics with a set of weights. Based on the weights, one or more scores representing expected media quality can be determined after the metrics data are collected. Each weight can reflect a degree of influence of that particular metric on the media quality. Each table can also be associated with a particular coder (e.g., table301is associated with G.729 coder, while table302is associated with G.711 coder), and the weight distributions for the metrics can be different for different coders. For example, as discussed before, G.729 codec operates at a lower bit rate and has low network bandwidth requirement, but offer inferior audio quality than, for example, G.711 and G.722 coders, but typically is more computation intensive than G.711 and G.722 coders. As a result, as shown inFIG. 3A, the weight associated with a latency at server for coder G.729 can be larger than that for coder G.711, due to the larger requirement of computation power for G.729. Moreover, the weights associated with the network metrics (e.g., network bandwidth, network latency, packet loss rate, etc.) for coder G.711 can also be larger than those for coder G.729, due to the higher bit rate requirement of G.711.

Further, the set of network and server metrics data can be collected at the media server (e.g., media servers119A and119D) configured to transmit and process data packets. In some embodiments, the media server can determine a coder associated with a stream of data packets by, for example, identifying certain payload content (e.g., meta data) in those data packets.

Media server119A (and119D) can also determine, based on the timestamps associated with the processing of the data packets, metrics that reflect latency and jitter (e.g., variation of inter-packet latency). The timestamp information can be derived locally by media server119A (e.g., by keeping track of the time at which the media server receives a data packet and the time at which the media server transmits the data packet). In additional, Real-time Control Protocol (RTCP), an IETF (Internet Engineering Task Force) defined protocol for providing out-of-band statistics and control information for an RTP session, provides periodic transmission to participants of an RTP session various packets, such as sender report, receiver report, etc. The receiver report can include information such as transmitted RTP packet counts, lost packet counts, jitter, round-trip delay time, etc.

Media server119A can also generate the metrics data based on the information included in the receiver report, or forward the receiver report to the data center. The metrics data collection can be performed over a certain sample size of data packets associated with a particular codec, and can be performed periodically (e.g., once every 10 seconds, based on the period of transmission of RTCP report, etc.).

Based on the weights and the metrics data, one or more scores representing expected media quality can be determined. For example, the scores can represent an MOS (mean opinion score) and can be determined according to the E-model specified by International Telecommunication Union (ITU) in ITU-T Recommendation G.107. Both the scores and the weights can also be updated at the same rate at which the metrics data are sampled. For example, as shown inFIG. 3A, table303records the time of last update of the scores and the weights on Aug. 5, 2015 at 15:00:10, at the end of a 10-second interval

In some embodiments, the metrics and score information can also be determined by an application server (e.g., application servers119B and119C) after receiving samples of timestamp and sequence number information from the network elements. Application server119B (and119C) can then determine whether the score associated with a codec is below one or more thresholds. The thresholds can be pre-determined or set dynamically, and can be configured based on various factors, such as expected media quality for that codec based on, for example, historical measurement of metrics data associated with the codec.

If application server119B determines that the score is below the one or more thresholds, application server119B can instruct the media server to collect metrics data for data packets associated with that codec for further analysis, the details of which will be described below. The data packets to be analyzed can be of a larger sample size than the data packets collected for score determination (e.g., being associated with a larger number of media sessions, collected within a longer duration, sampled at a higher rate, etc.). In some embodiments, historical samples of the metrics, and the associated scores, can also be stored at a database. The historical samples and the associated scores can then be used to determine a moving trend of the scores. For example, if application server119B determines that there is a downward trend of the scores, application server119B can also instruct the media server (e.g., media server119D) to collect metrics data for all data packets associated with that codec for further analysis, even if the latest score is not yet below the one or more thresholds. In both cases, application server119B can transmit identification information that identifies that codec to media server119D, which can then identify data packets associated with that codec (e.g., by examining the meta data), and collect metrics data for the identified data packets. Data representing data structure300, and the metrics data, can be stored at a database (e.g., CDB207A ofFIG. 2).

In some embodiments, the identification of a media session of which the media quality falls below a predetermined threshold can also be based on other indications. For example, a participant to a media session can submit a problem ticket to report a drop in media quality for that media session. The problem ticket, which includes the media session information such as, for example, subscriber identifier, can then be transmitted to application server119B (and119C). Based on the information included in the ticket, such as the subscriber identifier, application server119B can determine to collect metrics data for data packets associated with that media session (or a user associated with the media session), and obtain other information which it can provide to a media server (e.g., media server119D) to start metrics data collection.

Reference is now made toFIG. 3B, which depicts a data structure320that stores information for metrics data collection. As shown inFIG. 3B, data structure320stores a record that includes a media session identifier322, tags324and326, source IP address328, destination IP address330, and ticket identifier334. In some embodiments, media session identifier322can be an identifier configured to identify a media session underway in a network. Media session identifier322can be associated with other identification information which can be specific to the protocol for the media session. For example, tags324and326can be From Tag and To Tag configured to identify Dialogs under SIP, as defined in Request For Comments (RFC) 3261. Tags324and326can be used also to identify a call leg of, for example, a media-over-IP session initiated using the SIP protocol. Media session identifier322can also be associated with source IP address328and destination IP address330, which can be the IP addresses associated with data packets for that media session. Data structure320also include port numbers associated with these addresses (not shown inFIG. 3B). Further, media session identifier322can also be associated with ticket identifier334, which can be used to identify a ticket received by the data center concerning this particular media session. Portions of data structure320can be stored at different databases. For example, an account database (e.g., account DB121A) can store an association among session identifiers322, tags324and326, and ticket identifier334, while another database (e.g., CDB207A) can store an association among tags324and326, source IP address328, and destination IP address330.

Based on the data stored in data structure320, application server119B (and119C) can provide information for metrics data collection to a media server (e.g., media server119D). For example, after receiving a ticket from a participant to a media session, application server119B can determine the session identifier associated with the media session based on the ticket identifier associated with the ticket. Application server119B can then provide the session identifier to a media server (e.g., media server119D), which can then determine tags324and326based on the session identifier by querying, for example, account DB121A. Media server119D can then determine, based on the tags, the source and destination IP addresses (and the port numbers) of the data packets associated with the media session by querying, for example, CDB207A Based on the source and destination IP addresses and the port numbers information, media server119A can then collect metrics data only for data packets associated with the source and destination IP addresses and port numbers provided by the data center. In some embodiments, application server119B can also obtain the source and destination IP addresses (and the port numbers) of the data packets associated with the media session by querying CDB207A, and provide the source and destination IP addresses and the port numbers information to media server119A, which can then collect metrics data based on the information.

In some embodiments, application server119B (and119C) can also transmit a request to a media server (e.g., media server119A) to cause the media server to create a duplicate of the identified data packets, and to provide the duplicates to the application server, which can then derive metrics data from the duplicated data packets.

After instructing the media server to collect metrics data for a certain set of data packets (e.g., associated with a particular codec, or associated with a particular media session), or to duplicate the set of data packets, application server119B (and119C) can perform further analysis. The analysis can include, for example, analyzing inter packet delay, packet loss, or bit rate associated with a codec (e.g., if the codec is rate-adaptive, such as OPUS), for the set of data packets at each of the network elements involved in the transmission and processing of the data packets.

Based on a result of the analysis, application server119B (and119C) can then determine one or more configurations to manage the media quality associated with the set of data packets. For example, in a case where media server119D is determined to be a bottleneck (e.g., as reflected by huge latency introduced by the server), application server119B can determine to cause media server119D to update its data packet queuing policy to, for example, give higher priority to the set of data packets. The application server can also determine to reroute the data packets (e.g., by updating a configuration at routers213A) to a different server. For example, instead of routing the media data packets to media server119D, application server119B may determine to route the media data packets to media server119A for processing.

Moreover, based on a determination that the codec is associated with a low media quality, application server119B (and119C) can also determine to select a different codec and bit rate for transcoding the media data, to either alleviate the computation requirement at the server or the network bandwidth requirement for processing of the media data. The application server can also perform other actions, such as transmitting messages to inform participants to the media session about the change in network capacity and media quality, etc.

As to be described below, data structures300and320can be part of a media quality management system, which can control each of the network elements involved in the transmission of data packets to provide metrics data (and/or duplicate data packets) for detection of changes in media quality, and for further analysis to determine remedial actions to address the changes. Further, the example contents of data structures300and320are provided only for illustration purposes only, and do not limit the scope of the present disclosure.

FIG. 4is a block diagram of an example system400, consistent with disclosed embodiments. System400can be part of a communication device that is used in a communication system and that can function as any of the communication devices depicted inFIG. 2(e.g., communication endpoints243A-243F, servers119A-119D, router213A, etc.), as well as the aforementioned servers119A-119D, with techniques consistent with embodiments of the present disclosure.

System400includes a bus402or other communication mechanism for communicating information. Bus402interconnects subsystems and devices, such as one or more processors404, system memory (“memory”)406, storage device408(e.g., ROM), disk drive410(e.g., magnetic or optical), communication interface412(e.g., a modem, Ethernet card, or any other interface configured to exchange data with a communications network), display414(e.g., CRT or LCD), input device416(e.g., keyboard), and pointer or cursor control418(e.g., mouse or trackball).

According to some examples, computer system400performs specific operations in which processor404executes one or more sequences of one or more instructions stored in system memory406. Such instructions can be read into system memory406from another computer readable medium, such as static storage device408or disk drive410. In some examples, hard-wired circuitry can be used in place of or in combination with software instructions for implementation. In the example shown, system memory406includes modules of executable instructions for implementing an operation system (“O/S”)432, an application436, and a communication manager module438, which can provide the functionalities disclosed herein.

In some examples, execution of the sequences of instructions can be performed by a single computer system400. According to some examples, two or more computer systems400coupled by communication link420(e.g., links to LAN, PSTN, or wireless network) can perform the sequence of instructions in coordination with one another. Computer system400can transmit and receive messages, data, and instructions, including program code (i.e., application code) through communication link420and communication interface412. Received program code can be executed by processor304as it is received, and stored in disk drive410, or other non-volatile storage for later execution.

In some examples, where system400is part of a media quality management system, storage device408can store data structures300and320ofFIGS. 3A-B, and the associated network element configuration settings. Application436can receive a request for network resources for communication session (e.g., an RTP session) via bus402and communication interface412. If a participant to the session has subscribed to a certain quality of service for the session, application436can then determine whether the quality of service for that session is below one or more thresholds, which can be pre-determined or set dynamically, based on the metrics stored in data structure300or based on information received from participants of the media session (e.g., ticket information as stored in data structure320). Application436can also transmit instructions, via communication interface312, to other network elements involved in the transmission of data packets for that media session (e.g., media server119A), to collect data related to a transmission of the data packets (e.g., metrics data, duplicates of the data packets, etc.), and to provide the collected data back to system400for further analysis. Application436can then perform further analysis on the information provided by the network elements, and determine remedial actions (e.g., configurations for the media server) to manage the media quality for that media session.

FIG. 5is a simplified block diagram of an example application server500for managing media data transmission over a network, consistent with disclosed embodiments. As shown inFIG. 5, in a preferred embodiment, application server500can be part of data center506, which further includes media server508. Both application server500and media server508are communicatively connected with communication endpoints501A and501B via, respectively, network502and network510. Endpoints501A and501B can be any of the endpoints ofFIG. 2.

As shown inFIG. 5, application server500can transmit control data to media server508. The control data can include information that enables media server508to collect data related to a transmission of data packets, such as metrics that reflect a media quality, and duplicates of the data packets. The control data can define the scope of metrics data to be collected, such as source and destination IP addresses and port numbers for the data packets of which duplicates or metric data are to be generated, codec information of the data packets, the type of metrics data to be collected (e.g., timestamp, latency, etc.), the sampling time period and duration for the data collection, etc. The control data can also include configuration information for media server508, such as codec selection, routing direction, or the like, determined by application server500based on the data collected by media server508. In some embodiments, application server500can perform similar functionalities as application servers119B and119C ofFIG. 2, while media server508can perform similar functionalities as media servers119A and119D ofFIG. 2. The example application server500shown inFIG. 5can include a data collection triggering engine512, a data analytics engine514, and a decision engine516. The example media server508shown inFIG. 6can also include a data collection engine518. Each engine512,514,516, and518can either be a software program that performs a particular function of related functions, or a packaged functional hardware unit designed for use with other components. Application server500can also interface with database520, which can store the data received by application server500, as well as a result of analysis on those data by the system.

In some embodiments, data collection triggering engine512can determine whether to collect data related to the transmission of data packets between endpoints501A and501B. As discussed before, the collection of data can be triggered based on a determination that one or more scores representing expected media quality associated with a particular codec fall below the one or more thresholds. The scores can be determined based on a weighted average of various metrics (e.g., latency, packet loss rate, etc.) as defined according to data structure300ofFIG. 3A, with the metrics collected periodically (e.g., once every 10 seconds) by media center508. The collection of data can also be triggered based on a determination that those scores, associated with a particular codec, exhibit a certain downward trend. Upon determining that the data packets being transmitted between endpoints501A and501B are associated with that particular codec, data collection triggering engine512can determine to collect data related to the transmission of those data packets. In some embodiments, the collection of data can also be triggered based on control data (e.g., a ticket reporting drop in media quality) received from at least one of endpoints501A and501B. Based on the control data from endpoints501A and501B, data collection triggering engine512can determine identification information (e.g., source and destination IP address, port number, etc.) of data packets of which metrics data are to be collected, according to data structure320ofFIG. 3B. The metrics data, as well as data organized in the form of data structures300and320, can be stored in database520, which can then be retrieved by data collection triggering engine512to determine whether data collection is to be triggered.

After determining that data collection is to be triggered, data collection triggering engine512can then transmit control data that define the scope of metrics data to be collected, such as source and destination IP addresses and port numbers for the data packets of which duplicates or metric data are to be generated, coder information of the data packets, the type of metrics data to be collected (e.g., timestamp, latency, etc.), the sampling time period and duration for the data collection, etc., to media server508. Data collection engine518of media server508can then perform the data collection based on the control data.

Data collection engine518of media server508can interface with various components within media server508to perform the data collection. For example, to measure latency, data collection engine518may monitor media data packets that are stored in a queue for transmission. For the queued media data packets that are associated with the destination IP addresses and port numbers listed in the control data, data collection engine518may determine the time these packets spent in the queue before being transmitted, for the latency determination. Data collection engine518may also intercept the data packets at the queue may also determine a percentage of packets dropped from the queues at media server508. Data collection engine518may also monitor missing RTP sequence numbers to determine packet loss at, for example, network510.

In some embodiments, data analytics engine514can perform analysis on the data collected by media server508. The analysis can include, for example, analyzing inter packet delay, packet loss, or bit rate associated with a codec (e.g., if the codec is rate-adaptive, such as OPUS), for the set of data packets at media server508. Data analytics engine514can then provide a result of the analysis to decision engine516.

In some embodiments, decision engine516can, based on a result of the analysis from data analytics engine514, determine one or more configurations to manage the media quality associated with the set of data packets. For example, if decision engine516determines that media server508is a bottleneck, it can determine to route the data packets to some other media servers of other data centers (not shown inFIG. 5), cause media server508to update its queuing policy, to use different codecs to reduce bit rate and bandwidth requirement, etc. Decision engine516can also perform other actions, such as transmitting a message to endpoints501A and501B indicating about the change in network capacity, transmitting a message to other devices to collect data related to the transmission of the set of data packets, etc. While the remedial actions are being performed, application server500may continue to instruct media server508to perform the data collection until, for example, when the media session terminates.

FIG. 6is a chart illustrating an example method600for managing media data transmission over a network, consistent with disclosed embodiments, with reference toFIG. 5. In this example, an electronic device (e.g., application server500ofFIG. 5) executes a method600to interact with one or more other devices (e.g., data center506ofFIG. 5) for managing media data transmission over a network that comprises these devices. While the chart discloses the following steps in a particular order, it will be appreciated that at least some of the steps can be moved, modified, or deleted where appropriate, consistent with the teachings of the present disclosure. While the following steps are indicated as being performed by an electronic device, it is appreciated that the steps can be performed by more than one electronic device.

Method600begins with step S601in which data collection triggering engine512ofFIG. 5can determine that at least one media quality metric associated with a media session is below a predetermined threshold. As discussed before, the determination can be based on, for example, that one or more scores representing expected media quality associated with a particular codec falls below one or more thresholds which may be pre-determined or set dynamically, and/or that the scores exhibit a certain downward trend. The scores can be determined based on a weighted average of various metrics (e.g., latency, packet loss rate, etc.) as defined according to data structure300ofFIG. 3A, with the metrics collected periodically (e.g., once every 10 seconds) by, for example, data center506. Further, the determination can also be based on control data from endpoints501A and501B, such as tickets reporting an issue with media quality received from participants to the media session.

In step S602, data collection triggering engine512ofFIG. 5can obtain identification information associated with the media session. In some cases, the identification information can include, for example, codec information, if data collection triggering engine512determines to further analyze data packets associated with a particular codec, based on information stored in data structure300ofFIG. 3AIn some cases, the identification information can include, for example, source and destination IP addresses and port numbers, based on information stored in data structure320ofFIG. 3B.

In step S604, data collection triggering engine512can transmit control data including identification information to media server508. The control data can also include information that define the scope of metrics data to be collected, such as type of metrics data to be collected (e.g., timestamp, latency, etc.), the sampling time period and duration for the data collection, etc.

In step S606, data collection engine518of media server508can collect data related to a transmission of data packets based on the identification information. The collected data can include, for example, metrics that reflect a media quality, duplicates of the data packets, etc. In step S608, data center506can then transmit the collected data back to media quality management system500. Data collection engine518may collect the data by monitoring media data packets stored in a queue for transmission, ACK packets, etc.

In step S610, data analytics engine514ofFIG. 5can perform analysis on the data collected by data center606, and determine one or more configurations based on the analysis. The analysis can include, for example, analyzing inter packet delay, packet loss, or bit rate associated with a coder (e.g., if the codec is rate-adaptive, such as OPUS), at data center506. Based on a result of the analysis by data analytics engine514, decision engine516ofFIG. 5can determine one or more configurations to manage the media quality associated with the set of data packets. For example, if decision engine516determines that data center506is a bottleneck due to a choice of computation-intensive coder, it can configure data center606to use a different rodeo that is less computation-intensive. Decision engine516can then transmit the coder configuration information to media server508, in step S612. Media server508can then configure the processing of data packets based on the configuration information, in step S614. For example, if the coder configuration information indicates to use the G.722 coder, data center506can then use G.722 coder to transcode certain set of data packets (e.g., data packets associated with another codec, data packets associated with a certain media session, etc.).

It will also be understood by those skilled in the art that changes in the form and details of the implementations described herein may be made without departing from the scope of this disclosure. In addition, although various advantages, aspects, and objects have been described with reference to various implementations, the scope of this disclosure should not be limited by reference to such advantages, aspects, and objects. Rather, the scope of this disclosure should be determined with reference to the appended claims.