CUCM MediaSense Call Recording Error Troubleshooting

Introduction

This document describes how to troubleshoot MediaSense when an error appears in the call recording for a built-in bridge.

Basic MediaSense Call Flow with Built-In Bridge

This image illustrates the basic MediaSense call flow when a built-in bridge is used: 

Note: IP Phone A has recording enabled.

These steps describe the call flow:

1. The IP phone on the right calls the IP phone on the left and initiates the call via the Cisco Unified Communications Manager (CUCM).
   
   
2. The CUCM sends a signal to the destination phone and completes the call setup.
   
   
3. The connection between IP Phone A and IP Phone B is now set up.
   
   
4. The recording profile on IP Phone A says that as soon as it receives a call, the CUCM must set up a session with MediaSense. This is completed milliseconds after Step 3 begins.
   
   
5. The call is now set up between the two phones, the call forks via the built-in bridge, and the built-in bridge sends two Real-time Transport Protocol (RTP) streams to the MediaSense server.

No Recording on MediaSense

If you receive an error that indicates that there is no recording on MediaSense, then you must view the logs and search for this session ID:

0000049583: 10.201.227.136: May 28 2014 11:27:09.022 -0400: %CCBU_COMMON-6-VSMS
 HTTP Info: {Thrd=Pool-capture-thread-2800} %[HTTP Response Body=<Session>
   <diskusage>
      <recording name="78e146437088a93-TRACK0" size="0" repository="/
       recordedMedia" />
      <recording name="78e146437088a93-TRACK1" size="0"repository="/
       recordedMedia" />
   </diskusage>
</Session>][HTTP Response Content Type=application/xml][HTTP Response Status
 Code=200][logId=close-25668]: VSMS Received HTTP Response

The size="0" in this output indicates that there is no audio recorded on the server for that call. This typically means that the RTP stream did not get to the MediaSense server from the phone. When this occurs, the next step is to verify that the phone sends the RTP traffic.

Verify IP Phone Sends Traffic

A quick way to verify that the IP phone sends the RTP traffic is to view the IP phone web page. This is enabled on CUCM manually within the phone configuration page or via Bulk Admin.

Stream 1 is the main call with the remote address of the other IP phone or gateway. This consists of two streams: the first is the audio that is received on the IP phone and the second is the audio that is sent to the other end.

In order to verify that MediaSense records both of the call legs, click on Stream 2 and Stream 3 in order to verify that the Sender Packets increment when the page is refreshed multiple times. The remote address should show the MediaSense server for both Stream 2 and Stream 3. The reason that there are two streams to the MediaSense server is because one of them is the audio received on Stream 1 (Receiver Packets) and the other is the audio sent (Sender Packets) to the other end on Stream 1.

Note: In reference to the call flow diagram that is previously described, Step 3 is Stream 1, and each leg of Step 5 refers to Stream 2 and Stream 3.

This capture shows Stream 1:

This capture shows Stream 2:

Note: It is important to notice the IP address and the port in the Remote Address section of the page. This is very important when you take packet captures for test phone calls.

This capture shows Stream 3:

When you verify the data for Stream 2 and Stream 3, the key things to look for are:

• The remote address is the IP address of the MediaSense server.
  
  
• The port number on each stream is unique.
  
  
• When you refresh the page, the number of Sender Packets increases.

This indicates that the RTP packets are sent by the IP phone.

Perform Packet Captures

If you are still unsure whether the IP phone sends the RTP packets, the next course of action is to perform a packet capture and replay the streams.

Before you perform the packet captures, ensure that these settings on the IP phone configuration for CUCM are enabled:

• Span to PC Port
• PC Voice VLAN access
• PC Port

Then, apply the configuration and reset the IP phone. After this is complete, open Wireshark and take a packet capture with a 30-second duration. Ensure that you record the remote address as well as the port for Stream 2 and Stream 3 of the IP phone in question. For example:

• Stream 2 - 10.201.227.147/40676
• Stream 3 - 10.201.227.147/33358

Once the packet captures are complete, open the packet capture and complete these steps for each stream:

1. Filter by ip.addr == 10.201.227.147 && udp.port == 40676.
   
   
2. Navigate to Analyze > Decode As.
   
   
3. In the popup window, select RTP an click OK.
   
   
4. Navigate to Telephony > RTP > Stream Analysis.
   
   
5. In the RTP Stream Analysis, navigate to Player > Decode > Play, and verify that both legs of the call are heard.
   
   
6. Repeat Steps 1 through 4 for the other stream and port.

Troubleshoot

After you perform the packet capture and verify that MediaSense is configured properly and that the IP phone sends a valid RTP stream to the MediaSense server, and you continue to encounter issues, then the path between the server and IP phone should be checked.

Ensure that the path does not have any Access Control Lists (ACLs) and that it does not block or filter the RTP traffic.

Important Notes

If the call that is set up with CUCM is in question, then look into the detailed CUCM logs, and open the MediaSense logs in order to find the Call ID. This can be found from the session ID, and looks similar to this in the call control logs:

CallId: 74acba00-38c1ea2d-3a2937-f183000a@10.0.131.241
CallId: 74acba00-38c1ea2d-3a2938-f183000a@10.0.131.241

Since the IP phone sets up two streams with MediaSense, one for each leg of the original phone call, search the CUCM logs with one of the Call IDs in order to verify whether the MediaSense session is set up properly.