Searching Call Recordings, part 2

Originally published on the Clarify.io blog. View archived copy.

Recently we discussed how to index and search your Twilio call recordings immediately after the call was completed. While this is useful for building your search index, it doesn’t cover the search/discovery side of things. To tackle this, we can take one of three approaches:

First, we could use separate accounts/API keys for each user. Whenever our script receives a call recording or search request, we could look up the proper API key to use and add the file with that key. While this would ensure that no user could see any other user’s information, it is inefficient and potentially error-prone. What happens if you use the wrong API key? The call would simply disappear for one user and magically appear for another. Not a good option.

Next, we could use a single account and perform some sort of access control/filtering after the search. This gets around the key management problem above but now we have to deal with keeping Access Control Lists or lists of files a user can access. Unfortunately, it means the pagination information from the API won’t match our desired pagination. After we get a page of results and apply our permissions filter, we may only get a few records, so we have to request the next page, which may still not provide enough records.. etcetera. Imagine the complexity if we have to display another page of results. In short, it’s mess and error prone.

Alternatively, we could use our built-in metadata filters.

In the original sample code, we used this snippet of code:

to generate and add this metadata to the bundle:

Now that we have a little more information, we can make use of it with our metadata filters:

filter is used to limit the search results according to specific criteria based on metadata and bundle values. It uses an expression syntax similar to Javascript boolean expressions. An expression is made up of zero or more terms joined by logical operators with each term having a field, a comparison operator, and a literal value. Parentheses can be used to logically group terms.

For example, in our case, we could limit our search to certain callers by adding this to our query:

filter=from==7035551212

which looks like this using the PHP helper library:

This changes the search from “show me every recording containing my term” to “show me every recording containing my term AND where from is ‘7035551212’.”

Notice that this metadata search is completely independent of the actual search terms. This gives us the ability to take the user input – search terms – then add our additional fields transparently on the backend. While this may still require us to do a lookup of a user filter, it’s only on searches and scales easily. In addition, we could easily apply additional filters or even OR this condition with others as we need.

While there are dozens of more things you can do with this metadata field, user-based filtering is already proving to be incredibly popular and useful. If you have other tips, suggestions, or questions, don’t hesitate to contact me at keith@clarify.io or via Twitter at CaseySoftware.