One of the configuration required on the gateways that interact with CVP is the 987654 work around.
Play Media and Play Data IOS VXML templates, contain a "dummy" transfer to 987654 that is meant to fail. However,
it is possible that the gateway contains a dial-peer that will actually try to send a call to 987654. The following lines should be added to the gateway to prevent that dial-peer match from occurring. Add these lines verbatim (987654 is the real number you type here)..
voice translation-rule 1
rule 1 /987654/ //
!
voice translation-profile block
translate called 1
!
dial-peer voice 987654 voip
translation-profile incoming block
incoming called-number 987654
Finally, apply the translation-profile incoming block, as listed in the above dial-peer, to ALL the voip dial-peers in your config.
We need this work around, because the <prompt> statement is a non-blocking statement according to the VXML spec. Hence, when the IOS voice browser receives a <prompt> statement in the VXML as part of a PM or PD microapp, it will start playing the prompt AND submit back a URL to CVP (call result) right away before the prompt has finished playing.
This is problematic since to CVP it looks like the prompt finished playing and now it goes back to ICM to continue the next node in the script which could also be another prompt. At this point, the first prompt may still be playing on the GW and GW will continue to queue up the new prompts but keep returning back to CVP who thinks all the
prompts played.
Hence, to force the GW to not submit a return URL until it has finished playing the prompt, the <prompt> block is put inside a <transfer> block with a transfer to 987654 which will not return until the prompt has finished playing.
Note, VoiceXML Server applications use this work around as well, so it is important to include this translation profile even in CVP Standalone/VXML deployments.
Some symptoms of 987654 translation rule/profile config not implemented on the GW include:
PM plays the .wav file just fine, but does not return control to the routing script. There is no indication of a failure or a success in the script. Debugging from the App Server and/or VB shows that the call was abandoned. Debug from the ICM router shows a label of 987654 coming back to the router after the .wav file has been played, and the router cannot make a match.
This is an indication that the 987654 translation profile has not been configured correctly.
