Unable to record prompt in UCCX

[Gordon Ross]

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

[Gergely Szabo]

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.

[Gordon Ross]

We're using the prompt repository. The recording is attached.

GTG

[Gergely Szabo]

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.

[Gordon Ross]

Screen Grab attached. Recording a prompt has never worked. This is UCCX 10.5.1.11001-49. The script runs as if the prompt was recorded, but all it does is create that empty WAV file.

GTG

[Gergely Szabo]

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.

[Gordon Ross]

Changing those parameters didn't make any difference.

GTG

[ooluwafemi]

Hi Gordon,

I am trying to do exactly what you have achieved.

Please can you upload the working script.

Thanks you.

[Gergely Szabo]

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.

[Gordon Ross]

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

[Gergely Szabo · Accepted solution]

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.

[Gordon Ross]

Worked a treat. (Although the recording is quite quiet)

I wonder why they can't support a-law?

GTG

[Gergely Szabo]

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.

[Gordon Ross]

I've fired an email off to my SE to see why UCCX doesn't support G.711a

GTG

[cenglaro]

Did you get a response? I have having the same issues.