December 18, 2017, 03:04:01 am *
Welcome, Guest. Please login or register.
News:
 
   Forum Home   Search Login Register OBiTALK  
Pages: 1 2 3 [4] 5
  Print  
Author Topic: 3.0.1 (4303) Can No Longer Receive Calls  (Read 104107 times)
SteveInWA
Hero Member & Beta Tester
*****
Posts: 3973



« Reply #60 on: March 03, 2014, 09:05:24 pm »

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.
Logged

Tobi
Newbie
*
Posts: 8


« Reply #61 on: March 03, 2014, 09:15:45 pm »

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.
Logged
MikeHObi
Sr. Member
****
Posts: 326



« Reply #62 on: March 04, 2014, 05:44:18 am »

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?
Logged

Obi202 user & Obi100 using Anveo and Callcentric.
gderf
Sr. Member
****
Posts: 490



« Reply #63 on: March 04, 2014, 06:10:19 am »

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.

Logged

Help me OBiHai PhoneOBi. You’re my only hope.
meerkat
Newbie
*
Posts: 17


« Reply #64 on: March 04, 2014, 10:01:50 am »

A changelog post from OBI, along with firmware release will certainly help some of those who get stuck and try to trouble shooting.

Logged
QBZappy
Hero Member & Beta Tester
*****
Posts: 2322



« Reply #65 on: March 04, 2014, 10:41:05 am »

A changelog post from OBI, along with firmware release will certainly help some of those who get stuck and try to trouble shooting.

This is the most vexing problem for consumers of the OBi product since day one. Over the course of time people have begged on bended knees, demanded forcefully, politely asked to no avail. There was a breakthrough at one time when it seems there was a genuine effort to inform of firmware changes. This was greeted with much enthusiasm. Obihai dropped it faster than a new years resolution to loose lose weight.

Everyone without exception buying an OBi product wants obihai to succeed. Why do they go out of their way to keep their customers in the dark. The client base would be more forgiving when the occasional screw up happens as evidenced by the recent firmware fiasco. What trade secrets do they think they are protecting? From my point of view it is quite the opposite that they are doing. In fact they should be shouting from the rooftops extolling the different features of their products instead of sitting at their desk reading this rant about their disconnect with their retail base.

Just today I received an email notification from Grandstream notifying of the availability of a new firmware of one of their products. These notifications come on a regular basis. If you go on their support site you will see the proper way to document and support firmware changes. FWIW these notices are comforting and a constant reminder of my Grandstream products. The marketing people at obihai should be learning from this exercise as I think a simple email notification with a change log builds brand loyalty. This effort helps the product since it will have an effect of push and pull on product interest.

Enough for one day. Now back to your previously scheduled programming!

Edited: Pardon my French
« Last Edit: March 04, 2014, 04:46:10 pm by QBZappy » Logged

Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.
BigJim_McD
Full Member
***
Posts: 190



« Reply #66 on: March 04, 2014, 01:53:43 pm »

I totally agree with the comments by Meerkat and QBZappy.  At times I wonder just why many of us remain loyal customers of OBi. 

I would enjoy being able to recommend OBi devices to my friends but I can't except to the most tech savvy friends that have time to dig into this forum when they have an issue.  As for me either I'm a glutton for punishment or maybe it's because I'm a retired Wireless Telephony Integration Engineer with too much time on hand with a need to keeping finding puzzles to solve.
Logged

BigJimMcD
Koby
Jr. Member
**
Posts: 45


« Reply #67 on: March 04, 2014, 01:59:51 pm »

Fortunately, I did not upgrade my firmware in the last few days and did not encounter this issue, but my question is this.  I do currently use the "Oleg method" to thwart sip scanners, and I'd like to be able to keep my firmware up-to-date.  So, what is the recommendation now?

Do I:
  • Continue to use the Oleg method because the problem has now been corrected?
  • Stop using the Oleg method and enable X_EnforceRequestUserID instead?
  • Both use the Oleg method and enable X_EnforceRequestUserID
  • Don't use either of these for the time being?
  • Avoid ever updating the firmware again? Wink

I just don't understand what actually happened and how it was fixed well enough to know what is the right thing to do now.
Logged
MikeHObi
Sr. Member
****
Posts: 326



« Reply #68 on: March 04, 2014, 02:07:35 pm »

If want protection from SIP scanners, and you actually need this protection, then you have to manually enable the new X_EnforceRequestUserID feature.


One correction perhaps.  If I want protection from SIP scanners I have to not only manually enable the new X_EnforceRequestUserID  but I have to make sure the company I am working with for my SIP can work with that.

Note that OBi is the ones that threw the OLEG method on my settings as I never did it, it was just there.  The benefit to that method is that the provider of the SIP service didn't need to do anything.  From what i understand now is that if you use X_EnforceRequestUserID then the provider has to support that.

