News:

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

Main Menu

[SOLVED] Can't Call OBiTALK Test Number

Started by longcliff, October 21, 2011, 12:54:41 PM

Previous topic - Next topic

longcliff

For some reason, when I use the telephone connected to the OBi110 to call the Test Number **9 222 222 222, I get the following message, "There is no call route available to complete your call".  What is strange about this is everything else seems to be working fine, as detailed below:

My OBi Dashboard shows the OBi110 is online, and in Device Configuration my Google voice account is shown as 'connected' under service provider 1.  I can successfully make and receive calls from the telephone connected to the OBi110.  When somebody calls me, if I don't pick up the phone, they can leave a message on my google voice account.  When I call my google voice number, I can check my messages and change my settings (greeting, name, etc.)

Does anybody have any suggestions for making the test number (**9 222 222 222) work?  I am very new to this, so I may be making a novice mistake.

I wonder if I need to change something in my DSL modem?  I have century link DSL, and I had to do something in the modem configuration to get xbox live to work.

RonR

If Google Voice is working, your Internet connection is obviously functioning.

Log into your OBi directly using the IP address returned by dialing ***1 and check the OBiTALK Service Status at the bottom of the System Status page.  It should read:

Status     Normal (User Mode)

yhfung

You may consider to use static IP rather dynamic IP via DHCP.

YH
Hong Kong and China OBi Users Group
www.telecom-cafe.com

RonR

Quote from: yhfung on October 21, 2011, 09:20:01 PM
You may consider to use static IP rather dynamic IP via DHCP.

Why?  There shouldn't be any advantage to using a static IP address over a DHCP assigned IP address.  How will using a static IP address make cals to echo test or any other OBiTALK number more likely to succeed?

longcliff

Quote from: RonR on October 21, 2011, 01:09:57 PM
If Google Voice is working, your Internet connection is obviously functioning.

Log into your OBi directly using the IP address returned by dialing ***1 and check the OBiTALK Service Status at the bottom of the System Status page.  It should read:

Status     Normal (User Mode)


I logged onto the OBi and checked the OBiTALK Service Status.  It says "Normal (User Mode)".

I'm going to try going with a static IP and setting up 'port forwarding' in my century link DSL modem (westell 7500).  I really don't know what I'm doing here, but that's what was required to get my xbox live to work through the westell 7500.

Any advice is appreciated.

RonR

Quote from: longcliff on October 22, 2011, 11:04:05 AM
I logged onto the OBi and checked the OBiTALK Service Status.  It says "Normal (User Mode)".

Then you should be able to call : **9 222 222 222

Check to make sure the following settings are at Default in the OBi:

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

OBiSupport

Please try to disable the firewall in your westell router.
check "No Security (None)"

This is also described in our FAQ:
http://www.obihai.com/docs/OBiFAQ.html#09

-Obihai Support Team

Gabi

Quote from: RonR on October 22, 2011, 11:11:26 AM
Quote from: longcliff on October 22, 2011, 11:04:05 AM
I logged onto the OBi and checked the OBiTALK Service Status.  It says "Normal (User Mode)".

Then you should be able to call : **9 222 222 222

Check to make sure the following settings are at Default in the OBi:

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


Making those changes worked it for me.
Thank you Ron.

RonR

Quote from: longcliff on October 22, 2011, 11:04:05 AM
I logged onto the OBi and checked the OBiTALK Service Status.  It says "Normal (User Mode)".

I'm going to try going with a static IP and setting up 'port forwarding' in my century link DSL modem (westell 7500).  I really don't know what I'm doing here, but that's what was required to get my xbox live to work through the westell 7500.

The fact that you're successfully connected to the OBiTALK voice server and can make/receive Google Voice calls pretty much says you don't have an IP address, Internet connectivity, port forwarding, or firewall problem.

Once you're showing connected to a particular service, "There is no call route available to complete your call" errors are almost always DigitMap/OutboundCallRoute configuration problems.

longcliff

