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.
  
  

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

Note:
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