I know this probably sounds like a silly question, but understand that when using survivability.tcl, that TCL file and service on the dial-peer is what actually plays "critical_error.wav" or the like... When you are *not* using survivability, CVP sends a REFER to the Originator with the error DN (default is 92929292).
We can see this REFER sent to the originating gateway, and we can even match the pattern to a dial-peer (though it must be configured as a destination-pattern and not an incoming called-number as shown in the documentation)...but we cannot get "cvperror.tcl" and the associated "cvperror" service to actually work.
So after fruitless searching, I'm convinced that this might not actually work at all, or I'm missing a configuration setting somewhere (I'm hoping that is the case, actually).
Can anyone actually tell me they have a system that shows the error DN being passed to the gateway, matching the dial-peer with configured service, and actually calling cvperror.tcl to play the critical_error.wav?
The second part is, if the answer is "yes", are you using survivability and/or CUPS as a SIP Proxy?
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...