Make plans now to attend XMPP integration with CVP 2012/06/14 @ 10:00 AM at Cisco Live! in San Diego. ...Read More

 



Cisco Developer Network will be presenting a CDN Developer Track at Cisco Live! London the week of January 31, 2011.

We are presenting technical sessions which highlight Application Programming interfaces (APIs) and Software Developer Kits (SDKs) for Cisco technologies such as Unified Communications, IOS, and Access Routing Technologies ¿ including the new Cisco Cius ...Read More

 

Recently noticed that there have been repeated questions from our developer community complaining that they can't seem to get the beep to work with <record>. They have set the beep attribute to "true" alright, and the reference guide even says this is supported but why doesn't it work?
...Read More

 

August 01, 2006
Earlier today, as I was typing a comment in our internal issuing-tracking system, I hit backspace to correct a typo. WHAM! I go back to the previous page, and my long-winded comment is gone. Apparently I somehow left the context of the text area (did I tab, or spuriously click, or??), which causes backspace to act as a hotkey for "Back". The web browser was not very forgiving of my mistake.

Are your IVR applications forgiving? They should be.
...Read More

 

Mark Gibbs over at Network World has put together a spiffy little scoring system for customer service systems (including many criteria for IVR systems). How would callers score your IVR using Mark's guidelines? Place a call and find out, you may be surprised.
...Read More

 

If you're using JNDI to connect to your database through Tomcat, then it's possible you've had to deal with database connection pool leaks. Your code tests fine, it's been reviewed, but in load tests or in production your app is unable to acquire database connections, the pool is empty!

Fear not, there are some handy parameters which can be set in your application's XML configuration file (in tomcat/conf/Catalina/YOUR_IP/YOUR_APP.xml):
...Read More

 

Showing 6 results.
Items per Page 50
of 1
First Previous Next Last

CVP Forum

« Back to CVP - All Versions

CVP and ISDN

Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
CVP and ISDN
cvp standalone outbound isdn
Answer
1/24/13 12:46 PM
Hi,
 
Currelntly i'm on a deployment for a CVP Standalone using a Outbound like script. I noticed that when i'm ussing a ISDN link to to a cellular carrier and if the callee rejects the call it rings again without the script intervention, and if the callee rejects twice or more times, the call keeps as calling and active on the CVP (VXML session keeps standby) for 5 minutes. I've tryied with an R2 link to other carrier and this behavior never shows up, what could be doing the difference on this behavior?
 
Regards,
Claudio.
Flag

RE: CVP and ISDN
Answer
1/24/13 1:44 PM as a reply to CLAUDIO RIVAS.
Simply start with a deb isdn q931 and deb voip appl script to see what the gateway is doing.
Flag

RE: CVP and ISDN
Answer
1/24/13 2:12 PM as a reply to Paul Tindall.
Hello Paul  i have been working with Claudio on this and for debug q931 we got this .. for rejection call trough isdn to pstn R2 carrier we get 931: TX -> DISCONNECT pd = 8  callref = 0x00D8
        Cause i = 0x8090 - Normal call clearing, working all flow correctly,  but in the link to cellular carrier we got this RX <- DISCONNECT pd = 8  callref = 0x80DA
        Cause i = 0x839F - Normal, unspecified , and flow stuck on step MakeCall wating for respond , is there a way to identify on vxml script this disconnection code ( 0x839F) 
 
Thanks
Jaime
Flag

RE: CVP and ISDN
Answer
1/24/13 2:16 PM as a reply to Jose jaime Vazquez.
Turn on "deb voip appl script" so we can see what event it's getting.
Flag

RE: CVP and ISDN
Answer
1/24/13 6:01 PM as a reply to Paul Tindall.
Suggest you also turn on "deb gtd detail"
Flag

RE: CVP and ISDN
cvp outbound cvp outbound standalone call studio cvp
Answer
1/25/13 2:42 AM as a reply to Paul Tindall.
Paul Tindall:
Suggest you also turn on "deb gtd detail"
Here is the log file Paul, thank you.  
Attachments:
Flag

RE: CVP and ISDN
cvp standalone outbound
Answer
1/25/13 2:43 AM as a reply to Paul Tindall.
Paul Tindall:
Turn on "deb voip appl script" so we can see what event it's getting.
here is the other file Paul. Regards, Claudio.
Attachments:
Flag

RE: CVP and ISDN
Answer
1/25/13 9:20 AM as a reply to CLAUDIO RIVAS.
I see there's no signaling event reported after the call progress.  The requesting end times-out after 5 mins and will return a "dialer_resp_timeout" back to your VoiceXML session assuming you've got the application timeout set to more than 5 mins.   You should be able to see that in the activity log.  I'm not sure what your application is doing on return from the Makecall element but as the outbound call is ending with ls_008 (near-end disconnect) I assume you're exiting the application and clearing the call.

