Please let us know which application specifically is having this problem, we'll take a look.

Fuse only supports US addresses at this time. However, you could use the VXML Subdialog module (found under Data Integration) to collect your Canadian address in a separate VXML subdialog. Our platform, Plum Dev, does support Canadian addresses.

However, you will need to write your own subdialog in VXML and host it on your own webserver. More details can be found here: http://quickfuseapps.com/docs/module/su … _subdialog

The first and last name modules should be able to recognize the most popular names in the US. If the last name is not a common one in the US, it may not be recognized. Also, when using the name modules, the caller must first say the name, then spell it out.

You may also want to change the sensitivity in the app settings. If your callers are in a noisy environment, you can try changing sensitivity to "only listen to loud input."

A better way to do this is to send the "start time" call property to your SOAP web service. That way you can calculate the elapsed time in your webservice.

No, Fuse does not support any GPS capabilities.

Your newer SOAP webservice is returning improperly formatted cookies. Specifically, in the SOAP header, the line that contains "Set-Cookie:" is not formatted correctly. It should be "Set-Cookie: COOKIENAME=cookievalue"

Which data are you talking about? You can download CSV versions of your Simple Database at anytime.

We do believe you found the problem prompt. We have placed test outbound calls using v26 and v27 (as well as the current revision) of your application. We verified that on the second prompt of v26 we experienced the issue you described. On v27 and the current revision, the prompt no longer experiences this issue.

We are actively working on a fix to help with this issue, and will let you know as soon as it is deployed.

If you have any data integration to webservices or Simple Database before the first prompt, that may be the source of the delay. If not, you should hear your first prompt immediately. If you are testing via the Run! button, that also causes the application to be far slower than usual since it has to sync up with the visuals on the web browser.

Another thing that might be causing a "delay" for outbound calls is that outbound calls do not connect until they detect something on the other line. For example, if you queued an outbound call to yourself and said "Hello?" like a typical callee, the outbound call would start immediately. However, if you picked up and remained silent, the call would not begin until several seconds later when it detected it was connected.

There's no perfect way to make your outbound campaign leave voicemails but the best way to do this would be:

1. Outbound call goes out

2. Callee's phone rings then goes to voicemail

3. As soon as voicemail picks up, the outbound call is connected and will begin immediately

4. This is the imprecise part. You'll need to determine how many seconds to delay the call so that your message will begin after the callee's voicemail prompts have ended. This is different for every single voicemail system, but the more you know about your callees' voicemail systems, the more accurate you can make this delay.

If your outbound campaign reaches a real person, then this application would be pretty confusing for them as they would also hear that predetermined silence you added in the beginning. This is why we suggested in previous support emails that you use the workaround of playing a prompt like, "Please press 1 to hear your message." You should set the timeout to the number of seconds as determined in step 4 above. That way if it's a real person, they will press 1 and hear the message. If not, the application will wait x seconds to timeout, and then it can play the message anyway.

If you go to Configure > Audio, where you upload audio, you can also hear it playback. What you hear during that playback is what you'll hear during the call. If your audio is being shortened after you upload, you may be uploading your audio in a format we don't support. We support the following audio formats:

8 kHz 8-bit µ-law encoded headerless (*.ul)
8 kHz 16-bit linear PCM WAV (*.wav)
8 kHz 8-bit µ-law WAV (*.wav)
8 kHz 8-bit a-law WAV (*.wav)
MP3 (*.mp3) - Note: If the audio file is poorly encoded, the mp3 will not work.

Also, we do not support spoofing DTMF tones. We don't transmit directly down the PSTN. Our platform is SIP based and sends DTMF tones as custom packets in the RTP stream. The gateway and/or session border controller would filter out the spoofed tones so the far end would never hear them.