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
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
- Multiple A/V metrics reports may exist in a single POST body,
up to the maximum configured value for the WMI setting
- The A/V metrics reports will be sent in XML, UTF-8 encoded.
- The XML payload will have a root element 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
- 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
- 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
- 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.