Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
- Cisco Community
- Technology and Support
- DevNet Hub
- DevNet Collaboration
- Collaboration Knowledge Base
- Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200 MS
Options
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
1606
Views
0
Helpful
0
Comments
Options
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
on 01-25-2014 10:35 AM
This document was generated from CDN thread
Created by: Hariharan S on 06-03-2013 03:51:15 AM
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
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Birendra Hansda on 06-03-2013 04:10:57 AM
if {$wan_delay_ringback > 0} {
media play $incoming flash:ringback.wav
}
Regards
Birendra Hansda
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 06-03-2013 04:41:13 AM
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
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Paul Tindall on 06-03-2013 04:41:24 AM
Suggest you comment-out the "leg setupack leg_incoming" in survivability as that causes ISDN calls to be answered immediately. That should at least allow the caller to get ringback until the VRU leg is answered. If you're willing to do a bit of simple customisation the other thing you can do is answer the call explicitly from the IVR script at the point the dialogue needs to commence, using either ICM microapps or Studio application, depending on which one is delivering the initial audio. Let me know if you want to try that and I'll post a few slides later showing how it's done.
Paul
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 06-03-2013 05:01:11 AM
Hi Paul,
I will try ## leg setupack leg_incoming in TCL and will see the progress. LEt me post my updates in few minutes...
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 06-03-2013 05:10:42 AM
Hi Paul,
I made changes following:by adding # before it..I dont see a ringback on the call. :-(
# Begin CSCsg85951
#---------------------------------------------------------------------------------
# Procedure CheckDID
# This procedure is invoked when the call first arrives. If a digital FXO line, DNIS
# digits must explicitly be collected.
#---------------------------------------------------------------------------------
proc CheckDID { } {
global digital_fxo
global callident
set callident [infotag get leg_guid]
# leg setupack leg_incoming
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 06-03-2013 05:23:36 AM
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 ?
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Paul Tindall on 06-03-2013 05:33:59 AM
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.
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 06-03-2013 05:45:53 AM
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
!
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Paul Tindall on 06-03-2013 05:51:57 AM
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
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 06-03-2013 05:52:03 AM
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
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 06-03-2013 05:53:32 AM
Hi Paul,
Yes it is both ingress/VXML Gateway and could see it matches the dial-peer
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Paul Tindall on 06-03-2013 06:43:16 AM
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.
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 06-03-2013 06:52:49 AM
I tis h323 setup so deb voice ccapi inout ?
Subject: Re: New Message from Hariharan S in Customer Voice Portal (CVP) - General D
Replied by: Paul Tindall on 06-03-2013 07:04:58 AM
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.
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 06-03-2013 11:34:09 AM
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
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Paul Tindall on 06-03-2013 11:44:23 AM
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
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 06-03-2013 08:16:33 PM
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
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 06-03-2013 08:47:22 PM
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
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 07-03-2013 05:55:38 AM
Hi Paul,
Does the debug looks good ? Please advice..
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 08-03-2013 01:00:27 PM
Hi Paul,
For H323 calls, can we play a ringback/MOH During this Delay ? Or is it only possible for SIP..Please advice..
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Paul Tindall on 08-03-2013 07:43:02 PM
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
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 11-03-2013 02:17:22 AM
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
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Paul Tindall on 11-03-2013 06:18:39 AM
Good to hear you now have ringback.
Just to be 100% clear:
The TCL
Copy answer.tcl to gateway flash.
Create service --
app
service answer flash:answer.tcl
Load it using "call app voice load answer"
The VoiceXML
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 <mediaserver-path>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
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 11-03-2013 08:55:50 AM
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 <audio src="http://XX.XX.XX.XX/Media/en-us/app/MEA_Quality_Recording_V1_ENAR.wav" fetchtimeout="4s" /> 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 <mediaserver-path>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
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Paul Tindall on 11-03-2013 09:08:25 AM
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
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 11-03-2013 10:26:13 AM
Hi Paul,
Thsnk for your inputs..Let me hceck with the setup and get back to you :-)
Created by: Hariharan S on 06-03-2013 03:51:15 AM
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
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Birendra Hansda on 06-03-2013 04:10:57 AM
Hello Hariharan By modifying the survivability.tcl , you should be able to achieve this but as per my knowledge, Cisco will not support the modified script. If you still get the dead air, check your media file if it is in the flash and if you have encoded it appropriately.Hariharan S: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
if {$wan_delay_ringback > 0} {
media play $incoming flash:ringback.wav
}
Regards
Birendra Hansda
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 06-03-2013 04:41:13 AM
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
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Paul Tindall on 06-03-2013 04:41:24 AM
Suggest you comment-out the "leg setupack leg_incoming" in survivability as that causes ISDN calls to be answered immediately. That should at least allow the caller to get ringback until the VRU leg is answered. If you're willing to do a bit of simple customisation the other thing you can do is answer the call explicitly from the IVR script at the point the dialogue needs to commence, using either ICM microapps or Studio application, depending on which one is delivering the initial audio. Let me know if you want to try that and I'll post a few slides later showing how it's done.
Paul
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 06-03-2013 05:01:11 AM
Hi Paul,
I will try ## leg setupack leg_incoming in TCL and will see the progress. LEt me post my updates in few minutes...
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 06-03-2013 05:10:42 AM
Hi Paul,
I made changes following:by adding # before it..I dont see a ringback on the call. :-(
# Begin CSCsg85951
#---------------------------------------------------------------------------------
# Procedure CheckDID
# This procedure is invoked when the call first arrives. If a digital FXO line, DNIS
# digits must explicitly be collected.
#---------------------------------------------------------------------------------
proc CheckDID { } {
global digital_fxo
global callident
set callident [infotag get leg_guid]
# leg setupack leg_incoming
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 06-03-2013 05:23:36 AM
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 ?
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Paul Tindall on 06-03-2013 05:33:59 AM
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.
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 06-03-2013 05:45:53 AM
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
!
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Paul Tindall on 06-03-2013 05:51:57 AM
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
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 06-03-2013 05:52:03 AM
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
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 06-03-2013 05:53:32 AM
Hi Paul,
Yes it is both ingress/VXML Gateway and could see it matches the dial-peer
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Paul Tindall on 06-03-2013 06:43:16 AM
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.
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 06-03-2013 06:52:49 AM
I tis h323 setup so deb voice ccapi inout ?
Subject: Re: New Message from Hariharan S in Customer Voice Portal (CVP) - General D
Replied by: Paul Tindall on 06-03-2013 07:04:58 AM
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.
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 06-03-2013 11:34:09 AM
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
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Paul Tindall on 06-03-2013 11:44:23 AM
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
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 06-03-2013 08:16:33 PM
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
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 06-03-2013 08:47:22 PM
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
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 07-03-2013 05:55:38 AM
Hi Paul,
Does the debug looks good ? Please advice..
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 08-03-2013 01:00:27 PM
Hi Paul,
For H323 calls, can we play a ringback/MOH During this Delay ? Or is it only possible for SIP..Please advice..
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Paul Tindall on 08-03-2013 07:43:02 PM
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
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 11-03-2013 02:17:22 AM
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
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Paul Tindall on 11-03-2013 06:18:39 AM
Good to hear you now have ringback.
Just to be 100% clear:
The TCL
Copy answer.tcl to gateway flash.
Create service --
app
service answer flash:answer.tcl
Load it using "call app voice load answer"
The VoiceXML
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 <mediaserver-path>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
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 11-03-2013 08:55:50 AM
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 <audio src="http://XX.XX.XX.XX/Media/en-us/app/MEA_Quality_Recording_V1_ENAR.wav" fetchtimeout="4s" /> 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 <mediaserver-path>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
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Paul Tindall on 11-03-2013 09:08:25 AM
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
Subject: RE: Annoucements parallel to IVR to avoid dead air due to WAN Latency > 200
Replied by: Hariharan S on 11-03-2013 10:26:13 AM
Hi Paul,
Thsnk for your inputs..Let me hceck with the setup and get back to you :-)
Labels:
Getting Started
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:
Customers Also Viewed These Support Documents