OBiTALK Community

General Support => Day-to-Day Use => Topic started by: ofermend on April 04, 2012, 07:45:42 AM

Title: Routing dependent on DND
Post by: ofermend on April 04, 2012, 07:45:42 AM
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
Title: Re: Routing dependent on DND
Post by: RonR on April 04, 2012, 08:41:57 AM
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.
Title: Re: Routing dependent on DND
Post by: Everton on April 04, 2012, 09:31:44 AM
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.
Title: Re: Routing dependent on DND
Post by: ofermend on April 08, 2012, 04:58:15 PM
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?
Title: Re: Routing dependent on DND
Post by: RonR on April 08, 2012, 05:40:14 PM
Quote from: ofermend on April 08, 2012, 04:58:15 PM
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.
Title: Re: Routing dependent on DND
Post by: Stewart on April 08, 2012, 09:11:18 PM
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).
Title: Re: Routing dependent on DND
Post by: RonR on April 08, 2012, 09:30:06 PM
Quote from: Stewart on April 08, 2012, 09:11:18 PM
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).
Title: Re: Routing dependent on DND
Post by: Stewart on April 08, 2012, 09:38:42 PM
Quote from: RonR on April 08, 2012, 09:30:06 PM
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?
Title: Re: Routing dependent on DND
Post by: RonR on April 08, 2012, 10:01:58 PM
Quote from: Stewart on April 08, 2012, 09:38:42 PM
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.