There are a few protocol considerations that you should be aware of before you develop your custom solution. In order to support persistent connections, the metric report consumer must be a server that is compliant with HTTP 1.1.

To improve the security of your data and the privacy of your users, we recommend that HTTPS with mutual certificate authorization be configured.

This sample call flow illustrates how the metric report consumer accepts an A/V metric report for a single session. You will be responsible for the protocol implementation between the Monitoring Agent and the metrics report consumer.

Figure 1. Metric Report Consumer Acceptance of an A/V Metric Report

Protocol Requirements

The following protocol requirements should be taken into consideration when you develop your custom solution:

  • The metric report consumer must be able to handle multiple incoming HTTP connections and to simultaneously process requests that come in on these different connections. This will enable a single metric report consumer to communicate with multiple Monitoring Agents.

  • Multiple A/V metrics reports may exist in a single POST body, up to the maximum configured value for the WMI setting MaxPostBatchSize.

  • The A/V metrics reports will be sent in XML, UTF-8 encoded.

  • The XML payload will have a root element of VQReportEventList. The IDattribute of VQReportEventListwill be set to a unique value for the set of A/V metrics reports that it contains. If a transient network error or server error occurs or if the Monitoring Agent does not receive an HTTP response from your application, then the agent will repost the entire VQReportEventListdocument with the original ID. You can disable reposting when a transient network error or server error occurs by setting ErrorRetryEnabledto falsein WMI.

  • The QoE Agent performs only a basic level of validation against the A/V metrics report before it posts the report to the metric report consumer. None of the QoE Monitoring Server report aggregation logic is applied to the reports prior to the post.

  • The QoE Agent will not throttle requests; the metric report consumer is expected to keep up with the normal volume of A/V metric reports.

  • In order to handle A/V metric report bursts, such as might occur at the end of a large conference, the QoE Monitoring Server buffers A/V metrics reports, as needed, on behalf of the consumer. The buffer size itself is a configurable number of kilobytes. After the report bursts exceed the buffer size, the QoE Monitoring Server will drop the oldest reports. If the QoE Monitoring Server service or the computer is restarted, the contents of the buffer will not be retained.

  • Upon receiving metrics reports, the report consumer should return the HTTP response immediately. Performing any additional synchronous processing on the reports before returning will cause a drop in the report throughput rate to the report consumer.

HTTP Status Codes

Table 1 defines the status codes that are used in the HTTP protocol between the QoE Monitoring Server and the metric report consumer.

Only HTTP 2xx and 400 status codes are expected from the metric report consumer. All other status codes will be treated as a transient network error or server error and will cause the QoE Monitoring Server to retry the POST request.

Table 1. Supported HTTP status codes

HTTP Status Code Metric Consumer Usage QoE Monitoring Server Action


Metric consumer is expected to promptly return 202 Accepted to valid metric CDR post requests.

The post transaction will be marked as complete.

400 Bad Request

Metric consumer should return 400 Bad Request whenever basic validation of the A/V metric report post request fails.

The post transaction will be abandoned and not retried.

All other status codes

No other status codes are expected from the metric consumer.

The QoE Monitoring Server will treat all other status codes as transient errors and will retry the post request.