Help on Asterisk -> Obi110 #1 -> Obi110 #2 -> pstn setup
MichiganTelephone:
I agree this is a VERY serious bug, and needs to be fixed. But you said that you've "been informed by Obihai they will not be fixing this bug." I can't imagine why they would take that position, which seems totally unreasonable on the face of it. How did they respond to you, via e-mail? Did they offer ANY explanation as to why they would not fix it?
This especially appears to have bad implications for those using an OBi110 as a gateway between a PSTN line and an Asterisk server, because if you're describing the situation accurately then setting the phone port to Do Not Disturb or Call Forward All would block incoming calls on the Line port from reaching the Asterisk server. That is most definitely unacceptable behavior.
RonR:
This problem is easily reproduced. Simply set one or more rules on the SP1, SP2, or LINE Port InboundCallRoute(s) and then enable Do Not Disturb (*78) or Call Forward All (*72). You'll find those rules are ignored.
Clearly, features like DND and CFA should only be acted upon for calls actually arriving at the PHONE Port. That's the way the OBiTALK Service trunk behaves and all the other trunks should behave identically. There's no reason to treat SP1/SP2/LI differently.
MichiganTelephone:
Still no comment from Obihai Support???
ShermanObi:
Hi everyone,
Over the past several weeks, we have discussed and thought about the issue described in this post. We do see that the current implementation could be enhanced -- and of course it will be enhanced for various other applications. Understanding the DND & Call Fwd All limitation, the functionality in the current implementation should allow the OBi to perform well for this application. But as I said, we are considering this concern about the current implementation and are open to enhancing the current functionality.
Thank you for your support!
RonR:
Sherman,
You continue to describe this problem as a need for some new functionality, capability, or enhancement. That's simply not the case. Absolutely nothing new is needed. Absolutely nothing needs to be enhanced.
The logic on the SP1, SP2, and LINE Port trunks is currently:
Do Not Disturb enabled? Yes -> Ignore Call / End of Processing
|
V
Call Forward All Enabled? Yes -> Forward Call / End of Processing
|
V
Process InboundCallRoute
|
V
Ring OBi Phone
If Do Not Disturb or Call Forward All is enabled, the InboundCallRoute doesn't get processed.
All that's needed to fix this problem is a trivial change to the order in which these operations are performed:
Process InboundCallRoute
|
V
Do Not Disturb enabled? Yes -> Ignore Call / End of Processing
|
V
Call Forward All Enabled? Yes -> Forward Call / End of Processing
|
V
Ring OBi Phone
The OBiTALK trunk performs these operations in the correct (second) order and consequently has no problem. Simply follow the same order on the SP1, SP2, and LINE Port trunks and the problem is solved. The change can't possibly take more than a few minutes to accomplish.
Why is there so much reluctance to correct this problem? Currently, numerous tasks that people are accomplishing with the OBi cease to function if Do Not Disturb or Call Forward All is enabled. Moving the placement of a single operation so that it matches the OBiTALK order allows all these tasks to continue working instead of being terminated. It's such an obviously devastating problem that's so simple to fix, it's hard to understand why we're even having this discussion.
Navigation
[0] Message Index
[#] Next page
[*] Previous page