I've yet to see any updates from providers or Obi with the list of providers that support this flag they added.
Logged

Obi202 user & Obi100 using Anveo and Callcentric.
gderf
Sr. Member
****
Posts: 490



« Reply #69 on: March 04, 2014, 02:10:15 pm »

With the current firware, the Oleg method may either work like it used to or cause your incoming calls to fail. The problem is that what the Oleg method introduces into your  X_InboundCallRoute is no longer fully compatible with all VoIP service providers. A question for you is do you really need to use the Oleg method? Are you really vulnerable to SIP scanners?

You can stop using the Oleg method and use X_EnforceRequestUserID instead if you are vulnerable to SIP scanners. It won't hurt anything to enable it even if you are not vulnerable.

There is nothing to be gained by combining both methods.

Unless you are vulnerable to SIP scanners, there is no need to use either method. Are you vulnerable?

I would say the better thing to do now is disable automatic firmware updates, keeping in mind that it may still be possible for Obihai to push new firmware to you even if you disable that function, and only update to new firmware if it solves a specific problem you are having. The problem with this advice is that exactly what is fixed or new in any particular firmware update is either undocumented or vaguely described.

You can safely update to the latest firmware if you are subscribed to OBiTALK. OBiTALK will remove the Oleg method from your X_InboundCallRoute to prevent breakage, but you will have to manually enable X_EnforceRequestUserID if you need protection against SIP scanning.


Logged

Help me OBiHai PhoneOBi. You’re my only hope.
MikeHObi
Sr. Member
****
Posts: 326



« Reply #70 on: March 04, 2014, 02:17:31 pm »

You can safely update to the latest firmware if you are subscribed to OBiTALK. OBiTALK will remove the Oleg method from your X_InboundCallRoute to prevent breakage, but you will have to manually enable X_EnforceRequestUserID if you need protection against SIP scanning.


I highlighted above as that seems to be something that some keep saying but they leave out the fact that manually enabling X_EnforceRequestUserID is not that simple.  Because enabling that can break your ability to receive and make calls unless you make sure you are using a provider with which that flag works.  (and I'm unaware of any provider that supports this)
Logged

Obi202 user & Obi100 using Anveo and Callcentric.
BigJim_McD
Full Member
***
Posts: 190



« Reply #71 on: March 04, 2014, 02:21:22 pm »

Koby,

I have updated my OBi202 to the new firmware version Build: 4318.  I also have X_EnforceRequestUserID enabled without any issues with either Vestalink or with voip.ms.  I use OBiTALK to manage my Obi202, Obi100 and Obi110.  I no longer use the “Oleg method”.

The OBiTALK “Generic Service Provider” option was used to configure the OBi202 for Vestalink on SP1.  Next, OBiTALK was used to configure SP3 and SP4 for “voip.ms.  OBiTALK “OBi Expert Configuration” was used to modify the configuration to enable X_EnforceRequestUserID.

The voip.ms service is used for “Failover Call Forwarding” and for “Extensions” on my old OBi100 and OBi110.  I use the older OBi devices as Lab or Test devices to check out various VoIP services.


OBiTALK - OBi Dashboard
SP1  Home Ph1 sp1 Vestalink      Registered
SP2 
SP3  Home Ph2 sp3 voip.ms Main      Registered
SP4  vOFc Ph2 sp4 voip.ms x1024   Registered
Logged

BigJimMcD
Koby
Jr. Member
**
Posts: 45


« Reply #72 on: March 04, 2014, 02:24:26 pm »

With the current firware, the Oleg method may either work like it used to or cause your incoming calls to fail. The problem is that what the Oleg method introduces into your  X_InboundCallRoute is no longer fully compatible with all VoIP service providers. A question for you is do you really need to use the Oleg method? Are you really vulnerable to SIP scanners?

You can stop using the Oleg method and use X_EnforceRequestUserID instead if you are vulnerable to SIP scanners. It won't hurt anything to enable it even if you are not vulnerable.

There is nothing to be gained by combining both methods.

Unless you are vulnerable to SIP scanners, there is no need to use either method. Are you vulnerable?

Actually I shouldn't be, since although UDP port 5060 is open in the router it is directed to an Asterisk server, not to an Obihai device.  It was mainly just a bit of extra security.

But, I know a couple of guys that have Obihai devices, more or less on my recommendation, that were having this issue, so I helped them set up the Oleg method (easier than trying to get them to change their firewalls).  But they are both running OBi110's which I understand were not affected by this?

I would say the better thing to do now is disable automatic firmware updates, keeping in mind that it may still be possible for Obihai to push new firmware to you even if you disable that function, and only update to new firmware if it solves a specific problem you are having. The problem with this advice is that exactly what is fixed or new in any particular firmware update is either undocumented or vaguely described.

You can safely update to the latest firmware if you are subscribed to OBiTALK. OBiTALK will remove the Oleg method from your X_InboundCallRoute to prevent breakage, but you will have to manually enable X_EnforceRequestUserID if you need protection against SIP scanning.

Great, that's what I wanted to know.  Thanks!
Logged
gderf
Sr. Member
****
Posts: 490



« Reply #73 on: March 04, 2014, 02:25:42 pm »

Well, the only way to find out whether your provider supports enabling X_EnforceRequestUserID is to test it yourself.

Frankly, your not being aware of any provider that supports enabling X_EnforceRequestUserID doesn't mean it that there aren't any that do support it.

Callcentric does, I've tested it, and not having any others to try that's all I can do.

Don't you think we would be seeing this forum flooded again with problem reports if enabling X_EnforceRequestUserID caused new mass breakage?

Just enable it, call your number from another phone, and see what does or does not happen.

And do you really need protection from SIP scanners in the first place? I don't, so I leave it disabled. I didn't have a choice with the Oleg method, OBiTALK pushed that into me.
« Last Edit: March 04, 2014, 02:28:34 pm by gderf » Logged

Help me OBiHai PhoneOBi. You’re my only hope.
Koby
Jr. Member
**
Posts: 45


« Reply #74 on: March 04, 2014, 02:27:32 pm »

Koby,

I have updated my OBi202 to the new firmware version Build: 4318.  I also have X_EnforceRequestUserID enabled without any issues with either Vestalink or with voip.ms.  I use OBiTALK to manage my Obi202, Obi100 and Obi110.  I no longer use the “Oleg method”

Thanks, good to know!
Logged
QBZappy
Hero Member & Beta Tester
*****
Posts: 2322



« Reply #75 on: March 04, 2014, 02:52:58 pm »

Koby,

I have updated my OBi202 to the new firmware version Build: 4318.  I also have X_EnforceRequestUserID enabled without any issues with either Vestalink or with voip.ms.  I use OBiTALK to manage my Obi202, Obi100 and Obi110.  I no longer use the “Oleg method”

I believe the recent changes of the firmware are to the OBi2XX models. The OBi1XX did not inherit the X_EnforceRequestUserID feature. If that is correct the "oleg method" is still relavant!
Logged

Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.
Ostracus
Hero Member
*****
Posts: 581


« Reply #76 on: March 04, 2014, 04:16:31 pm »

This is the most vexing problem for consumers of the OBi product since day one. Over the course of time people have begged on bended knees, demanded forcefully, politely asked to no avail. There was a breakthrough at one time when it seems there was a genuine effort to inform of firmware changes. This was greeted with much enthusiasm. Obihai dropped it faster than a new years resolution to loose weight.

Hey that stuff is loose enough. Don't want it to fly free and put an eye out. Grin
Logged
MikeHObi
Sr. Member
****
Posts: 326



« Reply #77 on: March 04, 2014, 04:29:04 pm »

Took the firmware on my Obi202.  Configured Google Voice to forward via Anveo.  Flipped the X_EnforceRequestUserID  to true for SP1 (GV), SP2(Callcentric) and SP3(Anveo).  Note the default appeared to be on for Callcentric and Anveo though I can't be sure if that only flipped because I forced it for SP1 (GV).  In all cases I'm using the ObiTalk expert configuration pages.

First configure GV to forward through Anveo.   Able to receive call, able to make call.
Second, configure GV to forward through Callcentric.  Able to receive call, able to make call.
Third, configure to foward via google chat.  Able to receive call, able to make call.

So I think I can say that Anveo, and Callcentric support this.

Logged

Obi202 user & Obi100 using Anveo and Callcentric.
QBZappy
Hero Member & Beta Tester
*****
Posts: 2322



« Reply #78 on: March 04, 2014, 04:48:05 pm »

Hey that stuff is loose enough. Don't want it to fly free and put an eye out. Grin

Good one!
Logged

Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.
Mango
Sr. Member
****
Posts: 498


« Reply #79 on: March 06, 2014, 06:27:57 am »

3.0.1 (4330) for OBi2 & OBi3 Series: http://fw.obihai.com/OBi202-3-0-1-4330.fw
Restored the X_InboundCallRoute behavior as in 3.0.1.4269 and prior releases.
Specifically, the problem where the rule {>[Your Account UserID]:ph} is not working with
some service providers in 3.0.1.4303 and 3.0.1.4318 has been corrected.

Excellent!
Logged

Pages: 1 2 3 [4] 5
  Print  
 
Jump to:  

Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC