What you're experiencing is a variation of the bug (design flaw is more accurate) that you may have seen me complaining about recently. The implementation of calling features like Call Forward (all flavors) and Do Not Disturb, which clearly should apply only to calls that would otherwise terminate at the PHONE Port, is tangled up with the processing of InboundCallRoute rules (where COT, bridging, etc. is accomplished). The end result is InboundCallRoute processing totally fails or behaves unexpectedly if Call Forward or Do Not Disturb is ever enabled.
I have a fairly elaborate configuration here which supports Google Voice, several VoIP providers, Skype, and attached SIP phones across multiple OBi's and OBiON Apps. It all works extremely well as long as I don't enable Call Forward or Do Not Disturb. A great deal of my configuration obviously relies on the use of InboundCallRoute rules.
If I simply enable Do Not Disturb to temporarily silence incoming calls to the phones, much of my configuration fails as it disables all InboundCallRoute processing on the SP1, SP2, and LINE Port trunks.
When I'm away, I like having the ability to call into the OBi and have access to all these capabilities. But if I also enable Call Forwarding to receive all incoming calls on my cell phone, I can't even reach the Auto Attendant because all InboundCallRoute processing on the SP1, SP2, and LINE Port trunks ceases to function. While Call Forwarding is enabled, I also lose many of my in-house capabilities.
The sad part is it doesn't need to be this way. The problem is terribly obvious and extremely easy to remedy with a very minor shuffling of a few lines of code in the OBi firmware. I've had numerous email exchanges with Obihai about this issue. They are very aware of it and have not expressed any technical reasons for not correcting it.
