On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

InboundCallRoute vs Calling Features Evaluation Order Problem

Started by RonR, June 04, 2011, 06:18:07 PM

Previous topic - Next topic


The OBiTALK Service trunk evaluates the InboundCallRoute BEFORE checking calling features such as Call Forwarding, Do Not Disturb, and (presumably) Block Anonymous Calls.  This is the correct sequencing.

All other trunks evaluate the InboundCallRoute AFTER checking calling features such as Call Forwarding, Do Not Disturb, and (presumably) Block Anonymous Calls.  This is disastrous.  This breaks all kinds of OBi features that rely on InboundCallRoute processing when any of the these calling features are enabled.  I can't think of a good reason for this sequencing.

For example, I route incoming calls from my cell phone to the Auto Attendant so I can make outbound calls through Google Voice, my VoIP Provider, or OBiTALK when I'm away from home.  I also forward all incoming calls (*72) to my cell phone when I'm away from home.  Enabling call forwarding breaks my ability to call into the Auto Attendant since the call is immediately forwarded right back out to my cell phone.

My additional telephone attached to the OBi via a PAP2 which uses the InboundCallRoute on SP2 also ceases to function properly when calls are forwarded or Do Not Disturb is in effect.  No matter what number I call, I'm forwarded to the forwarding number since the InboundCallRoute is not processed.

There are numerous other scenarios that use the InboundCallRoute (just as the OBiTALK Service does) that fail as soon as these calling features are enabled.

Since these calling features are controlled by Star Codes initiated at the PHONE Port only and apply to calls destined for the PHONE Port only, these calling features should only be checked when a {ph} InboundCallRoute rule is processed on any trunk.



Would you please comment on this issue and whether you intend to address it in any way.  This appears to be a serious design or implementation flaw.  It's currently imposing considerable limitations on my intended use of the OBi110.

Please respond.


It's very disappointing to see obi-support2, ShermanObi, OBi-Guru, and OBiSupport logging into this forum multiple times a day, yet nobody from Obihai will respond to this thread or the thread regarding DTMF problems.