Hi Experts,
I have a Ingress/VXML gateway talking to CVP. Since the latency is more than 200 MS i hear around 4 to 6 seconds delay in call to play the first prompt. I could see it is due to WAN delay. But i am seeing a bug "csctd31704" and since we are running CVP 8. As per SRND
"• On the survivability service, the setting for "wan-delay-ringback" can be set to 1 to add a ringback tone during longer than normal call setup times with IVR."
"• Setting WAN Delay to zero will have the effect of immediately playing holdmusic.wav and then playing it for a minimum of 5 seconds."
I see after changing this on survivability.tcl still ringback is not prompting intead it is silence / dead air till first prompt getting played.
My Query:
Is there a way we can make the Music on Ring for the caller in local gateway using a TCL Script parallely transfer the call to VXML till first prompt gets played ? So users wont experience a silence till first prompt ?
I am sure you guys might have fixed issues similar to the Query..Please assist on this.
 
Thanks in advance for your support and co-operation.
 
With Regards,
Hariharan.S

Hi Birendra Hansda,
Since it is CVP 8..new TCL have that bug fixed: But still seeing that issue ..Hope you can help..
 
       # CSCtd31704 Excessive WAN delay can cause unacceptable delay in hearing first prompt
       if {$wan_delay_ringback > 0} {
           media play $incoming flash:ringback.wav
       }
With Regards,
Hari.S

Hi Paul,
I will try ## leg setupack leg_incoming in TCL and will see the progress. LEt me post my updates in few minutes...

Hi Paul,
One More Query, Do i need survivability.tcl to be added as an application in VXMl Gateway ? I guess this is an automatic event once the call comes in am i correct ?
 

Hi Paul,
Thanks for your inputs. always giving me good hope here..
Reg. Applications..i see following are added here.. And i do see survivability.tcl in flash.So i may need to add this service and associate it to incoming dial-peer is that correct..then this changes will take effect ..Am i correct..
application
 service new-call flash:bootstrap.vxml
  paramspace english index 0
  paramspace english language en
  paramspace english location flash
  paramspace english prefix en
 !
 service ringtone flash:ringtone.tcl
  paramspace english index 0
  paramspace english language en
  paramspace english location flash
  paramspace english prefix en
 !
 service recovery flash:recovery.vxml
  paramspace english index 0
  paramspace english language en
  paramspace english location flash
  paramspace english prefix en
 !
 service cvperror flash:cvperror.tcl
  paramspace english language en
  paramspace english index 0
  paramspace english location flash
  paramspace english prefix en
 !
 service handoff flash:handoff.tcl
  paramspace english index 0
  paramspace english language en
  paramspace english location flash
  paramspace english prefix en
 !
 service bootstrap flash:bootstrap.tcl
  paramspace english language en
  paramspace english index 0
  paramspace english location flash
  paramspace english prefix en
 !

Hi Paul,
 
I added the application
!
service survivability flash:survivability.tcl
 paramspace english language en
 paramspace english index 0
 paramspace english location flash
 paramspace english prefix en
!
And associated to POTS and could see it is matching but no change in behaviour..same 4-5 sec delay our there till it hit first prompt..
Reg "Regarding ringback, if you want to force immediate ringback you can insert a "leg alert leg_incoming" where the leg setupack is.  You should then see the ALERTING sent immediately in your ISDN Q.931 debug trace on the ingress gateway." i am still a new bie :-) not able to see where to really search for this under survivability.tcl script.may need your help as well

Suggest you turn on some debug just to make sure things are working as expected and we can see where the delays are.

deb voip appl script
deb isdn q931
deb ccsip mess
deb http client msg
 
Make sure you have "no logging console" set and collect the trace in the logging buffer otherwise you'll get gaps in the trace.

That changes things considerably as the CVP Call Server will answer the call immediately so we're not going to achieve much at all by manipulating the signalling. You should still collect the logs to confirm where the delays are. Use deb h225 q931 if my memory serves me correctly.

<Sent from mobile device>

On 6 Mar 2013, at 12:53, "Cisco Developer Community Forums" <cdicuser@developer.cisco.com<mailto:cdicuser@developer.cisco.com>> wrote:

Hariharan S has created a new message in the forum "General Discussion - All Versions": -------------------------------------------------------------- I tis h323 setup so deb voice ccapi inout ?
--
To respond to this post, please click the following link: http://developer.cisco.com/web/cvp/community/-/message_boards/view_message/12696018 or simply reply to this email.

Looks like there are large gaps in the log.  You need to collect the log in the logging buffer and extract it after the test, not just feed the trace to the terminal.
Make sure you have the following configured --
no logging console
logging buffered 10000000
 
Turn on the following debugs --
deb isdn q931
deb h225 q931
deb voip appl scrip
deb http client msg
 
Do the following --
clear log
<< Perform the test >>
ter len 0
sho log
 
Capture the screen output from the show log and attach it as a text file to your response.  Please don't paste it into the response.  Once we can accurately see where the worst delays are, we can suggest the best ways to mitigate.
 
Paul

Hi Paul,
In VXML Gateway this action is normal ? or we do get timeouts and retrying makes any delay..again i am just a newbie so i will wait for your valuable analysis.
<catch event="error.badfetch">
                <if cond="TryNum == MaxTries">
                        <if cond="DEBUG == '1'">
                                <log> Error: Exceeded Retries to Application
Server for New Call Request.  Going to Recovery VXML