Revision as of 19:02, October 2, 2015 by Alison.obrien (talk | contribs) (Update with the copy of version: DRAFT)
Jump to: navigation, search

Troubleshooting

What Happens if MCP fails to send recordings to Recording Processor?

If you have scheduled maintenance for an extended period of time which could cause lost recordings, Genesys recommends that you reconfigure Media Control Platform (MCP) to stop posting recording, so that you do not have to handle the failed recordings.

Important
Genesys recommends that your deployment be sized to accommodate 48 hours worth of recording on disk, and that there is plenty of physical memory available on the MCP machine, so that the recording can reload efficiently when MCP restarts.

To reconfigure MCP:

  1. Stop MCP.
  2. Set the recordnumparallelpost parameter in the [mcp] section to 0.
  3. Restart MCP.
    This disables the MCP posting functionality and all recording/meta data files will continue to accumulate in the cache/record directory.
  4. When suitable, stop MCP, set the recordnumparallelpost parameter back to the recommended/default value and restart MCP.
    MCP will now scan the cache/record directory and post the requests for the recording files that are present.

Handling Failed Recordings

For handling MCP post failures in the cache directory:

  1. Find the MCP's $InstallationRoot$/cache/record/failed directory for the following file types:
    • [audiofilename]-htccmetadata.json
    • [audiofilename]
    • [audiofilename].pem (provided only when encryption is enabled)
    The audio file name can have extensions of .mp3 or .mp3.bin. For example:
    • 743CTLVFHH0TH7HHB4D1PTS5US00000F_2014-10-04_11-47-25-00780142-10004349-00000001.mp3-htccmetadata.json
    • 743CTLVFHH0TH7HHB4D1PTS5US00000F_2014-10-04_11-47-25-00780142-10004349-00000001.mp3
  2. Submit these files to:
    1. Recording Processor
    2. Recording storage (WebDAV)
  3. Recording post failures can be due to incorrect provisioning in the IVR Profile, so before posting the metadata file to Recording Processor, look at the metadata file to make sure provisioning is correct. [+] See example

    Check for following items in the json file:

    • mediaFiles[0].mediaDescriptor.path—Make sure this is the correct WebDAV address
    • mediaFiles[0].parameters['rp.speechminer_uri']—Make sure this is the correct location of SpeechMiner Interaction Receiver
    • mediaFiles[0].parameters['rp.speechminer_auth']—Make sure this is the correct authorization of SpeechMiner Interaction Receiver
  4. When encryption is enabled, edit the json file and manually add the pkcs7 headers which is the content of the .pem file (make sure that you replace the line break with \n). [+] See example
  5. When you are ready to submit the files, do the following steps in order:
    1. Issue an HTTP PUT to WebDAV: 
      curl -u [webdavauth] -T [audiofilename] [mediaFiles[0].mediaDescriptor.path]

      Using this example above and assuming the webdav authorization is webdav:password, you will see the following returned: 

      curl -u webdav:passowrd -T 743CTLVFHH0TH7HHB4D1PTS5US00000G_2014-10-07_15-46-21-00780143-100043F9-00000001.mp3 
http://ca-to-irp02/recordings/743CTLVFHH0TH7HHB4D1PTS5US00000G_2014-10-07_15-46-21-00780143-100043F9-00000001.mp3
    2. Issue an HTTP POST to Recording Processor: 
      curl -u [rpauth] -X POST -d @[metadatafile] --header "Content-Type: application/json" [rpuri]

      where:

      • [rpauth] is the Recording Processor authorization as per the IVR Profile
      • [metadatafile] is the metadata json file in MCP's cache/failed directory
      • [rpuri] is the Recording Processor URI as per the IVR Profile

      Using the example above, you should see the following returned: 

      curl -u user:password -X POST -d @743CTLVFHH0TH7HHB4D1PTS5US00000F_2014-10-04_11-47-25-00780142-10004349-00000001.mp3
-htccmetadata.json --header "Content-Type: application/json" http://ca-to-macon2:8889/api/contact-centers//recordings/

What Happens if Recording Processor fails to send recordings to SpeechMiner or Web Services?

