My OBi200 reboot by itself randomly and there's no reason code displayed on the status page. But when I export the settings and open the file I can see "(91)" in there. I searched this forum and found somebody else mentioned this too but I couldn't find a solution.
I contacted OBihai support, they told me that "Such reboot 91 indicates there are some incorrect combinations of parameters that cause the OBi to reboot." and asked me to do a factory reset, delete the device from the portal, then add it and re-configure it again. I followed their instructions. However, this seems didn't work and I still see random reboots.
Part of the device info:
ModelName OBi200
HardwareVersion 1.4
SoftwareVersion 3.0.1.4738
CertificatesStatus Installed
CustomizationStatus Generic
I have voip.ms on SP1 and Google Voice on SP2. The ATAs, modem, router, etc are all plugged in a UPS, and I know exactly when a network connection was reset. I also have a Linksys PAP2T and it never reboot by itself.
What's the possible cause of this mysterious reboot problem? Hardware or firmware related? I would highly appreciate if anybody can point me to the right direction. Thanks a lot!
It may be difficult to pin this down to hardware or firmware issues.
I'd suggest trying this,
in this exact order:
- Delete the device from the OBiTALK portal. Confirm that it is truly gone.
- Go here and download firmware version 4822: http://fw.obihai.com/OBi202-3-0-1-4822.fw (http://fw.obihai.com/OBi202-3-0-1-4822.fw)
- Press ***1 on the telephone attached to the OBi to find out the OBi's IP address.
- Log into the OBi's local web interface from your computer's web browser, and go to the System Management-->Device update page.
- Choose the firmware file you downloaded, select it and update the OBi.
- Find the factory reset hole on the device, and, while it is powered on, depress it with a paper clip for about 10 seconds, until the device resets.
- Add the device back to the OBiTALK portal using the **5 procedure.
- Configure just one of your two service providers (take your pick) via the OBiTALK portal. Do not make any custom configuration changes, beyond the plain vanilla OBiTALK portal setup for that SP.
- Use it for a while to see if/when it fails.
- If it fails, the unit (or its power adapter) is likely defective.
- If it works, then configure the other SP. Don't make any custom configuration changes, and use it for a while to see if it fails.
- Report your findings here
This sounds exactly like the problem I have been experiencing with a 202 (firmware 4581). I described the problem in this thread, which may be the post you refer to: http://www.obitalk.com/forum/index.php?topic=10334
Since posting, I have made some additional observations. I do not have a solution, but I do have a workaround that appears to work for me. In my case, the random reboots start to occur after I change a parameter using the built-in webserver. Doing so requires reboot for the change to take effect, after which the reason code on the Status page shows (4) - "Reboot after Parameter Change or Firmware has changed and invoked via device web page" [ OBi Device Admin Guide, p56 ]. However, after subsequent random reboots, no reason code is shown. The random reboots continue to occur every one to several days from this point on, although I've never had one occur while I was actually using the device. However, if I manually command another reboot from the webserver, the device then becomes stable, with the reboot reason code of (9) - "Reboot from Webpage - No change in parameter values or firmware". The last time I did this the device went 27 days without a reboot, until I made another parameter change, after which the random reboots started again until I did another forced (9) reboot.
Note that I am using a non-recommended method of programming the device: I've disabled all Obi updates and make all changes from the built-in webserver. I don't know if this has anything to do with stimulating the problem or not.
I would suggest you try requesting a manual reboot by clicking on the "Reboot" button in the upper-left corner of the web page and see if that affects the random reboots. If it does, I suspect OBi has a bug in their 200/202 firmware.
Quote from: restamp on September 29, 2015, 08:56:56 PM
This sounds exactly like the problem I have been experiencing with a 202 (firmware 4581). I described the problem in this thread, which may be the post you refer to: http://www.obitalk.com/forum/index.php?topic=10334
Since posting, I have made some additional observations. I do not have a solution, but I do have a workaround that appears to work for me. In my case, the random reboots start to occur after I change a parameter using the built-in webserver. Doing so requires reboot for the change to take effect, after which the reason code on the Status page shows (4) - "Reboot after Parameter Change or Firmware has changed and invoked via device web page" [ OBi Device Admin Guide, p56 ]. However, after subsequent random reboots, no reason code is shown. The random reboots continue to occur every one to several days from this point on, although I've never had one occur while I was actually using the device. However, if I manually command another reboot from the webserver, the device then becomes stable, with the reboot reason code of (9) - "Reboot from Webpage - No change in parameter values or firmware". The last time I did this the device went 27 days without a reboot, until I made another parameter change, after which the random reboots started again until I did another forced (9) reboot.
Note that I am using a non-recommended method of programming the device: I've disabled all Obi updates and make all changes from the built-in webserver. I don't know if this has anything to do with stimulating the problem or not.
I would suggest you try requesting a manual reboot by clicking on the "Reboot" button in the upper-left corner of the web page and see if that affects the random reboots. If it does, I suspect OBi has a bug in their 200/202 firmware.
Your device is downlevel. Upgrade the firmware.
Thank you for your replies, SteveInWA and restamp! I will try your suggestions soon later.
SteveInWA: I noticed the firmware you posted is for OBi202, is it also compatible with OBi200?
The OBi 200 and 202 use the same firmware.
Thank you SteveInWA!
Before doing tests as you suggested, I disabled all auto provisions and OBiTalk service last night to see if I can see some changes. If not I will try your method.
Disabling auto-provisioning and OBiTALK won't help, and are not the problem. Just follow the steps in my post and report back.
Quote from: SteveInWA on October 01, 2015, 01:13:51 PM
Disabling auto-provisioning and OBiTALK won't help, and are not the problem. Just follow the steps in my post and report back.
Just followed your directions and set up voip.ms on SP1 only, no custom options, just leave as default.
Put a footprint here for my own record. :)
HardwareVersion 1.4
SoftwareVersion 3.0.1 (Build: 4822)
SystemTime 19:48:04 10/01/2015, Thursday
UpTime 0 Days 0:02:04 (6)
It's been almost 4 days now and no reboot happened yes. :)
I also noticed that there was a disconnect of my internet at about 3:16am this morning. Last time when this happened, the OBi200 also rebooted, but today it didn't.
Should I add SP2 now or wait a little longer?
It's up to you! If you want to wait a few more days to see if you get a random reboot, great; otherwise, you can add SP2, and see what happens. You can, of course, back out the SP2 addition if it starts failing, to isolate the failure. Troubleshooting 101, essentially.
It's been 5 days without reboot. I just set up GV on SP2, left everything as default. Let's see what will happen. :)
While I am observing stability of the device, I'd like to post my next question here.
Current settings (default settings after two SPs added):
SP1 DigitMap:
(1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|011xx.|xx.|(Mipd)|[^*#]@@.)
SP2 DigitMap:
(1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|011xx.|xx.|(Mipd)|[^*#]@@.)
Phone Line DigitMap:
([1-9]x?*(Mpli)|[1-9]S9|[1-9][0-9]S9|911|**0|***|#|##|**70(Mli)|**8(Mbt)|**81(Mbt)|**82(Mbt2)|**1(Msp1)|**2(Msp2)|**3(Msp3)|**4(Msp4)|**9(Mpp)|(Mpli))
Phone Line OutboundCallRoute:
{911:sp1},{933:sp1},{([1-9]x?*(Mpli)):pp},{(<##:>):li},{(<**70:>(Mli)):li},{(<**82:>(Mbt2)):bt2},{(<**81:>(Mbt)):bt},{(<**8:>(Mbt)):bt},{**0:aa},{***:aa2},{(<**1:>(Msp1)):sp1},{(<**2:>(Msp2)):sp2},{(<**3:>(Msp3)):sp3},{(<**4:>(Msp4)):sp4},{(<**9:>(Mpp)):pp},{(Mpli):pli}
Phone Line CallReturnDigitMaps:
{pli:(xx.)},{sp1:(<**1>xx.)},{sp2:(<**2>xx.)},{sp3:(<**3>xx.)},{sp4:(<**4>xx.)},{bt:(<**8>xx.)},{bt2:(<**82>xx.)},{pp:(<**9>xx.)}
PrimaryLine:
SP1 Service
My requirements:
1. let the device select SP based on dialed number, without dialing **(1|2), but still can manually select which service to use with **(1|2)
2. call all North American numbers and international numbers through GV (SP2)
3. call 911, *97, *98, 4xxx, *225, and all toll free numbers through voip.ms (SP1)
4. if GV failed in (2), still call numbers in (2) through voip.ms (SP1)
4. better to keep OBiTalk service but not a must if it's a compromise of stability
What's the simple and good way to do this? I have my old settings, but I am afraid they were the culprit of random reboot, so I'd like to make changes from the default first.
I'll let Robert esplain how to accomplish your dialing goals, but first, I suggest that you leave it as-is with the defaults for a week to prove that it works without "randomly" rebooting.
Yes I will leave it as is for some days and observe if anything happens again. Thanks SteveInWA!
It's been 10 days without reboot. So I guess the device with the new firmware is stable now? ;D
I am going to change the DigiMap and OutboundCallRoute to make it work according to my requirements. Will report back how it goes. And yes, if Robert can chime in and give me some suggestions regarding my settings that will be geat!
Robert seems to be taking a well earned rest - so I'll have a go at this one :)
Setting up a Trunk Group will do what you want. Dialling **1 or **2 will still force calls to sp1 and sp2 respectively.
Parameters should be as follows:
Physical Interfaces > PHONE Port > PrimaryLine: Trunk Group 1
Voice Service > Auto Attendant > PrimaryLine: Trunk Group 1
Voice Services > Gateways and Trunk Groups > Trunk Group1 >
TrunkList: sp2,sp1
DigitMap: ((Msp2)|(Msp1))
Voice Services > SP2 Service > X_NoRegNoCall: checked
SP1 DigitMap:
(*97|*98|4xxxS3|*225|1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|011xx.|xx.|(Mipd)|[^*#]@@.)
SP2 DigitMap:
(1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|011xx.)
Nothing to do with the above, but I notice 933 is missing from here:
Phone Line DigitMap:
([1-9]x?*(Mpli)|[1-9]S9|[1-9][0-9]S9|911|933|**0|***|#|##|**70(Mli)|**8(Mbt)|**81(Mbt)|**82(Mbt2)|**1(Msp1)|**2(Msp2)|**3(Msp3)|**4(Msp4)|**9(Mpp)|(Mpli))
Thank you very much ianobi!
I missed your requirement for routing of toll free numbers. There's more than one way to sort this, but to route them normally via Voip.ms and also allow forcing them to GV by dialling **2, I suggest this:
User Settings > User Defined Digit Maps > User Defined Digit MapX >
Label: tfree
DigitMap: (18(00|88|77|66|55)xxxxxxx|<1>8(00|88|77|66|55)xxxxxxx)
Phone Line DigitMap:
([1-9]x?*(Mpli)|[1-9]S9|[1-9][0-9]S9|911|933|**0|***|#|##|**70(Mli)|**8(Mbt)|**81(Mbt)|**82(Mbt2)|**1(Msp1)|**2(Msp2)|**3(Msp3)|**4(Msp4)|**9(Mpp)|(Mtfree)|(Mpli))
Phone Line OutboundCallRoute:
{(911|933|(Mtfree)):sp1},{([1-9]x?*(Mpli)):pp},{(<##:>):li},{(<**70:>(Mli)):li},{(<**82:>(Mbt2)):bt2},{(<**81:>(Mbt)):bt},{(<**8:>(Mbt)):bt},{**0:aa},{***:aa2},{(<**1:>(Msp1)):sp1},{(<**2:>(Msp2)):sp2},{(<**3:>(Msp3)):sp3},{(<**4:>(Msp4)):sp4},{(<**9:>(Mpp)):pp},{(Mpli):pli}
Thank you ianobi! I am still learning these settings so I have couple questions here.
1. Why you put "(Mfree)" in the phone line digitmap? I think "(Mpli)" is TG1's digitmap in my case so it has both Msp1 and Msp2 thus the toll free numbers are already included. Am I right?
2. Can I put 911|933 in Msp1 instead of in OutboundCallRoute because these two are exclusive for SP1?
1. Yes, you are right. I put it in the digitmap as a discrete item to make things easy to trace - so all (Maps) in the phone port digitmap match up with (Maps) in the phone port outboundcallroute. Also, it protects against future changes to the digitmaps Msp1 and Msp2.
2. Yes, but I advise against it. The OBi design puts 911 in the Phone Port OutboundCallRoute to give it the most direct way of being routed with the least number of digitmaps involved. The way it is now any changes to any sp/tg/vg digitmaps cannot affect it being routed directly to sp1. This is particularly important when using Trunk Groups. E.g. If you put 911 in the sp1 digitmap, then for some reason at a later date put a rule such as "xx." in the sp2 digitmap, then the Trunk Group config would route the 911 calls to sp2.
You might say it's a blessing and a curse just how configurable these OBi devices are. There are often two or three different ways of configuring digitmaps etc to achieve the same end. Sometimes there are logical reasons for taking one sort of approach, but sometimes it just comes down to personal preference.
Quote from: ianobi on October 19, 2015, 09:12:59 AM
You might say it's a blessing and a curse just how configurable these OBi devices are. There are often two or three different ways of configuring digitmaps etc to achieve the same end. Sometimes there are logical reasons for taking one sort of approach, but sometimes it just comes down to personal preference.
To which I would add: kudos to you, Ian... IMO, you're the only contributor on this forum who truly understands not only how to customize digit maps, but exactly how each parameter is designed to work, and why one solution is better than another, resulting in solutions that work without a lot of re-tries. This complexity, and likelihood of breaking something, is the main reason I steer most users away from attempting to create customized configurations, as long as the OBiTALK portal can accomplish the same thing.
Thanks Steve - when it comes to digit maps I would say azrobert knows at least as much as me and answers more posts. Also, any of us who know our way around digit maps owe a big debt to RonR. His explanations of digit maps and call routing are still a much better reference than the AdminGuide.
We need a good mix of contributors here - for example, what I know about GV could be written in very large letters on the back of a postage stamp :)
Thank you for your explanation ianobi! This is very helpful to me.
Back to the topic, so far so good, OBi200 has been stable since my last change. I will observe and report back if reboot happens again.