RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200

2013-03-11T15:26:13Z

Hi Paul, Thsnk for your inputs..Let me hceck with the setup and get back to you :-)

RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200

2013-03-11T14:08:25Z

Just treat answer.vxml as though it's a media file as it will be located in the same way. In your case, I'd suggest dropping it into your "/Media" folder, set the applib ECC to ".." and the resultant URL should be http://x.x.x.x/Media/answer.vxml. Then, set your applib ECC back to "app" before playing your prompts. Paul

RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200

2013-03-11T13:55:50Z

Hi Paul, Got You..i was half way through..like i loaded the answer.tcl,VXML and removed PI=8 in the voip dial-peer and disabled leg connect in Bootstrap and invoked answer service and also addded alerting_1 under bootstrap. So i need to work on now with on Flash: for VXML Locate answer.vxml in your media file path; this can be in flash but doesn't have to be; it can be on your media server. If you put it in flash then make sure your media server ECC variable is pointing to "flash:" and the applib ECC variable is set to ".." I see so i need to point this under answer.vxml ? If you put it in on your media server then also put it at the top level and set the applib path to ".."Use "GS,answer,V" as the microapp to invoke it -- this will reference the file at answer.vxml. Use "sho http client hist" on the gateway to verfiy the actual location the gateway is trying to load answer.vxml from. Paul

RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200

2013-03-11T11:18:39Z

Good to hear you now have ringback. Just to be 100% clear: [u]The TCL[/u] Copy answer.tcl to gateway flash. Create service -- app service answer flash:answer.tcl Load it using "call app voice load answer" [u]The VoiceXML[/u] Locate answer.vxml in your media file path; this can be in flash but doesn't have to be; it can be on your media server. If you put it in flash then make sure your media server ECC variable is pointing to "flash:" and the applib ECC variable is set to ".." If you put it in on your media server then also put it at the top level and set the applib path to ".." Use "GS,answer,V" as the microapp to invoke it -- this will reference the file at answer.vxml. Use "sho http client hist" on the gateway to verfiy the actual location the gateway is trying to load answer.vxml from. Paul

RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200

2013-03-11T07:17:22Z

Hi Paul, In Quotes "Remember that external VoiceXML files are located at run-time using the media server path ECC variable, the same path variable that's used for media files. The TCL file should be copied to flash on the VoiceXML gateway and a service "answer" should be defined that points to it." I copied the answer.tcl and vxml in flash and pointed it to service answer in VXML. I need to point any media files here inside this vxml ? Because once i done with this and made a call, i see ringback for all the times no IVR i could hear.. Please advice..i guess we are near to the fix

RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200

2013-03-09T01:43:02Z

Yes, the debug looks good. If we look at the timeline of the different phases between initial call setup and the first prompt, we have the following: 0s Call setup received  1.7s Call answered (by CVP H.323 service)  2.8s VRU leg setup and bootstrap.tcl executed  4s Initial HTTP request to CVP IVR service  5.85s First VoiceXML doc to play audio That does present some challenges, especially because the call is answered by the call server in the H.323 case. That said, it should be possible for the caller to hear ringtone from the network until that point. However, I do see PI 8 is set in the ALERTING message which will open the backward voice path to the caller and result in dead air. You could look at your PSTN gateway and ensure PI 8 isn't being sent on ALERTING but at best it will only help a small amount. You could try setting the wan-delay-ringback parameter on survivability but that is really only going achieve the same effect by a slightly different approach. Once the call server answers, you will get dead air again. The situation would be easier to address with SIP but there is one thing you could try in order to introduce a burst of ringtone after the call is first answered. The approach is to comment-out the leg connect in bootstrap.tcl and enable alerting, which you can do by setting the parameter "send_alerting 1" on the bootstrap service. The next thing to do is answer the VRU call leg explicitly from the ICM script using a GS…,V microapp. You can do this using a simple static VoiceXML doc and TCL script (attached). Remember that external VoiceXML files are located at run-time using the media server path ECC variable, the same path variable that's used for media files. The TCL file should be copied to flash on the VoiceXML gateway and a service "answer" should be defined that points to it. Give it a try and let me know how it goes or if anything needs more explanation; I realise this might be a bit brief. Paul

RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200

2013-03-08T19:00:27Z

Hi Paul, For H323 calls, can we play a ringback/MOH During this Delay ? Or is it only possible for SIP..Please advice..

RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200

2013-03-07T11:55:38Z

Hi Paul, Does the debug looks good ? Please advice..

RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200

2013-03-07T04:39:45Z

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. Error: Exceeded Retries to Application Server for New Call Request. Going to Recovery VXML

RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200

2013-03-07T02:16:33Z

Hi Paul, Thanks for the debug instructions.. PSTN calls are coming in one router and VXML service is initiated on other router. Attached are the logs and clocks are sync with NTP so timing should be fine between the two routers. During the testing, i hear less delay since it is afterhours and no much traffic on the Pipe.. With Regards, Hari.S

RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200

2013-03-06T17:44:23Z

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

RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200

2013-03-06T17:34:09Z

Hi Paul, Thanks for making me to know about the logs!!!! Looks like call comes at 12:54 but Http Stream started obly by 12:57 so 3 seconds delay is observed here.I am not able to play Ringback unfortunately between this 3 seconds delay. What could be the next steps :-) With Regards, Hari.S

Re: New Message from Hariharan S in Customer Voice Portal (CVP) - General D

2013-03-06T13:04:58Z

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. On 6 Mar 2013, at 12:53, "Cisco Developer Community Forums" > 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.

RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200

2013-03-06T12:52:49Z

I tis h323 setup so deb voice ccapi inout ?

RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200

2013-03-06T12:43:16Z

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.

RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200

2013-03-06T11:53:32Z

Hi Paul, Yes it is both ingress/VXML Gateway and could see it matches the dial-peer

RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200

2013-03-06T11:52:03Z

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

RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200

2013-03-06T11:51:57Z

Survivability is invoked on the incoming dial-peer on your ingress gateway. The config you show is on the VoiceXML gateway so only add it here if this is the same device as your ingress gateway. Will be offline for a while. Paul

RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200

2013-03-06T11:45:53Z

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 !

RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200

2013-03-06T11:33:59Z

If you're using survivability then it has to be defined as an application on the ingress gateway and referenced in the incoming dial peer service command. 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. The call will then be answered when the VRU leg is set up and then you'll typically get silence until the initial VoiceXML dialogue is at the point of playing initial audio. So, changing the signalling should mitigate your call setup delays but you still have to go a bit further to eliminate the delays due to the HTTP/VoiceXML dialogue.