I'm newbie in the UCCE & i am facing an issue with our UCCE implementation
ours is a 8.5.1 UCCE solutions, CVP Comprehensive with SIP Proxy setup, all the devices including the combined gateway (VXML+Ingress - IOS 15.1.T3) are located in the HQ, Call flow is somthing like this
PSTN > IngressGW > CUPS > CVP > ICM
We have enabled send to originator on CVP, also given a static route for the VRU labels in the CUPS pointed to the HQ-VXML gateway to treat the CUCM originated calls
I'm now in the process of a adding a new branch with a brach combined gateway, the issue what i am facing is whatever calls i'm making to the branch DN its always playing via HQ router, i can see initial call and dial-peer requests in the branch gw, but all the VXML browsing is done on the HQ gateway.
Please help me to solve the issue, i m not attaching any screenshot or logs as i dont know which one would be relevent - please advice, so that i can upload those as well
Send To Originator is indeed a straight-forward choice to contain VRU treatment of a call within any site. To understand why your calls that are entering at the new branch site are actually receiving VRU treatment at an HQ gateway you'd want to investigate your VRU patterns, so you may want to post somescreenshots here of :
* the UCCE Network VRU Explorer, pick yout CVP VRU and clearly show the CVP VRU label;
* From (each of) your CVP Call Server(s) post some screenshots) of the SIP tab showing both Static Routes and Send To Originator patterns.
Send to originator I am pretty sure is only a trick that worked with H.323. There are a couple answers to this with SIP.
The VRU label is defined on th customer instance, of your dialed number. If you browse to the instance a VRU is set. If you look their that label is always called. With CVP in SIP you need some excellent way to do intelligent routing back to the branches for local VXML rending. I have other threads out there in 2008 timeframe on this as well.
The best and only acceptable choice in my opinion is the SIP Significant digits features. This allows you to prepend a digit at the ingress, have it stripped by CVP and held... after ICM treatment when a lab is called, you can use this significant digit in order to do unique reouting to the gateway of your choice in the SIP Proxy.
Option 2 is to make different customers for each branch office in ICM, so you can assign the a seperate network VRU, with different labels, which will give you some significance to route on. <---don't do this unless your really lazy or don't know what your doing
As I said, I think it's the nmost straight-forward way to work if you have just a couple of sites. Indeed SigDigits are the way to go if you want more control, have separate ingress/vxml gatteways, also want to keep your CUCM agent calls in the right locations etc etc. But it is somewhat more complex to set up and basically requires you to completely change your current call routing too.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...