Quote from: RonR on October 22, 2011, 11:11:26 AM
Quote from: longcliff on October 22, 2011, 11:04:05 AM
I logged onto the OBi and checked the OBiTALK Service Status.  It says "Normal (User Mode)".

Then you should be able to call : **9 222 222 222

Check to make sure the following settings are at Default in the OBi:

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


Ok, I'm getting closer.  Under Physical Interfaces -> PHONE Port -> Outbound Call Route, I did not have the default setting.  This is what I have:

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

If I change it to default (by marking the checkbox), submitting changes, and rebooting the system, I can call **9 222 222 222 and it works.  But, then the system reboots again (without being told to) and changes the Outbound Call Route back to the non-default setting above.  Then **9 222 222 222 stops working.

The other non-default setting I have is Physical Interfaces -> PHONE Port -> PrimaryLine, which is set to 'SP1 service'.

Does anybody know why my default setting for OutboundCallRoute is being changed?




Stewart

#10
While I don't see anything obviously wrong with the OutboundCallRoute, it appears that you have changed it (for 911) in the portal and still have updates from the portal enabled, which are overwriting your changes.

If you want to configure the OBi manually (from its web interface), you must set the method (in System Management->Auto Provisioning) for both ITSP Provisioning and OBiTalk Provisioning to Disabled.  Save and reboot.  Then, you should be able to change OutboundCallRoute as desired.

However, whatever you do, be sure that you end up with a configuration that works properly for 911.  If at all uncertain, after calling your police non-emergency number and asking permission, make a test call to 911.  Immediately tell them that you do not have an emergency and are just testing.  Don't hang up until they have confirmed that, or you'll get a visit from the cops.  During your test call, confirm that you have reached the proper PSAP and they show your correct physical address.

Edit:  I just noticed that you are directing 911 to SP1, but you also state that you have Google Voice for SP1.  GV does not offer 911 service!  If you have another provider that does offer 911, you should be sending emergency calls there.

longcliff

Quote from: Stewart on October 23, 2011, 05:01:39 AM
While I don't see anything obviously wrong with the OutboundCallRoute, it appears that you have changed it (for 911) in the portal and still have updates from the portal enabled, which are overwriting your changes.

If you want to configure the OBi manually (from its web interface), you must set the method (in System Management->Auto Provisioning) for both ITSP Provisioning and OBiTalk Provisioning to Disabled.  Save and reboot.  Then, you should be able to change OutboundCallRoute as desired.

However, whatever you do, be sure that you end up with a configuration that works properly for 911.  If at all uncertain, after calling your police non-emergency number and asking permission, make a test call to 911.  Immediately tell them that you do not have an emergency and are just testing.  Don't hang up until they have confirmed that, or you'll get a visit from the cops.  During your test call, confirm that you have reached the proper PSAP and they show your correct physical address.

Edit:  I just noticed that you are directing 911 to SP1, but you also state that you have Google Voice for SP1.  GV does not offer 911 service!  If you have another provider that does offer 911, you should be sending emergency calls there.

I have a cell phone for 911, so I was not trying to direct 911 to Google Voice (SP1).

Do you know where I might have told the OBi to direct 911 to SP1?  When I use OBiTALK Dashboard to configure my Google Voice Account (SP1), under the entry for 'Use this service for emergency 911 calls' it simply has a circle with a line through it and a note saying that google voice is not capable of placing or receiving emergency calls.  There is no way to select (or de-select) the 911 option for google voice.

longcliff

Ok, I think I understand how provisioning works now.  Rather than disable auto provisioning, I went into the OBiTALK Dashboard 'OBi Expert Configuration' and set Physical Interfaces -> Phone -> OutBoundCallRoute to 'Device Default'  Then when the OBi device 'auto provisions' at startup, it takes the settings from expert configuration and applies them to the OBi device (which is why my previous changes from the web interface were being overwritten.)

To confirm this, I logged onto the OBi from the web interface, and sure enough, the OutBoundCallRoute is now at the default selection.

