3.0.1 (4303) Can No Longer Receive Calls
SteveInWA:
Quote from: carl on March 03, 2014, 10:34:39 am
Quote from: Mango on March 03, 2014, 10:30:50 am
Guys, remember that OBiTALK can update your firmware automatically, even if Automatic Firmware Update is disabled.
...I may have to use my spare credit card and order a IP phone system and say farewell to this hassle.
SIP telephony is simply complex. I have had an equivalent level of "hassle" trying to get ATAs from brand "C", Brand "L", and brand "G" to work. Firmware releases sometimes fix one thing and break another thing. Documentation ranges from incredibly obtuse to downright absent. The target market is to telephone service providers and resellers who specialize in installing the equipment, not to average end users. Obihai has at least done what very few other equipment providers have tried: made a (relatively!) user-friendly web portal to try to shield the end user from the ugly complexity underneath.
I do also have a Gigaset C610A IP phone system, and its setup menus are pretty clear and easy to use. It works great with Callcentric. It's easy to set up an OBi box, for example, with separate CC extension numbers from the Gigaset, and thus have them all place or receive calls using the same account.
Tobi:
gderf, all your steps used here. A nice little class for me. Next, I'm trying to set up VestaLink for a test. Something about my data input is glitchy. VestaLink isn't registering.
I have a feeling that it was using the VestaLink automatic OBI setup tool that killed GoogleVoice. But, the issue was confused by the firmware update issue at the same time. Then, someone here wrote of the unlikeliness of the firmware change messing with GoogleVoice.
MikeHObi:
I am disappointed in Obi in that they are stating "some providers" but giving no indication to which ones that might be. When setting up and obi SP port you get a list of providers that the wizard will then setup all the various parameters for that provider. I would hope that a list of providers this does or does not work with from that provider list would be available. Since that provider list is one that Obi maintains.
My experience over the weekend was that neither Callcentric or Anveo supported this. Has that changed?
gderf:
You may have missed the post, but the providers that were broken weren't explicitly named. However, the difference between those that were broken and those that weren't was explained.
If you used a rule like this X_InboundCallRoute -> {>[Your Account User ID]:ph} (AKA as the "Oleg method" to stop SIP scanners) then the contents of [Your Account User ID] was the potential culprit. This was exasperated by the fact that the OBiTALK service, if used, pushed this syntax to your OBi. If you had configured your SPs manually (didn't use OBiTALK), and didn't use the Oleg method, you were fine.
If your provider used your phone number for the contents of [Your Account User ID] then it continued to work. If your provider used anything other than your phone number there, such as 1777xxxxxxx for Callcentric, then it was broken in some circumstances.
For me, calls dialed to Callcentric DIDs failed to connect. But for calls to an IPKall DID that forwarded to the OBi provisioned Callcentric SIP URI worked. I do not understand why calling a DID failed and calling a SIP URI worked though. I'd like to have that explained.
The current status now is that OBiTalk no longer pushes {>[Your Account User ID] to your X_InboundCallRoute. Only the bare 'ph' is used. If want protection from SIP scanners, and you actually need this protection, then you have to manually enable the new X_EnforceRequestUserID feature.
I hope this clears it up for you. And if anything I said is not correct, I welcome corrections.
meerkat:
A changelog post from OBI, along with firmware release will certainly help some of those who get stuck and try to trouble shooting.
Navigation
[0] Message Index
[#] Next page
[*] Previous page