Determining which Subflow Call Step Fails but is Valid technique

BCOLE2007 · ‎02-22-2008

Does anyone have a technique to determine which Call Sublfow is causing an applicaiton to fail on loading, this happens due to an invalid destination field in the input/output fields?

It takes a while to find this manually by deleting code and reloading to determine whats failing but is valid

bwilmoth · ‎02-28-2008

You can install Dialed Number Analyzer as a plug-in to Cisco CallManager. The tool allows you to test a Cisco CallManager dial plan configuration prior to deploying it. You can also use the tool to analyze dial plans after the dial plan is deployed.

Because a dial plan can be complex, involving multiple devices, translation patterns, route patterns, route lists, route groups, calling and called party transformations, and device level transformations, a dial plan may contain errors. You can use Dialed Number Analyzer to test a dial plan by providing dialed digits as input. The tool analyzes the dialed digits and shows details of the calls. You can use these results to diagnose the dial plan, identify problems if any, and tune the dial plan before it is deployed.

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/dna/3_3_4/dnai.html

BCOLE2007 · ‎02-29-2008

I am not familiar with this tool, How does this help idenitfy a "bad" Call Subflow step in a CRS script?

A "bad" Call Subflow causes and application to fail because the destination is not correct. Validation will not pick up the incorrect destination/step. But an upload into a CRS application will fail without indicating the error. I have several Call Subflow steps referenced and I am wondering if there is an easier way to find a bad Call Subflow.