Routing dependent on DND

[ofermend]

Is it possible to have a routing rule that looks at whether DND is enabled or not?
For example, if DND is enabled route to my GV number; if it's disabled then route to the attached phone

[RonR]

There is no ability to test DND and make routing decisions based on its current state.  In fact, there is a serious design flaw in the OBi such that, if DND is enabled, all call routing done in the InboundCallRoute is disabled/bypassed and ceases to function.

[Everton]

If they incoming calls are via your GV Number, couldn't what you are requesting be done through the GV Portal?  So, if DND is enable on the GV Portal, the calls will not ring your OBi attached phone and if disable, it will pass through to your analog phone.

[ofermend]

Thanks for the response.
I was hoping this can be done for the PSTN line, and I guess it's not possible at the moment.
Is there any known ETA for when this might be fixed?

[RonR]

I was hoping this can be done for the PSTN line, and I guess it's not possible at the moment.
Is there any known ETA for when this might be fixed?

Obihai has stated that they intentionally included this limitation in the firmware of the current products.

[Stewart]

DND is just the name of a feature (that doesn't do what you want).  What are your actual requirements?

For example, suppose you wish to dial (from a phone attached to the OBi) a code that causes subsequent incoming calls to not ring the phone but be sent to voicemail, and have another code that restores the original behavior.  Change Star Code Profile A -> Code7 to *72, Cfwd All, set($Cfa,1) Then, manually set CallForwardUnconditionalNumber to the number of a voicemail service.  If you want your main GV account to get the voicemail, you will need to send the call via another service.  Once set up, you would dial *72 to enable the feature and *73 to turn it off.  If you want the original called ID to be passed to the voicemail service, you will need to send the call via a provider that permits spoofing within the OBi's limitations (Voxbeam, Flowroute).

[RonR]

Once set up, you would dial *72 to enable the feature and *73 to turn it off.

Just be aware that ALL InboundCallRoute rules on SP1, SP2, and the LINE Port will be totally non-functional while *72 is in effect (same as DND).

[Stewart]

Just be aware that ALL InboundCallRoute rules on SP1, SP2, and the LINE Port will be totally non-functional while *72 is in effect (same as DND).

I haven't tried this, but the admin guide says that $CFA is trunk specific.  Would a rule of
*72, Cfwd All, set(LI1($Cfa),1)
reroute Line calls to VM but leave the inbound routing for other trunks alone?

[RonR]

I haven't tried this, but the admin guide says that $CFA is trunk specific.  Would a rule of
*72, Cfwd All, set(LI1($Cfa),1)
reroute Line calls to VM but leave the inbound routing for other trunks alone?

CFA/DND is controlled on a per trunk basis and only affects the assocated trunk's InboundCallRoute.  The design flaw in the OBi is particularly problematic on an SPx that's used for SIP and utilizes InboundCallRoute rules for IP phone support and the like, but there are many other scenarios on any trunk (for example, calling into your Google Voice account from your cell phone to use the Auto Attendant).  These finctions get totally disabled with no reason for doing so and the fix is trivial, but Obihai refuses to change it.