QmCallQualityReport 500 Internal Server Error on BYOC Trunk Aggregation

General Discussion
1

Having some issues getting my configuration to work… specifically regarding the aggregation of quality metrics for our APAC BYOC trunks. We are attempting to generate a comprehensive call quality report using the Quality Management API endpoint /api/v2/analytics/quality/details. The request fails with a 500 Internal Server Error when the date range exceeds 30 days and includes trunk IDs from our Singapore region. The error response body is empty, providing no insight into the specific validation failure or timeout trigger. This behavior is inconsistent with our US-based trunks, which return data successfully for the same duration. The platform appears to be struggling with the sheer volume of SIP session records associated with these specific carrier configurations.

  • Verified that all trunk credentials are active and the SIP registration status is green across all 15 BYOC endpoints.
  • Tested the query with a reduced date range of 7 days, which returns data successfully, suggesting a pagination or backend processing limit issue.

Has anyone encountered similar backend processing errors when querying high-volume BYOC trunk data in the APAC region? Are there known limitations on the quality/details endpoint for specific geographic clusters?

2

Try breaking the request into smaller chunks. The Quality Management API struggles with large date ranges combined with specific BYOC filters, especially under load.

  • Split the 30-day range into 7-day increments.
  • Use from-date and to-date parameters for each chunk.
  • Add a short delay between requests to avoid hitting throughput limits.

Here is a sample JMeter HTTP Request configuration:

<hashTree>
 <HTTPSamplerProxy guiclass="HttpTestSampleGui" testclass="HTTPSamplerProxy" testname="Quality Metrics Chunk">
 <stringProp name="HTTPSampler.path">/api/v2/analytics/quality/details</stringProp>
 <stringProp name="HTTPSampler.query">from-date=${__time(YEAR}-${__time(MONTH)}-${__time(DAY,-7)}&to-date=${__time(YEAR}-${__time(MONTH)}-${__time(DAY,0)}&filter=trunk_id IN (${trunkList})</stringProp>
 <stringProp name="HTTPSampler.method">GET</stringProp>
 </HTTPSamplerProxy>
</hashTree>

Running this in a loop with a constant throughput timer set to 1 req/sec usually bypasses the 500 error. The backend aggregation service seems to timeout when processing too many BYOC records at once.

3

The root cause here is the backend struggling with large date ranges. Splitting into 7-day chunks works perfectly. I use this exact method for weekly adherence reports. It keeps the API happy and prevents timeouts. Just loop through the dates in your script. Simple and effective.