| Knowledgebase Home | Contact |
 Search the Knowledgebase |
 Jump to ID |
 Browse by Category |
| Audio files cannot be heard, only TTS is heard | ||||||||||||
| Categories: Audium Call Services 3.4.x and 3.5 | ||||||||||||
When calling into an Audium application, despite referring to an audio file in the application, the contents of the audio file are not heard. Instead the text-to-speech (TTS) backup is heard. SYMPTOMS - Not hearing the pre-recorded audio. - If there is no TTS backup, hearing the default Audium error message followed by a hangup. The logs indicate a VoiceXML error of "error.badfetch". - An e-mail sent to the application maintainer indicating a bad fetch error or other VoiceXML error such as bad encoding, bad format, corrupted file, etc. RESOLUTION The voice browser is unable to retrieve the audio files. In most cases, the cause is that voice browser is unable to evaluate the compete URL specified for the audio file because the URL is formatted incorrectly, the URL refers to a local machine instead of one that is accessible from external systems, or DNS problems. Some cases involve corrupted audio files, files in a format not supported by the voice browser, files without the correct extension, etc. These errors will most likely be reported in the voice browser logs and/or sent to the maintainer e-mail address. All these issues stem from understanding how Audium Builder for Studio, Audium Call Services, and the voice browser handle URLs for audio files. In Audium Builder for Studio, the URL entered for an audio file appears in the VoiceXML generated by Audium Call Services exactly as it was entered by the user. This VoiceXML page is sent to the voice browser and the URLs referring to the audio files are accessed by the voice browser to retrieve them. It is important to note that it is the voice browser that accesses the URL to obtain the audio files, the Audium software only passes along the URL entered by the user to the voice browser. Knowing this, one must enter a URL that is accessible to the voice browser machine, the location of the Audium system is irrelevant. So one can imagine opening up a web browser on the voice browser's machine, typing out the URL, and receiving the audio file in response. Many of the reasons audio files cannot be found are because the voice browser machine does not have access to the audio files. If the voice browser is deployed on premises, for example, its IP is most likely internal (e.g. 192.168.1.100). If the audio files are hosted on another internal machine, the URL to an audio file must refer to the correct internal IP address. If the voice browser is external, such as in a data center or using a hosted voice browser (such as Tellme), the internal machine hosting the audio files must be made available to the outside by giving it a static IP address, and external IP address, mapping a port, or some other mechanism. The URL must be absolute (in other words, it must begin with "http://") and refer to the external domain name or IP address of the machine on which the audio is placed. In order to use a relative URL (in other words, not beginning with "http://", something like "/my/relative/url.wav"), the audio files must be placed on the same machine as the Audium software (for example, if the application server being used is Apache Tomcat, the audio files would be placed in TOMCAT_HOME/webapps/ROOT/). In all other cases, absolute paths must be used. Note that using "localhost" will cause this issue because localhost is a relative term. It refers to the machine making the request, so in the case of the voice browser, a URL with localhost inside it will indicate to look for the audio file on the local machine, not the external machine hosting the audio files. Another potential cause can be DNS issues. If the URL contains a domain name as opposed to an IP address, it is possible that the domain name does not properly evaluate to an IP. To test this, use the IP address and if the issue is resolved, the DNS is at fault. Check with your systems administrator. Finally, any audio file meant for a voice application, irrespective of voice browser, must be encoded in the proper manner: mono, ulaw encoding, 8-bit or 8Hz sampling. Files encoded with any other values will not be heard by the caller and the voice browser will report an encoding error. This requirement is due to the limitations of the phone network itself, and has nothing to do with Audium or voice browsers. Each voice browser does support various file formats for audio files, such as .WAV, .VOX, .ulaw, etc. Check with your voice browser's documentation for exactly which types are supported. |
Print this page
Post a comment
(2 votes)
| Visitor Comments |
| No visitor comments posted. Post a comment |
| Related Questions |
| Attachments |
| No attachments were found. |