IQ (6160) RAD ports going into DND, sxerr_privilege_violation, Remote_Remove_DND

[flambo]

Had a strange issue yesterday in that RAD ports on an IQ would continually keep going into DND on the Mitel controller. The system has been running for some time now without error, the only change possibly being it currently being more utilised then before. The IQ also uses Update Position In Queue messaging that continued to work fine. Have checked the COS for the RAD (Application) devices against the Golden Rules and the options where set correctly and DND had been disabled - its seems as though the fix was to reboot the IQ server that had not been done for 165 days, but it was still odd to me that the ports would even go into DND, even set the expected off hook timer to max just in case?

My questions are that after looking through the log files I could see an audit that was taking place trying to undo the DND but the error sxerr_privilege_violation was being reported. I enabled the remote clear DND in the COS of the RAD / application device with no effect and am unsure what exactly is causing the violation?

The other question is that in IQ under ports, there is a feature called 'Remote_Remove_DND' which I have put the appropriate feature access code in but it seemed to have no effect - not sure if anyone has used this before?

And obviously how can the IQ put the RAD / Application device into DND if the COS prohibits it?

Many thanks in advance.

 

[LoopyLou]

There was a thing with the message length timer for RAD's. If the RAD recording was longer then the message length timer programmed then the system would put the RAD in DND. What I mean is if you set the message length timer for the RAD as 1 min but your RAD message is acutally 2 then at the end of the timer the system still sees the RAD port off hook ( its still playing the message ) and it assumes something is wrong so it places the port in DND. What we did to deal with a customer constantly changing the RAD message was increase the RAD message timer to the max. It didn't effect the system as most RAD ports dropped the connection before the timer expired.

Long story short, check that.

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.

 

[flambo]

Thanks LoopyLou for the reply, yes I know exactly what you mean as have experienced that too. The timers where the message length timer and the expected off hook timer, the later being the one that needs to be set to max (255), which I had already done but it did not help.

 

[LoopyLou]

Ok, then I am puzzled as well as to what is putting the ports into DND. With DND off in the COS of the ports then the IQ shouldn't be able to do it which leaves the 3300 as the cause. With the time set to the max I would think the 3300 would not do it, however it still might have the ability as a maintenance function if it thought the port defective. Any kind of network issue that might cause the 3300 to lose site of the IQ?

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.