Issues with Obi-to-Obi dialing (**9+9-digit-Obi#)

[robbie]

I've setup two Obi110 devices and registered them successfully on Obitalk.com. I've also setup Google Voice on the two Obi110 devices one in my house and one at my sister's house. The Google Voice works perfectly.

However, if I try to call my sister's device using **9-<her Obi110's 9-digit #>, I get this recording:
"No Call Route Available to Complete This Call"

She tried calling me using my Obi110 device's 9-digit # prefixed with the **9 code and got the same message! Is this recording from Google Voice or is it from Obitalk/Obi110 device? What am I missing? Again, there's absolutely no issues with Google Voice, Google Voice works flawlessly. Also, I don't have anything connected in the Telco ports on the Obi110 devices.

I bought the Obi devices primarily for the **9 direct-dial feature just in case Google Voice starts charging sometime in the future, but this direct Obi-to-Obi using the**9+9-digit Obi# feature dosn't seem to work. Is it a case of either or, ie, you can only have Google Voice working and not the Obi-to-Obi calling or the other way round?

Thanks for all your help in advance. All suggestions/pointers gratefully accepted.

Best Regards

Robbie

[RonR]

The message you're hearing is coming from the OBi.

You should be able to call each other's OBi's without registering them on the OBiTALK Web Portal and without configuring them in any way.  IOW, nothing is required to make OBi-to-OBi calls straight out of the box.  You should also be able to call the echo test at : **9 222 222 222

1. Log directly into the OBi using the IP address returned by dialing ***1 (userid/passwd = admin/admin) and verify that the OBiTALK Service Status at the bottom of the System Status page reports:

Status     Normal (User Mode)

2. Then navigate to each of the following settings and verify that the Default box is checked:

Physical Interfaces -> PHONE Port -> DigitMap
Physical Interfaces -> PHONE Port -> OutboundCallRoute
Voice Services -> OBiTALK Service -> DigitMap

[robbie]

Hi RonR

Thanks for the suggestions. I had registered the two Obi110s using the portal Obitalk.com/obinet and also used that portal to configure Google Voice on the devices, so I assume the portal then updated the firmware settings on two Obi110s I bought. In any case, I followed your suggestion and accessed the devices directly using their respective IP addresses (with the login: admin/<pwd> I had setup in the Obitalk portal) since I now have both devices connected to my home router.

I found that the default check box for the OutboundCallRoute setting was unchecked on both devices, so I checked it and rebooted them. (Physical Interfaces -> PHONE Port -> OutboundCallRoute)

Unfortunately, I still get the same recording when I pick up the phone attached to the Ob110 "Phone" port on both the devices and dial **9+9-digit Obi#!! Not sure what the issue is? BTW, the **9-222-222-222 echo test also gives me the same annoying announcement in a male voice: "No Call Route Available to Complete This Call"

Again, thanks for any suggestions/pointers on fixing this issue or getting the right settings into the Obi110 box or onto the portal Obitalk.com/obinet using my portal account login where the two devices are registered.
I should report that I also added a bunch of phone #s under the Circle of Trust, none of which I'm guessing should affect the direct Obi-to-Obi dialing capability.

I should repeat that the two Google Voice #s I setup on the Obi110s continue to work flawlessly even though the direct dial **9 feature is crippled on both devices.

Best,

Robbie

[RonR]

If you want to make changes to the OBi directly, you must disable Auto Provisioning in the OBi or the OBiTALK Web Portal will overwrite your changes:

System Management -> Auto Provisioning -> ITSP Provisioning -> Method : Disabled

You'll probably find when you go back in that the Default box is no longer checked and the OutboundCallRoute is back to it's previous value.  Please copy the entire value (ctrl-A followed by ctrl-C) before checking the Default box and post the contents here so I can see what change the OBiTALK Web Portal is making.

[robbie]

Indeed, it appears the web portal is overriding the manual checkbox for Default for the OutboundCallRoute attribute. As you say, when I went back in there now, the Default box for OutboundCallRoute is unchecked. Here is the string that is in there now before I re-check it:

---
{911:sp1},{([1-9]x?*(Mpli)):pp},{(&lt;#:&gt;|911):li},{**0:aa},{***:aa2},{(&lt;**1:&gt;(Msp1)):sp1},{(&lt;**2:&gt;(Msp2)):sp2},{(&lt;**8:&gt;(Mli)):li},{(&lt;**9:&gt;(Mpp)):pp},{(Mpli):pli}
---

Ok, I disabled the Auto Provisioning attribute under System Management as you suggested and and went into the Phone Port menu under Physical Interfaces and re-checked the box under Default for the OutboundCallRoute attribute and "Submit"ted the changes and rebooted the Obi110. Guess what, the System MAnagement attribute has been changed to Disabled, however when I go into Phone Port under Physical Interfaces, its been over-ridded again and the box under Default for the attribute OutboundCallRoute is again unchecked!! It appears, disabling the Auto Provisioning attribute under System Management doesn't seem to prevent the device from  being over-written by the portal. Very strange.

Any more suggestions or things to try?

Thx

robbie

[Stewart]

Confirm that both ITSP Provisioning->Method and OBiTalk Provisioning->Method are set to Disabled.  Save settings.  Reboot the device, re-enter the OutboundCallRoute, save and reboot again.

[RonR]

---
{911:sp1},{([1-9]x?*(Mpli)):pp},{(&lt;#:&gt;|911):li},{**0:aa},{***:aa2},{(&lt;**1:&gt;(Msp1)):sp1},{(&lt;**2:&gt;(Msp2)):sp2},{(&lt;**8:&gt;(Mli)):li},{(&lt;**9:&gt;(Mpp)):pp},{(Mpli):pli}
---

It appears there's a nasty bug in OBiTALK Web Portal and/or the OBi firmware that's generating a corrupted OutboundCallRoute.  Another user is experencing the same problem:

http://www.obitalk.com/forum/index.php?topic=1747.msg11355#msg11355

If you disable Auto Provisioning and check the OutboundCallRoute Default box in the OBi, your problem will go away.

[infin8loop]

Since this thread mentions Auto Provisioning more than once, I'm going to post this observation/question here.

Up until yesterday my OBi110 was configured locally with the following two settings:

System Management --> Auto Provisioning --> ITSP Provisioning --> Method : System Start (Default check box checked)  (I don't recall ever specifically changing this setting)

System Management --> Auto Provisioning -->  OBiTalk Provisioning --> Method : Disabled (Default check box not checked but Disabled appears to be the default when the check box is checked).  I believe but am not certain this was Enabled before  I manually Disabled it locally and did not check the unchecked Default check box because I was concerned that a subsequent release might not default to Disabled.

Perhaps the answer is in the Admin Guide and I'm just not seeing or understanding it.  The bottom line is my local settings (done thorough the local IP address)  were NOT being overlayed.  Example:  The OBiTalk portal isn't aware that I have voip.ms on SP2 since I added it locally AFTER I Disabled OBiTalk Provisioning mentioned above months ago.  Yesterday I disabled the ITSP Provisioning as well just to be safe because I keep seeing mention of it as well.  The OBi110 is registered on OBiTalk but I never used the OBiTalk Expert Configuration it provides.  I did however initially configure Google Voice on SP1 using the OBiTalk portal basic configuration wizard before I Disabled the OBiTalk Provisioning.  Again, until yesterday I had only OBiTalk Provisioning Disabled and local settings were not being overlayed (at least any settings that I've looked at). I've been "safe" for months or at least thought I was. Are these two settings controlling different things?  Is it plausible the ITSP Provisioning applies settings from the OBiTalk Expert Configuration (refers to a tftp://$dhcpopt66/$DM.xml) but since I never used it I was ok?  Every time I think I have a handle on this OBi, the handle falls off for some reason (grin).  Does the OBi have undocumented TFTP access?  I know I'm over thinking all this, but I like to fully understand the technology.

[RonR]

infin8loop,

OBi provisioning is another area that is virtually undocumented.  Prior to firmware v1.3, there was only one flavor of provisioning, but now there's two (ITSP and OBiTALK).  The OBiTALK Web Portal obviously uses the ITSP flavor and can be disabled.

As we've previously discussed, from my own experience, there's no way to stop the Obihai folks from peering into and/or making changes to the internals of your OBi if they have a mind to.  Not registering an OBi, setting secret passwords, etc. does not make the OBi secure.

[infin8loop]

The OBiTALK Web Portal obviously uses the ITSP flavor and can be disabled.

RonR,
Thanks for the reply.  As of yesterday, I have BOTH flavors Disabled. And, yes, I fully understand neither setting disables their ability to access the OBi if they want to.  Let's just hope they don't want to.   

[robbie]

I'm happy to report that on one of the Obi110 devices I was able to get the OutboundCallRoute box stay checked after reboot but no success on the other box. Very strange. This is after ITSP and the ObiTalk provisioning being disabled on both boxes.

Will report back if I'm successful tweaking anything else. One of these boxes will be shipped overseas shortly and I'm really hoping the Obi-to-Obi calling works as a backup to GoogleVoice's plans to start charging sometime next year or the year after.

robbie

[RonR]

robbie,

You might try the following steps:

1. Delete all devices from the OBiTALK Web Portal (do not re-enter them).

2. System Management -> Device Update -> Backup Configuration (Use OBi Version : checked)

3. System Management -> Device Update -> Reset Configuration

4. System Management -> Device Update -> Restore Configuration

5. System Management -> Auto Provisioning -> ITSP Provisioning -> Method: Disabled
   System Management -> Auto Provisioning -> OBiTALK Provisioning -> Method: Disabled

6. Re-enter all passwords (they're not saved in a backup file).

7. Double-check all configuration settings and correct as necessary