20:19:27.301 CVP_OBCALLREQ: sent dialer record to CVP_OUTBOUND.TCL, waiting for call outcome ...
20:19:27.309 CVP_DIALER: assumed control of call with argument: <dnis=90453339558244       cli= rna=10 id=1861 uui="3122">
20:19:27.353 CVP_DIALER: event ev_proceeding on call leg 37975
20:19:29.133 CVP_DIALER: event ev_alert on call leg 37975
20:19:31.773 CVP_DIALER: event ev_progress on call leg 37975
20:24:27.301 CVP_OBCALLREQ: ERROR: timed-out waiting for dialer response, returning leg to VXML
20:24:27.329 CVP_DIALER: ID = 1861: call to 90453339558244 failed, status ls_008 (ls_008)


In the sample we provide, the response timeout is set in cvp_obcallreq.tcl to 300 secs so you can edit that to increase or decrease the time it takes to report back if that helps.  Being able to set that timeout on the Makecall element might be a useful enhancement. What is the behaviour you're trying to achieve in the case the called destination doesn't respond?
Flag

RE: CVP and ISDN
Answer
1/25/13 4:16 PM as a reply to Paul Tindall.
Paul Tindall:
I see there's no signaling event reported after the call progress.  The requesting end times-out after 5 mins and will return a "dialer_resp_timeout" back to your VoiceXML session assuming you've got the application timeout set to more than 5 mins.   You should be able to see that in the activity log.  I'm not sure what your application is doing on return from the Makecall element but as the outbound call is ending with ls_008 (near-end disconnect) I assume you're exiting the application and clearing the call.

20:19:27.301 CVP_OBCALLREQ: sent dialer record to CVP_OUTBOUND.TCL, waiting for call outcome ...
20:19:27.309 CVP_DIALER: assumed control of call with argument: <dnis=90453339558244       cli= rna=10 id=1861 uui="3122">
20:19:27.353 CVP_DIALER: event ev_proceeding on call leg 37975
20:19:29.133 CVP_DIALER: event ev_alert on call leg 37975
20:19:31.773 CVP_DIALER: event ev_progress on call leg 37975
20:24:27.301 CVP_OBCALLREQ: ERROR: timed-out waiting for dialer response, returning leg to VXML
20:24:27.329 CVP_DIALER: ID = 1861: call to 90453339558244 failed, status ls_008 (ls_008)


In the sample we provide, the response timeout is set in cvp_obcallreq.tcl to 300 secs so you can edit that to increase or decrease the time it takes to report back if that helps.  Being able to set that timeout on the Makecall element might be a useful enhancement. What is the behaviour you're trying to achieve in the case the called destination doesn't respond?

 
Hi Paul,
 
I'm trying to retry the same number after a no answer, busy or whatever is diferent to "connected", or in case the stop condition insert the next number (this last action is controlled by the script).
 
Regards,
Claudio.
 
 
 
 
Flag

RE: CVP and ISDN
Answer
1/25/13 11:19 PM as a reply to Paul Tindall.
Paul Tindall:
I see there's no signaling event reported after the call progress.  The requesting end times-out after 5 mins and will return a "dialer_resp_timeout" back to your VoiceXML session assuming you've got the application timeout set to more than 5 mins.   You should be able to see that in the activity log.  I'm not sure what your application is doing on return from the Makecall element but as the outbound call is ending with ls_008 (near-end disconnect) I assume you're exiting the application and clearing the call.

20:19:27.301 CVP_OBCALLREQ: sent dialer record to CVP_OUTBOUND.TCL, waiting for call outcome ...
20:19:27.309 CVP_DIALER: assumed control of call with argument: <dnis=90453339558244       cli= rna=10 id=1861 uui="3122">
20:19:27.353 CVP_DIALER: event ev_proceeding on call leg 37975
20:19:29.133 CVP_DIALER: event ev_alert on call leg 37975
20:19:31.773 CVP_DIALER: event ev_progress on call leg 37975
20:24:27.301 CVP_OBCALLREQ: ERROR: timed-out waiting for dialer response, returning leg to VXML
20:24:27.329 CVP_DIALER: ID = 1861: call to 90453339558244 failed, status ls_008 (ls_008)


In the sample we provide, the response timeout is set in cvp_obcallreq.tcl to 300 secs so you can edit that to increase or decrease the time it takes to report back if that helps.  Being able to set that timeout on the Makecall element might be a useful enhancement. What is the behaviour you're trying to achieve in the case the called destination doesn't respond?
 
Hi Paul,
 
Seems to be running fine for this time, and as you said it's a nice enhancement. I appreciate your help.
 
Regards,
Claudio.
 
 
Flag