Error: sound_file_not_found

[Harry C]

When I try to play back the digits that I enter by using Say Number Module, I got sound_file_not_fund error.

[SupportTeam]

Please post the trace files from VoiceGuide's /log/ subdirectory - the vgEngine and the ktTel traces.

We will need to see the entire vgEngine trace that captures system startup and the call. Not just an except.

We can then see how the system was initialized and what happened on the call and any previous calls and advise.

[Harry C]

The attached zip file are the log files.

Thanks

VC05232023.zip

[SupportTeam]

vgEngine trace file shows that the module named LocZip2Confirm has this specified as its input:

$RV(LocZip_CT2)

and that a Get Numbers type module named LocZip_CT2 was used immediately prior to gather some digits from caller.

 

Result Variables that are used to access 'main' data from other callflow modules should use this notation:

$RV[module title]

note the use of 'square brackets' : [ ] around the title, not 'curved brackets' : ( )

Info on Result Variables syntax: https://www.voiceguide.com/vghelp/source/html/resultvariables.htm

 

Please change LocZip2Confirm module to use this to speak out the digits (note the square brackets):

$RV[LocZip_CT2]

LocZip2Confirm module will then access the data stored in that Result Variable that contains the digits entered in the LocZip_CT2 module, and the caller will then hear the LocZip2Confirm module speak out those digits.

 

Note that the Get Numbers module type has the "Play back entered number and ask caller to confirm" option - you can use that option to let caller hear and confirm the entered number as well.

Info on Get Numbers module: https://www.voiceguide.com/vghelp/source/html/modgetnumber.htm

 

Trace excerpt:

204816.692  20   3   1     1 state [LocZip_CT2] Number Input 20878 | 
204816.692  20   3   1     1       path {20878} not found
204816.692  20   3   1     1 t     timer set   6 sec : EV_TIMEOUT_ENTERDATA
204816.692  20   3   1     1 t     timer clear force=False(LsGetNbrs_#)
204816.692  20   3   1     1       rv    add   LocZip_CT2|20878
204816.693  20   3   1     1       path {20878} not found
204816.693  20   3   1     1       find_next_vgm module=[LocZip2Confirm] (trigger={SUCCESS})
204816.693  20   3   1     1       rvns  add   LocZip_CT2_PathTaken|success
204816.693  20   3   1     1 t     timer clear force=False(RunModule_begin)
204816.693  20   3   1     1       RunModule start Say Numbers, [LocZip2Confirm], vgm=62, previous_vgm=59
204816.694  20   3   1     1       rv    replace start [$RV(LocZip_CT2)]
204816.694  20   3   1     1       rv    replace end   [$RV(LocZip_CT2)]
204816.694  20   3   1     1 state [LocZip2Confirm] Say Numbers: $RV(LocZip_CT2) as Digits | 

[Harry C]

Problem fixed after I replaced () to [], 

[SupportTeam]

Just as a note:

Traces show that the sound files used in this callflow are PCM encoded (zipcodemenu.wav, zipcode.wav), and looks like the digits sound files that have been placed in the C:\Program Files (x86)\VoiceGuide\System\Voice directory are also PCM encoded.

The SIP voice data sent in the RTP packets is usually encoded in uLaw format, not PCM.

To achieve best possible sound quality we recommend using sound files that are encoded in same format as the format use in RTP packets. This way the exact byte values in your sound file will become the contents of the data in the RTP packets - giving you exact control over the quality of the transmitted sound.

If the format of the sound file is different then the RTP format then the sound file data will end up being trans-coded into the RTP format just before being sent out. Like with all trans-coding, a minimal amount of white noise may be perceptible in the resulting file.

This may not be noticeable to the caller, but if you would like best possible sound quality then matching the sound formats to the RTP format is one thing that can be done to improve the system's transmitted sound quality.

Asking the sound prompts provider to provide 8kHz uLaw (or whatever RTP format is used) as well as high quality recordings is usually best. Any conversion into uLaw etc. should be done from high quality recordings - eg: 44kHz 16bit PCM. Converting 8kHz PCM sound file into 8kHz uLaw sound file will result in that small amount of background white noise - exactly the same as the conversion that would be done just before RTP packet transmit.