Also, I can make calls through google voice (sp1) and also call the OBiTALK test number **9 222 222 222.

Thanks for all the help!

I still wish I knew why my OutBoundCallRoute had been changed from default in the first place.




Stewart

Quote from: longcliff on October 23, 2011, 06:57:29 AMI still wish I knew why my OutBoundCallRoute had been changed from default in the first place.
Sorry, that's well beyond my knowledge of the OBi system.  Perhaps RonR or Obi support knows what may have happened.

RonR

Quote from: longcliff on October 23, 2011, 03:58:39 AM
Under Physical Interfaces -> PHONE Port -> Outbound Call Route, I did not have the default setting.  This is what I have:

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

The OutboundCallRoute should be:

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

As can clearly be seen, there is a nasty bug in OBiTALK Web Protal and/or OBi firmware that's resulting in a highly corrupted OutboundCallRoute containing HTML escape sequences (&lt;/&gt;) when Auto Provisioning is used to configure this setting.  This leaves all **1/**2/**8/**9 prefixes unusable.

Everton

Quote from: RonR on October 23, 2011, 09:24:38 AM

As can clearly be seen, there is a nasty bug in OBiTALK Web Protal and/or OBi firmware that's resulting in a highly corrupted OutboundCallRoute containing HTML escape sequences (&lt;/&gt;) when Auto Provisioning is used to configure this setting.  This leaves all **1/**2/**8/**9 prefixes unusable.

I use the OBiTALK Web Portal with the current and previous version of the OBi Firmware and never got those corrupted OutboundCallRoute data.  Why is it happening to some users and not others?  Could it be associated with an incompatible Browser (I use Chrome exclusively)?

RonR

Quote from: Everton on October 23, 2011, 10:10:35 AM
I use the OBiTALK Web Portal with the current and previous version of the OBi Firmware and never got those corrupted OutboundCallRoute data.

Is the OBiTALK Web Portal configuring your OutboundCallRoute?  Try unchecking the OutboundCallRoute Default box in the OBiTALK Web Portal and see if you get a corrupted OutboundCallRoute in your OBi.

Everton

It is unchecked for the "OutboundCallRoute Default box"  As I said, I do not used the direct web portal, even though I have direct direct assess to the OBi110 remotely.  I manage the Network and OBi110 for a friend and ALL changes/enhancements (including changes to "OutboundCallRoute") have been done via the OBiTALK Web Portal.  Have you been able to reproduce this behavior recently?


Quote from: RonR on October 23, 2011, 10:17:58 AM
Quote from: Everton on October 23, 2011, 10:10:35 AM
I use the OBiTALK Web Portal with the current and previous version of the OBi Firmware and never got those corrupted OutboundCallRoute data.

Is the OBiTALK Web Portal configuring your OutboundCallRoute?  Try unchecking the OutboundCallRoute Default box in the OBiTALK Web Portal and see if you get a corrupted OutboundCallRoute in your OBi.


RonR

Quote from: Everton on October 23, 2011, 10:27:33 AM
Have you been able to reproduce this behavior recently?

I never use the OBiTALK Web Portal, in order to avoid this sort of problem.

Neither of the two users experiencing this problem should have had an OutboundCallRoute that was other than Default.  Both had an extra/unwanted/unrequested {911:sp1} rule forced onto the beginning of their OutboundCallRoute (overriding the normal 911 call processing).  Checking the Default box in the OBi corrected the problem.  It's pretty clear the OutboundCallRoute was incorrect as generated by the OBiTALK Web Portal.  There's never been a case before where an OutboundCallRoute value that was copy/pasted from an OBi to a forum message resulted in < and > being shown with HTML escaping.  Based on all this, it certainly appears something is awry.

RonR

Quote from: Everton on October 23, 2011, 10:27:33 AM
Have you been able to reproduce this behavior recently?

I pulled a new OBi from the shelf and used the OBiTALK Web Portal to configure it.  The bug is reproducible:

Physical Interfaces -> PHONE Port -> OutboundCallRoute:

{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}