On 18/03/15 23:55, Daniel Pagan wrote: > Definitely makes sense and what I thought you were trying to achieve. If this > is the case, then rejecting the call via xlate or route patterns won't do - > the call will be rejected instead of connecting and then being disconnected. > You'll more than likely receive the standard recording from your call agent > or provider for a non-working number. > > I can't think of anything native to CUCM that would answer and then > disconnect the call. At the end of the day, for this to happen, the call > would not only need to be routed to some endpoint whether its SIP, SCCP, CTI, > H.323, or MGCP, but also accepted by the endpoint and only then > disconnected... this is basically what CUC is doing for you. In other words, > the call would need to go somewhere :) I was thinking maybe call queueing on > a hunt pilot with no logged in HG members but even that won't help. > > Do you have UCCX? Is CUBE part of the call-flow? You can do something > creative here like Tim Smith mentioned (TCL script in IOS). If UCCX, simply > route the call to a trigger, accept it, add a delay step for two seconds, and > then disconnect it.
No UCCX, we have 2921s as H.323 E1 gateways, but no CUBE licensing. I've never done TCL scripting before, so I think the easiest option is to just bite the bullet and upgrade it via PCD from 8.6 to 10.5 and join the rest of the now-virtualised servers. Thanks, -- James Andrewartha Network & Projects Engineer Christ Church Grammar School Claremont, Western Australia Ph. (08) 9442 1757 Mob. 0424 160 877 _______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
