This is a bit like saying you have just built a motor car but it's not working properly and you post a circuit diagram of the radio and ask us to help.
In the words of the inimitable Rodgers & Hammerstein:
Let's start at the very beginning
A very good place to start
When you read you begin with A-B-C
When you sing you begin with do-re-mi
When building up a CVP deployment, getting CUCM-originated calls working is the last piece of the puzzle. You should always start with calls into the gateway from either the PSTN (T1/E1) or an analogue phone into an FXS port, and work in stages, testing each stage, and adding complexity and redundancy until you reach the final setup.
Now if you don't have a T1/E1 or FXO for your gateway, and all you have is an IP phone, it's still advisable to build that the correct way, because you surely will have that PSTN connection eventually. I'll get to that part last.
This is the way I normally work through the CVP SIP build out.
(It appears that your NVRU label on CVP routing clients is 8001234567 and your agent extensions are similar to 2xxxx. )
Do
Call Server and no outbound proxy.
Gateway dial peer finds the Call Server through "session target ipv4::5060.
Call Server configured with "send to originator" to push the NVRU label 8001234567 back to the ingress gateway to start the VXML.
Add "send to originator" for the ringtone label 91919191
Add "send to originator" for the error label 92929292
Play a message, queue the call.
When an agent goes ready, a static route in the Call Server for 2> points to a subscriber
SIP trunk from CUCM to Call Server
Re
Remove the static route 2> from the Call Server
Change the Call Server to use the Outbound Proxy and restart the Call Server
Add a SIP trunk from CUCM to CUSP
Put your 2 pattern in CUSP to the Sub server group (your key 2 target-destination cucm.ipcc.com enterprise)
Mi
Change the dial peer in the gateway to send the call to the SIP Proxy
Add a route in the route table to find a Call Server (your key 77 and key 88 to the CVP server group)
Fa
Remove 8001234567, 91919191, 92929292 from the "send to originator" section
Add a route in the proxy for the NVRU label 8001234567 to find your gateway (your key 8001234567 for the gw server group)
Once you get this working, put the send to originators back for a branch-office deployment
So
IP phone calls a CTI Route Point mapped to the JTAPI user which has Dialed Number-Call Type-Scheduled Script
Add a label 8222222222 on the CUCM routing client to the NVRU
The first "Send to VRU" node returns 8222222222 to CUCM
CUCM has a Route Pattern on 8222* - the target is the SIP trunk to the Proxy server!
Add a route to the SIP proxy to find a Call Server for this pattern - in your case, add "key 82222 target-destination cvp.ipcc.com enterprise"
The script has a SECOND explicit "Send to VRU" to return the 8111111111 to CVP
CVP finds a gateway through the Proxy server - we set that up and tested it in the previous step
La
Check all the server groups in the Proxy are working correctly
Check that the OPTION PINGs are getting to all the elements and all server groups are up
Turn off/disable elements of the server groups in turn to ensure all redundancy is correctly set up (for the Call Servers, for the Subs, for the Gateways)
Ti
Configure a Server Group in the Call Servers for the 2 Proxy servers
Change the Call Server to use SRV local, no Outbound Proxy, and configure the target as the Server Group.
Add a second preference dial peer at the gateway to find the second CUSP or use srv records on the gateway
Do
Configure a Route Group/Route List of the two CUSP SIP Trunks in CUCM (probably Circular) and change the Route Pattern for 82222* to point to the Route List now instead of the trunk.
Remove the SIP trunk to the Call Server.
Now sing after me ...
Regards,
Geoff
