Cisco Cisco MediaSense Release 9.0(1) Developer's Guide

Page of 136
Failure JSON
Response Schema:
{
    “responseCode”: <
 is an integer>,
this
    “responseMessage”: “Failure: <
 is a string>”,
this
    
"detail"
"<
 is a string>"
this
}
Related Error
Codes:
Go to the 
Events Triggered:
None. 
 
Availability:
Available since API Version 1.0. 
Modified in API Version 1.2 (See Notes below.) 
Modified in API Version 1.4 (See Notes below.) 
Release:
8.5(1)
Notes:
The following changes were introduced in Release 9.0(1), Version 1.4:
Introduced a new parameter in the Track (refer to Parameter Description table for more info):
codec
The following changes were introduced in Release 8.5(3), Version 1.2:
To enforce scalability, this API requires a sessionStartDate field condition.
This API no longer supports sessionId as a searchable fieldName.
Parameters introduced:
callControllerIP
callControllerType
ccid
A track can now have tags. The following SYSTEM_DEFINED tagName enumeration values are
available at the track level:
TrackActive
TrackInactive
Avoiding Non-Scalable Queries
Overview
The 
custom queries that can filter on any of several important data fields in the session metadata. It also provides a flexible way to combine those
queries to perform powerful metadata searches.
Warning
If this custom query mechanism is misused, it can have serious performance impacts on not only the query itself, but the
entire Cisco MediaSense system. This is because it is possible to store large numbers of session records depending on the
traffic on the system and the retention mechanism in use. This is normal. However, if a query processes a large amount of
data, it could take up to several minutes to complete. It could also take resources away from the system that should be used
to process new recordings and metadata.
To avoid this problem, it is important that clients form scalable queries. A scalable query is a query whose performance remains constant
regardless of how much data is in the database. An example of a scalable query might be: "Find all sessions whose start date/time is between
4 and 5 o'clock today." No matter how many sessions are in the database, the number of sessions between 4 and 5 o'clock today will remain
fairly stable and small. An example of a non-scalable query would be: "Find all sessions." The number of sessions returned would be
proportional to the number of sessions in the database. If there were a large number of stored sessions, then the results would be huge. It
would take a lot of time to complete and would impact resources needed by other functions of the Cisco MediaSense system.
While there is no direct way to issue a "Find all sessions" query with the 
 
99