Star Codes - Need to Restart Obi11 to make them 'take'

[TwoFast]

Hi all,

I just got my unit two days ago. While using the star codes to block/unblock anonymous calls, I am finding that they only 'take' if I restart the Obi110. This is the case even though I am doing this from the phone, and not from the Obi configuration web page.

Has anyone else seen this behavior? It makes no sense to have star codes you can send from the handset if you have to reboot the device to make them stick.

I'm using Google Voice, one line only.

Thanks!

[obi-support2]

TwoFast,

I want to confirm that a reboot is NOT necessary after you enable AnonymousCallBlock feature using *code (by default, to block is *77; to unblock is *87).

I have just tried that for about 10 times, using both version 1.2.0.2101 and 1.1.0.1892, both seems to be working as expected. I tried calling the unit's SP2 and OBiTALK services, the phone rings if I show my caller-id number, but will get busy tone if I hide my caller-id number.

Also tried *87 to unblock it again; and it too does not need to reboot the unit to take effect.

After you dial *77 (or *87) from the phone, the unit should return dial tone immediately; this is the indication that the * code you entered is valid.

If you can access the device's web page, you can also check under SP1/SP2/LINE/OBiTALK Service - CallingFeatures, that the AnonymousCallBlockEnable parameter is checked after you dial *77, and unchecked after you dial *87, and no reboot is needed.

Please try it out a few times again and see if this works consistently.

To other forum members reading this thread, please let us know if you can duplicate this problem also. Thanks everyone.

[TwoFast]

Hi,

Thanks for your reply.

I've confirmed this IS the case (on mine, at least). Anonymous Call Block and <UNDO> Anonynous Call Block DOES require a restart for me to make it 'take'.

Also, DND and <UNDO> DND also require a restart to make it 'take'.

*67 (One-timne Caller ID Block) does NOT work at all.

I've tried these all (3) times again today, just to be sure I'm not crazy!!

I'm going to try and do a system reset... I'll provide an update later.

Thanks!

--TwoFast

[TwoFast]

Hi,

Al of the above is still true even after a reset, and even completely deleting my Obi from the Portal. Also one weird thing is when the caller ID is blocked, the calling phone rings 4x and goes into VM, but the called phone/OBI never rings.

According to what I've read and what was posted above, the calling phone should receive a fast busy signal...

[TwoFast]

...and it does return a dial tone immediately after dialing the star codes...

[Gogyroswin]

I have the same issue.  My star commands, this one was call forward all *72, will not work unless I reboot my device.  I have done this numerous times and each change needed a reboot.

[obi-support2]

TwoFast,

- *77 should be dialed on the called OBi to block an incoming call with caller-id blocked
- The called OBi does not know how to forward an anonymous call to VM after 4 rings

From your last statement,... "when the caller ID is blocked, the calling phone rings 4x and goes into VM, but the called phone/OBI never rings", I suspect your call is forwarded to VM by your service provider.

Question:
- What voice service are you using on the called OBi that you want anonymous call blocked?
  Is it Google Voice or someone else?

Thank you.

[RonR]

obi-support2,

There's definitely a bug with *72 not working until after a reboot.  It's 100% reproducible here.

*62 works fine without a reboot.

I haven't tried any of the others, but I suspect the reports are true.

It may be related to having PrimaryLine = Trunk Group 1.


After further testing...

It doesn't appear to be related to Trunk Group 1 after all.  Although *72 enables CallForwardUnconditional on all ports with the desired number, it just plain doesn't work until the OBi is rebooted, regardless of the PrimaryLine setting.

Also, if PrimaryLine = SP1 Service, the forwarding number is set to GT1(...) instead of SP1(...).  If GT1 is a valid Trunk Name, it needs to be documented.  PrimaryLine = SP2 Service sets the forwarding number to SP2(...) not GT2(...).  LINE and Trunk Group 1 set LI1(...) and TG1(...) as expected.

[RonR]

obi-support2,

The problem with *72 requiring a reboot to be effective appears to be fixed in 1.2.1 (Build: 2103).

Would you please confirm that you were able to reproduce the problem and actually fixed it, or is this change in behavior simply a fluke?

P.S.  If PrimaryLine = SP1 Service, the forwarding number is still set to GT1(...) instead of SP1(...).

Thanks,

Ron

[RonR]

Any chance of getting a reply from the Obihai folks regarding the previous two posts?

Thanks,

Ron

[RonR]

Is it really asking that much to get a reply?

[Gogyroswin]

Ron,

I have downloaded the latest update (1.2.1, Build: 2103) and I am still having the same issue.  When trying to activating *72/*73 I have to reboot my Obi in order for it to work.

[RonR]

I had this gut feeling that the change of behavior I noticed wasn't due to any specific action on Obihai's part, which is why I've been trying to get a response from them.  Problems that go away by themselves tend to come back in the future.

For some reason, Obihai is very fearful of discussing problems openly, especially when they don't already have them solved and a fix immediately available.  They really need to get over this and be more forthcoming with information.

[RonR]

Ron,

I have downloaded the latest update (1.2.1, Build: 2103) and I am still having the same issue.  When trying to activating *72/*73 I have to reboot my Obi in order for it to work.

Gogyroswin,

I've just discovered that I now have the problem with Do Not Disturb (DND : *78/*79).  Each requires a reboot to be effective.  There is definitely a problem with the processing of Star Code's.

[lhm.]

I just tested *78 & *79 both work as they should without rebooting. It may be something somewhere in your configuration. I do not use Obi Talk

Obi100  FW1.2.1 (Build: 2103) Manual Configuration.

[obi-support2]

After more investigation, we found out this problem will occur for calls on Google Voice lines
(that is SP1 or SP2 configured for Google Voice), and you do need a reboot for those star codes to
take effect.

We do not see this problem for calls on other lines (SP1/2 configured for SIP, LINE Port, and OBiTALK Service). The only exception is when you configure call forward number to go out on a Google Voice line (*72 for example). For these cases, it will require a reboot regardless the line type where the incoming calls are on.


We will address these problems in a later firmware.
Thank you very much for notifying us about this problem.

[electriccat]

Got an ETA on the GV/starcode issue fix? sure is handy when the baby is sleeping.