10-12-2010 08:20 AM - edited 03-14-2019 06:40 AM
Hi,
I have a CVP deployment model "Stand-Alone Self-service", with CUCM 7, CVP 7, CISCO 2821 ISR
Call-flow of service is:
PSTN -----> VoiceGateway (dial peer to CVP application-service ) -------> CVP VXML Application (Play of message and transfer to Directory Number)
In CVP VXML Application there is a "transfer" - "phone" node type that is assigned with number of CUCM Hunt Pilot
(Es: there is in the node numer 9999 that is issued on CUCM as Hunt Pilot)
On Cisco 2821 there is a dial peer voip with "destination pattern" 9999 and session target IP : CUCM IP
Hunting works but only by CUCM: in this solution the transfer of the user call from CVP (after play message) to CUCM Hunt Pilot fails.
Log CVP shows error: Transfer,data,result,network_busy
This scenario is possible ?
The best solutions is a Cisco IP IVR?
Thanks a lot
Francesco
Solved! Go to Solution.
10-15-2010 02:11 AM
Hi Francesco
For the VXML GW, when the call needs to be sent to CUCM, it becomes IPIP or CUBE for two IP Leg.
depending on what protocol you are using, in addition to the dial-peers, you need to have following commands
voice service voip
allow-connection sip to sip
allow-connection h323 to h323
allow-connection sip to h323
allow-connection h323 to sip
!
hope this helps.
thanks
- abu
10-12-2010 11:04 AM
Definitely possible.
Change the gateway for a test. On that dial peer add a translation profile with a rule to translate your 9999 into an extension number - a configured and registered phone that you know is there.
dial-peer voice 9999 voip
description CVP standalone - transfer
translation-profile outgoing xfer
destination-pattern 9999
session target ipv4:192.168.0.10
dtmf-relay rtp-nte h245-signal h245-alphanumeric
codec g711ulaw
no vad
(Assume 192.168.0.10 is a subscriber)
This surely works - it works for me. Change it to bridge transfer in CVP studio (or on the VXML server) for debugging - you can come out and catch the network_busy if there is one. Does this work? Can you hit a phone?
Now drop the trans profile and run the test again.
Regards,
Geoff
10-13-2010 03:52 AM
Hi Geoff,
I thank you for your suggestions!!
Unfortunately I had already tried your solution, even by entering in the node "transfer", the Directory Number associated with an Cisco IP Phone
(registered on CUCM).
The result is the same: network busy on CVP' log application and call drop.
Also I can confirm that the node in the CVP "transfer" is "bridge - true" and "phone type"
I was thinking of trying the problem:
1) A particular parameter to be assigned ("param redirect - redirect paramspace ...)
in the application - service section on config voicegateway;
2) Improper configuration of the solution:
On the CUCM I surveyed VG and CVP as "Gateway H323" only; I do not use trunk or gatekeeper;
Best regards.
Francesco
10-13-2010 08:40 AM
You need to debug this on the gateway.
When the VXML command comes back to build the bridge transfer, something is going wrong. You don't need a param on the service to make this transfer.
debug ccapi inout should show something like this on the transfer:
000469: *Oct 13 11:36:16.685: //523/69DEFDDA805D/CCAPI/ccCallSetupRequest:
Destination=, Calling IE Present=TRUE, Mode=0,
Outgoing Dial-peer=333, Params=0x471566A8, Progress Indication=NULL(0)
000470: *Oct 13 11:36:16.685: //523/69DEFDDA805D/CCAPI/ccCheckClipClir:
In: Calling Number=4082521112(TON=National, NPI=ISDN, Screening=User, Passed, Presentation=Allowed)
000471: *Oct 13 11:36:16.685: //523/69DEFDDA805D/CCAPI/ccCheckClipClir:
Out: Calling Number=4082521112(TON=National, NPI=ISDN, Screening=User, Passed, Presentation=Allowed)
000472: *Oct 13 11:36:16.685: //523/69DEFDDA805D/CCAPI/ccCallSetupRequest:
Destination Pattern=408447T, Called Number=4084473001, Digit Strip=FALSE
000473: *Oct 13 11:36:16.685: //523/69DEFDDA805D/CCAPI/ccCallSetupRequest:
Calling Number=4082521112(TON=National, NPI=ISDN, Screening=User, Passed, Presentation=Allowed),
Called Number=4084473001(TON=Subscriber, NPI=ISDN),
Redirect Number=408447, Display Info=
Account Number=, Final Destination Flag=TRUE,
Guid=69DEFDDA-D616-11DF-805D-00131AA41870, Outgoing Dial-peer=333
In my case, the outgoing dial peer 333 is
dial-peer voice 333 voip
description standalone - AA transfer (last 4)
destination-pattern 408447T
session target ipv4:16.91.120.135
dtmf-relay rtp-nte h245-signal h245-alphanumeric
codec g711ulaw
no vad
my application takes the last 4 digits entered (3001) and prepends 408447. you can see above "Called Number=4084473001"
Regards,
Geoff
10-14-2010 04:53 PM
Francesco,
Have you tested this again. Any traces?
Regards,
Geoff
10-15-2010 02:11 AM
Hi Francesco
For the VXML GW, when the call needs to be sent to CUCM, it becomes IPIP or CUBE for two IP Leg.
depending on what protocol you are using, in addition to the dial-peers, you need to have following commands
voice service voip
allow-connection sip to sip
allow-connection h323 to h323
allow-connection sip to h323
allow-connection h323 to sip
!
hope this helps.
thanks
- abu
10-15-2010 03:20 AM
Hi Abu,
great,It works!!
voice service voip
allow connection h323 to h323
Next step I write a tcl script for incomning PSTN calls when VG is in SRST (IP WAN down - CVP not available): this script
routes incoming calls on ephone - hunt group registered on VG during SRST, after a play of audio.
This is an emulation of scenario whit CVP.
Thanks a lot Abu
Francesco
10-15-2010 03:13 AM
Hello Geoff,
I picked up the trace as I've suggested with the debug command
I eventually solved by operating the VG as a CUBE.
The configuration added (suggested by Abu Hadee) is:
voice service voip
allow-connection h323 to h323
The next step is to review a TCL script that routes the incoming call PSTN on hunt group or ephone
(registered on VG as ephone) during SRST (CVP not available for WAN connection down or CVP server/serivces down)
If my script works then I public it: it might help someone
Thanks for your time.
Now it works.
10-15-2010 11:17 AM
I picked up the trace as I've suggested with the debug command
I eventually solved by operating the VG as a CUBE.
The configuration added (suggested by Abu Hadee) is:
voice service voip
allow-connection h323 to h323
Sorry, I am so used to CVP that my gateways always have that, and Cisco have that in the Guide.
Should have asked to see your complete gateway config.
Regards,
Geoff
10-15-2010 11:22 AM
The next step is to review a TCL script that routes the incoming call PSTN on hunt group or ephone
(registered on VG as ephone) during SRST (CVP not available for WAN connection down or CVP server/serivces down)
If my script works then I public it: it might help someone
Cisco already allow you to do this:
service my_app flash:CVPSelfService.tcl
paramspace english language en
paramspace english index 0
param CVPPrimaryVXMLServer 16.91.120.234
param survive myapp_survive
param CVPBackupVXMLServer 16.91.120.234
param keepalive ground
param CVPSelfService-port 7000
param CVPSelfService-app MyApplication
and
service myapp_survive flash:survivability.tcl
paramspace english index 0
paramspace english language en
param alert-timeout 180
paramspace english location flash
param setup-timeout 7
paramspace english prefix en
param after-hours-agent1 4084473002
!
Regards,
Geoff
11-12-2010 12:44 AM
Hello Geoff, thanks for the suggestion.
I wish it was in SRST mode before playing a message "welcome"
(message "custom" of the customer) and then the PSTN call is transferred to the corresponding DN.
The file "survivability.tcl" I do not believe you allow this function: need to change it?
In the file "survivability.tcl" there is not a section "act_Media proc {}" which would serve for my case.
Cisco also says it does not change the files. "Tcl" connected with the CVP.
How do I proceed?
Francesco
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide