How important is it to have the failure branch of a Run External Script node point to somewhere other than the success branch?
We have quite a few scripts built by other people with the success and failure branch both pointed to the next node in the script regardless. Besides the call not recieving the prompts or announcements are there any other consequences to not fixing these?
Interesting technique. I would never do that. I connect the X node to an ICM script called something like SYS_F_RES (system failure run external script) and this sets a call type and returns END if the call comes from the PSTN and Release if the call comes from CUCM (this is CVP). Setting the call type allows a quick WebView/CUIC report check. Bringing all failures through a single script allows a quick check with Monitor.
(PS: I also have similar little scripts/calltypes for Send 2 VRU failure, DN list failure, queue 2 skill group failure. )
Normally these things only fail in development, when you have the WAV file wrong/missing, the config params wrong. But in production there are the predictable failures (max no entry, max no match) you need to deal with correctly.
IntroductionCUCM Routing RulesDial String implementation PolicyCUCM Routing LogicSIP URI Call Routing Analysis+++ Case Study: 1 ++++++ Case Study: 2 +++Conclusion
Over the last few months, I have had the privilege of working on SI...
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...