11-07-2014 05:15 AM - edited 03-14-2019 02:05 PM
We're running UCCX 10.5. In a script, we're trying to use the recording step to record a prompt. When you call in and run the script, it all appears to work. But once you look at the recorded prompt, it shows up as being 0.0.6KB. And when you play it back, there's nothing. We've done a Wireshark, and can see the RTP stream going to UCCX fine.
How can we troubleshoot this? Google hasn't been much help so far.
Thanks,
GTG
Solved! Go to Solution.
11-10-2014 01:52 AM
Actually, the "a" might be a problem (if by G.711a you mean G.711 A-Law).
The SRND says
Recording and playback is not supported for a-law.
here (on p. 80 in the PDF version).
Is A-Law somehow forced? Most endpoints including phones and voice gateways happily support μ-Law if requested.
Could you set up a temporary Device Pool with μ-Law support and try again?
G.
11-07-2014 06:20 AM
Hi,
can you please explain what kind of storage you use in your script? Is it the prompt repository? The file system? A database?
Would it be possible to attach the "recording"?
G.
11-07-2014 11:29 AM
11-09-2014 11:01 AM
Hi,
hmm, this looks like an empty wav file. The header looks alright but there's no data.
Could you take a screenshot of the script (the relevant part). Plus could you give me the exact version of your UCCX.
Did it ever work? Do you know about a recent change (a system update perhaps) that might have lead to this situation?
G.
11-10-2014 12:29 AM
11-10-2014 12:59 AM
Hi, could you try the following: change the duration to a more friendly value, for instance, 20.
Make sure the number of "Maximum retries" (Input tab) is set to 0 and the Flush Input Buffer parameter is set to Yes.
G.
11-10-2014 01:42 AM
Changing those parameters didn't make any difference.
GTG
07-06-2015 08:14 AM
Hi Gordon,
I am trying to do exactly what you have achieved.
Please can you upload the working script.
Thanks you.
11-10-2014 01:26 AM
One more thing: what is the codec used between the UCCX endpoint and the calling device?
I think I have seen this behaviour when G.722 was used but I can't remember the details.
Actually, on second thought, if the playback works then this means the getInputStream method on the recording object returns something - it might be a different implenentation for reading bytes when doing it for persisting 'em bytes for the DB table.
Did you notice anything suspicious in the logs? An exception, perhaps?
G.
11-10-2014 01:41 AM
Doh - Should have checked the logs earlier:
Nov 10 09:16:28.941 BST %MIVR-LIB_MEDIA-3-PROB_START_RECORDING:Exception in recording: Exception=com.cisco.audio.WrongAudioFormatException: Unsupported payload type: 2
We use G.711a here. That's not a weird codec, is it?
GTG
11-10-2014 01:52 AM
Actually, the "a" might be a problem (if by G.711a you mean G.711 A-Law).
The SRND says
Recording and playback is not supported for a-law.
here (on p. 80 in the PDF version).
Is A-Law somehow forced? Most endpoints including phones and voice gateways happily support μ-Law if requested.
Could you set up a temporary Device Pool with μ-Law support and try again?
G.
11-10-2014 02:14 AM
Worked a treat. (Although the recording is quite quiet)
I wonder why they can't support a-law?
GTG
11-10-2014 02:22 AM
Hi.
Glad it worked and thanks for the rating.
I can't think of any logical reason other than there must be something nasty hidden within the UCCX core preventing the use of A-Law.
G.
11-10-2014 06:02 AM
I've fired an email off to my SE to see why UCCX doesn't support G.711a
GTG
11-17-2014 08:42 PM
Did you get a response? I have having the same issues.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide