The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes two issues you might encounter with Cisco MediaSense and provides troubleshooting information about them. MediaSense is a call recording platform that listens for and records all communications directed at it. If that information, which can be voice or data, is not received or received properly, it might not appear in MediaSense as desired or expected. However, it is often a configuration or network-related issue.
The first type of call is where the audio is not present but the data is received. In these situations, the problem is typically with a configuration or network-related issue with Access Control Lists (ACLs), Cisco Unified Communcations Manager (CUCM), or Cisco Unified Border Element (CUBE).
The best way to verify this type of issue is to make sure that the call control logs are enabled, pull the logs via the Cisco Real-Time Monitoring Tool (RTMT), and have the session ID of the missing audio call log to search.
After you collect the call control logs, open them, search for the session ID, and verify that the size under diskusage is not 0. If the logs show size="0", MediaSense probably did not receive the audio and that is why it is not there.
In this example, the session ID is 78e146437088a93.
When you search, examine the lines that mention diskusage for the particular session ID. In this area, you notice that there is a size in the recording attributes. This example shows that size="0", which means MediaSense did not receive the audio from CUCM or CUBE.
The second type of call is where data is either not present or altered. In these scenarios, the problem is due to configurations on the CUBE or CUCM.
The best way to verify this type of issue is to make sure that the call control logs are enabled and access those via the RTMT. Ensure that youd to have the session ID of the missing audio call log to search.
Search for a block of text under CCBU_CALL_CONTROL-6-BORDER_MESSAGE that contains all of the call information that MediaSense receives, which includes but is not limited to:
The call's originating location
The directory numbers (DNs) of the call
The codec and much more information
If something here does not match what it should be, you might need to analyze the call flow at either CUCM or CUBE in order to determine where the information is altered.
These two examples show these two different issues with missing or incorrect call information.
Example 1 - Phone Number Clipped
In this example, the expected value for session ID 5148fb9543011 shows 19725551234, but MediaSense only shows 197255512 on Search & Play.
In this situation, notice that MediaSense received the number 19725551234 with the last two digits are stripped off. Since this information comes from CUCM, that is the next place to look in order to determine if CUCM also receives a clipped number from further up the call flow or if this happens on CUCM itself.
Further troubleshooting determined that, in this scenario, CUCM caused the issue, which is described in Cisco bug ID CSCuq20108:
If the From header sent to a recording server exceeds 231 characters, the header will get truncated if escaped characters are found. if the From header contains escaped characters "@", (i.e. %40), the dynamic buffer allocation doesn't account for this resulting in characters getting truncated.
Example 2 - No Phone Number
In this example, the DN is completely absent from a device called SIP_TRUNK_CVP.
In this scenario, the logs show that there is no DN information sent to MediaSense, which is very similar to the previous example. In order to further troubleshoot, you should verify that CUCM receives the information correctly, and then check CUBE.