If Recording Processor fails to send recordings to SpeechMiner or Web Services for any reason, Recording Processor will continue trying to send these recordings until it exhausts the number of retries configured. When the number of retries have been exhausted, Recording Processor logs an INFO message to the log file with the corresponding JSON content that is not submitted to SpeechMiner or Web Services. The following steps show how to search for the specific messages in the log file to recover the post failure to SpeechMiner and Web Services.

Prerequisites:

  • Make sure that the Recording Processor logging is set to the INFO level.


Important
Metadata for the same call could be sent multiple times to Web Services or SpeechMiner if the call is transferred. Therefore, even if a given metadata record is not sent upstream, the call may still exist in the Web Services or SpeechMiner database.

Handling Failed Recordings to Interaction Receiver (SpeechMiner)

  1. Search the Recording Processor log files for the follow message: "Metadata will not be sent to SM". For example: 
    grep "Metadata will not be sent to SM" recordingProcessor_071614_112548.log
    [+] Show code snippet returned
  2. Save the json string after "Metadata will not be sent to SM:" as a text file.
  3. Issue an HTTP POST to Interaction Receiver for the saved json text file. For example:
    4. curl -u <user:password> -X POST -d @json.txt --header "Content-Type: application/json" <http://speechminer/interactionreceiver>

    Where:

  • <user:password> is the user/password authorization for Interaction Receiver
  • <http://speechminer/interactionreceiver> is the URI of Interaction Receiver

Handling Failed Recordings to Web Services

  1. Search the Recording Processor files for the following message: "Metadata will not be sent to HTCC". For example, 
    grep "Metadata will not be sent to HTCC" recordingProcessor_071714_054043.log
    [+] Show code snippet returned
  2. Save the json string after "Metadata will not be sent to HTCC:" as a text file.
  3. Issue an HTTP POST to Web Services for the saved json text file. For example, 
    curl -u <user:password> -X POST -d @json.txt --header "Content-Type: application/json" <http://htcc/internal-api/contact-center/
{ccid}/recordings>

    Where:

    • <user:password> is the user/password authorization for Web Services
    • <http://htcc/internal-api/contact-center/{ccid}/recordings> is the URI of Web Services
    • {ccid} is the contact center identifier on Web Services

    You can find the contact center identifier from the initial Web Services setup, or you can look up the contact center id from the recording processor log file. In the first few lines of the log file you will find a GUID string as follows: 

    2014-07-17 05:40:43,746 contact_centers INFO Contact center (:79566087-0535-4f30-bb07-2c95a22aaa89) discovered.

    The following example can be used to return the contact center ID: 

    curl -u user:password -X POST -d @json.txt --header "Content-Type: application/json" http://htcc/internal-api/contact-center/79566087-0535-4f30-bb07-2c95a22aaa89/recordings


How do I collect logs to debug issues relating to login to the SpeechMiner UI?

If you are having a problem logging into the SpeechMiner UI, you will need to collect the Network and Console log from the Chrome Developer Tools before and after the login attempts with the Preserve log checkbox enabled—for example:
Devtool.png

Make sure that you have captured the requests for the following applications after you click the login button:

  • Web Services
  • Recording Crypto Server
  • SpeechMiner
Important
Uncheck these options after you have collected the necessary information.

Why do only some of my calls have screen recordings associated with them?

Percentage based screen recording can be configured globally for all agents using (for example, 10%):

In Genesys Admistrator Extension, go to Applications > Main_Configuration > <Cloud Cluster Application > Properties, and set the [screen-recording-client] recordingWhen parameter to random_voice(10). This means that only 10% of agents that have their voice calls recorded will have their screen recorded.


To confirm that this setting is working properly, you could either check the UI, or if you have access to S3 (for Cloud deployments), check the customer folder for the previous day. Find out how many mp3 files there are (that’s the total number of recordings), and then find out how many mp4 files there are (that’s the number of screens). Take the number of mp4 files and divide by the number of mp3 files to determine the percentage of calls that include screen recordings.

Important
If the mp4 and mp3 files are encrypted, the files will end with a .bin suffix.
Comments or questions about this documentation? Contact us for support!