This will cause the Media Server to save all interactions to audio files and never delete them, allowing you to access them at will.
Users looking to do speech tuning (reviewing audio to improve the performance of their application) are not recommended to use the save_waveform functionality. Instead, they should enable response file generation and use the LumenVox Speech Tuner. The response files contain much information that is vital to tuning which is not present in raw audio files:
The primary use of saving raw audio with save_waveform should be just to verify that audio is making it to the Media Server.
Waveform Filenames
The name of the waveform generated is made up of the session identifier, plus a sequence number relating to the individual sequence within the session (since a single session can have multiple decodes, and therefore multiple waveforms associated with it), followed by a suffix based on the audio format selected.
The session identifier used is based on whether you are using RTSP or SIP:
In the case of RTSP, it is the Session: value associated with the session. This is followed by an underscore, then the corresponding sequence number associated with the RECOGNIZE request, so if the Channel-ID was “5891c16e-1d6f-4e51-a” and the REQUEST sequence number was 5 and the audio format was ulaw, the waveform filename would be:
5891c16e-1d6f-4e51-a_5.ulaw
In the case of SIP, the filename is made up of the Channel-Identifier, followed by the corresponding sequence number, with the audio format suffix. So, if your Channel-Identifier value was “32AECB23433801@speechrecog” and the sequence number associated with the recognition was 11 and the audio format was alaw, the name of the generated wavefile would be:
32AECB23433801@speechrecog_11.alaw
When the current recognition request is completed, the name and location of this waveform file are sent back to the MRCP client as part of the RECOGNITION-COMPLETE message. In RTSP, this is returning the Waveform-URL header, and in the case of SIP sessions, this is returned in the Waveform-URI header. When trying to determine the name of any generated waveform file, this should be the primary source used, since this will give the actual name that was generated, along with any configured prefix. Typically, users specify a prefix (waveform_url_prefix) and a location where these files are saved (waveform_url_location) in their configuration settings, as described above.
For UniMRCP Users
Note that users of the UniMRCP client interact (often in conjunction with Asterisk or some derivative platform) can access the Waveform-URI or Waveform-URL using the ${RECOG_WAVEFORM_URI} variable within their applications.
Please refer to the UniMRCP documentation for more information relating to this.
You can use this variable within your dialplan. For example, this will log out the value to the Asterisk console:
exten=>s,n,Verbose(1,The recognition waveform
URI is ${RECOG_WAVEFORM_URI})
Other Notes
Only audio packets received while the MRCP session is in a RECOGNIZING state will be saved, so audio sent between RECOGNIZE requests will be discarded and not saved (this is per the MRCP specifications). Consider a full packet capture if you need to get the entire RTP stream between a voice platform and the Media Server.
DTMF audio will also generally not be present in saved audio files. This is because LumenVox does not support nor expect to receive inband DTMF audio tones; instead DTMF must be converted to RTP Events per RFC 4733 before being sent to the Media Server.