December 16, 2018, 06:55:39 pm *
Welcome, Guest. Please login or register.
News:
 
   Forum Home   Search Login Register OBiTALK  
Pages: 1 [2]
  Print  
Author Topic: Firmware 3.2.2 Build 5898) breaks PhonePower. Need to revert to 3.2.2 build 5757  (Read 10439 times)
BenE
Newbie
*
Posts: 6


« Reply #20 on: August 14, 2018, 07:02:07 pm »

I didn't have to change from Phone Power to another ITSP.  Why that was mentioned as a fix is why that is confusing to me, as we want to get Phone Power to work, as it did on older firmware or on older devices.

Anyway, I did have to go thorough the template provided by Phone Power to be able to use SIP Credentials, as Phone Power no longer can provision Obi devices directly.  I could not get back to the firmware that did work previously due to the mismatch.  All I can guess is that Phone Power might have fixed something on their end that will only register the OBI200 as a single device, or my internet outage fixed something that allows the device to properly register.

Logged
KevKan
Jr. Member
**
Posts: 46


« Reply #21 on: August 16, 2018, 11:23:21 am »

BenE, I am glad to hear your device mysteriously started working properly and hope it continues to be trouble free.

Being a most satisfied PhonePower customer for over four years, I too wanted them to the fix the problem.
They emphatically maintained this was not their problem, it was Obi Hai's.  After hearing this for four weeks,
I started searching to see if this problem was being reported with other ITSPís.  Finding none, it appeared this
problem was exclusive with PhonePower.   Based on this, I felt it was time to try a different ITSP and moved
two SIP configured devices plagued with the problem.  Two other Obi Hai devices I have with PhonePower,
configured on ObiTalk when PhonePower was an approved supplier, are rock solid.

Since I am unaware of Obi Hai revising their firmware, and you say it is working, it now appears PhonePower must have accepted responsibility for their problem and proceeded to fix their software.  I hope this to be true.

Please keep us posted on how your device is functioning.

Mystery Soved!! Just spoke with PhonePower tech support and they confirmed they found their problem (didn't say when) and have corrected it.  It sure would have been nice if they had informed their customers.

 



« Last Edit: August 16, 2018, 12:34:03 pm by KevKan » Logged
madhouse
Newbie
*
Posts: 4


« Reply #22 on: August 20, 2018, 09:13:07 pm »

Does anyone have a working sip setup with PhonePower? I am up on a Grandstream but would like to get my OBI 202 back. The OBI works to some degree but I cant get the *21 to work for voicemail. It works on the Grandstream strange enough. I can setup the ID and password OK but not sure about the 100 or so other parameters! I was able to revert build back to 3-2-2 build 5859. Thanks
Logged
etta
Newbie
*
Posts: 1


« Reply #23 on: August 22, 2018, 09:44:38 pm »

Hi KevKan, may I ask what new ITSP did you choose?


For clarification of my post, ITSP is the abbreviation for "Internet Telephone Service Provider" .  A few of them are:  Anveo, PhonePower, VOIP.MS, and Callcentric.
Logged
jman19
Newbie
*
Posts: 2


« Reply #24 on: September 05, 2018, 06:49:06 pm »

BenE, I am glad to hear your device mysteriously started working properly and hope it continues to be trouble free.

Being a most satisfied PhonePower customer for over four years, I too wanted them to the fix the problem.
They emphatically maintained this was not their problem, it was Obi Hai's.  After hearing this for four weeks,
I started searching to see if this problem was being reported with other ITSPís.  Finding none, it appeared this
problem was exclusive with PhonePower.   Based on this, I felt it was time to try a different ITSP and moved
two SIP configured devices plagued with the problem.  Two other Obi Hai devices I have with PhonePower,
configured on ObiTalk when PhonePower was an approved supplier, are rock solid.

Since I am unaware of Obi Hai revising their firmware, and you say it is working, it now appears PhonePower must have accepted responsibility for their problem and proceeded to fix their software.  I hope this to be true.

Please keep us posted on how your device is functioning.

Mystery Soved!! Just spoke with PhonePower tech support and they confirmed they found their problem (didn't say when) and have corrected it.  It sure would have been nice if they had informed their customers.


Hi all,
New to this forum, and I hope that we can share some info that will help out.
I just ported a landline to PhonePower, after having an account with them for over a year and waiting for the right opportunity. I had an OBi200 that (unfortunately) had a lot of analog line noise with hardwired phones, so I could not port my number until I switched to an OBi202 which has much better analog performance. Anyway, I struggled this afternoon with a lot of the same issues as others are having (device unregistering and registering in the middle of phone calls, etc.) I called PP support and was told that the firmware version was causing the problem. I disabled automatic firmware updates and tried to revert to earlier FW versions without success.
I also tried signing up with CallCentric and entering this ITSP as SP2 to compare registration stability. It's too soon to know for sure, but testing is underway. So far, PhonePower has dropped off several times in the last hour, while CallCentric remains registered.
I also tried reconfiguring my OBi200 for the PP service, and noticed that both devices were showing "unregistered" at the same time. Then they both showed "Registered" a short while later. It seems there is some possible issue on the PP registration server...

CallCentric recommends trying their service before committing to a phone number port, so we will see how that works out.

Bottom line is that the support tech I spoke to said that there was still a problem and that Obihai/Polycom needed to fix it. He did mention that this had been a problem since about May, which was consistent with other postings in this forum. So, I would not be too ready to say that the problem is "fixed" - maybe Polycom is working on a FW update.

Some more info: PP tech support has been very helpful. They seem as frustrated as anyone else that this problem is still not solved. Rolling back to the last version of FW that can be loaded (5859EX) solved the problem for me, although there was a lot of parameters to change from the "default" values (mostly using port 12060 instead of 5060 and entering sip.phonepower.com for practically every server address). Obihai tech support pushed the latest FW back onto the device and broke it again (thus confirming that the 5898EX firmware is causing the problem), so I reverted again to 5859EX and it's working again. It's too soon to tell if this will continue to be an issue.
It does not seem to matter if I have the port forwarding on my network firewall enabled or disabled, so I'll keep it disabled.

I have a working configuration with the OBi202, as long as the FW stays at 5859EX or Obihai releases a newer version that fixes this once and for all.
« Last Edit: September 11, 2018, 01:55:54 pm by jman19 » Logged
madhouse
Newbie
*
Posts: 4


« Reply #25 on: September 17, 2018, 08:22:14 am »

jman19, how are you doing with PP. I loaded 5859EX and set up sip but still dropping calls. Using a GS box at the same time with no problems so I know its the OBI. I do like the OBI box better and would like to get it working. If your up can you PM the changes you made to the default to get it working? Thanks. Madhouse
Logged
Abestock
Newbie
*
Posts: 11


« Reply #26 on: September 27, 2018, 01:49:55 pm »

Been running this for months without any issues. Occasionally have to reboot due to Polycom server not in sync.

SoftwareVersion
3.2.2 (Build: 5898EX)

SystemTime
14:18:07 09/27/2018, Thursday

UpTime
5 Days 2:15:29 (1

I am using my own  BYOD Obi202 on PP. I have a special deal for a reduced rate.
This deal was available to people that provide their own units.
I have the non-cloned service active on port 1 ONLY. Didn't need same tel. number appearing on port 2.
The two port configuration requires MPLS, configured by PP techs on their server.
So, when it came time to provision the unit via Obihai, it kept falling out.
The problem was found to be that since I provided my own unit, went through the provisioning process via Obihai. PP provides a template for Obihai to datafill when provisioning the unit.
Obihai passed the template onto PP where it was rejected due to no account info setup in PP server.
Even though I had entered ALL the required information, the Obihai template that PP provided was incorrectly datafilled by Obihai itself, causing the rejection.
When it was rejected by PP, all my datafill was all DEFAULTED because ITSP Provisioning - Method was set to Enabled by default.
In other words, it was thrown out by PP and since Obihai didn't know what to do, unit was defaulted by Obihai. PP wasn't even aware of this happening. The problem was identified and corrected.

Change the following. Everything else is left at Obitalk default values:

Auto Provisioning - Auto Firmware Update - Method = Disabled
ITSP Provisioning - Method = Disabled
                  - ConfigURL = tftp://$DHCPOPT66/$DM.xml;$DHCPOPT66;

OBiTalk Provisioning - Method = Periodically

ITSP? Profile - SIP-
                  - ProxyServer = 206.15.130.6
                  - ProxyServerPort = 12060
                  - RegistrarServer = 206.15.130.6
                  - RegistrarServerPort = 12060
                  - OutboundProxyPort = 5060
                  - X_RegistrationMargin = 0.1
                  - RegisterMinExpires = 60
                  - RegisterRetryInterval = 60
                  - X_AccessList = 208.64.8.6,206.15.130.6,206.15.150.6
                  - X_MWISubscribe = (enabled or check marked)
                  - X_UsePublicAddressInVia = (enabled)
                  - X_DetectALG = (enabled)
                  - X_EchoServerPort = 12060
              RTP - KeepAliveInterval = 10

SP? Service - X_RegisterEnable = (enabled)
            - X_AcceptSipFromRegistrarOnly - (enabled)
            - X_KeepAliveEnable = (enabled)
            - X_KeepAliveExpires = 60
            - X_KeepAliveServer = 206.15.130.6
            - X_KeepAliveServerPort = 12060
            - X_UserAgentPort = 12060

A note about MWI functioning on your analog phone. In order for MWI to turn ON or OFF, your unit MUST be connected to the Obihai server.
Their server controls this function. If you do not register your unit on the Obitalk server, MWI will NOT function regardless.
Seems past issues with this feature requires Obihai control of MWI indicator. If you Obi unit undergoes a power failure, then the MWI is updated after re-registering on their server.
         
            - Calling Features - MWIEnable = (enabled)
            - X_VMWIEnable = (enabled)

         
A note about the 5898 3.2.2 FW. This version provides alternate Tone Settings and Ring Settings if you choose to use PP as SP1. This FW was modified by the UK to provide distinctive UK ring cadence and ring-back tones. That is all it did.
It's great if you have a two line desk phone setup. Go off hook on line 1, UK dial and ringback tones so you know you are placing a call on your PP service.
Line 2 is standard US dial tone, for use on Google Voice. By the way, on my unit, SP1 is PP, SP2,3 and 4 are GV numbers in different states. Thats 4 Service Providers on my Obi 202.

A note about Star codes: Yes, Obi is guilty for even not getting that right for PP. They didn't bother creating a Star Code profile that matches the PP network itself, they just used their usual default.

The CORRECT Star Code profile for PP:

Star Code Profile B -

Star Code Profile B
Star Codes

Code1 - *03, Loopback Media, set($Lbm1,1)

Code2 - *04, Loopback RTP Packet, set($Lbp1,1)

Code3 - *05, Repeat Dial, rpdi($Ldn)

Code4 - *06, Cancel Repeat Dial, rpdi()

Code5 - *07, Redial Last DN, call($Ldn)

Code6 - *10, Day Mode, set($Opm,0)

Code7 - *11, Night Mode, set($Opm,1)

Code8 - *12, Auto Night Mode, set($Opm,2)

Code9 - *21, VM-Redial *21, call(*21)    <------ This is VM *21 !!

Code10 - *27, run OBiWiFi as Access Point, wifiap()

Code11 - *28, OBiBT Discoverable, btdscvr(0)

Code12 - *29, OBiBT Discoverable, btdscvr(1)

Code13 - *4711, Use G711 Only, set($Cdm1,3)

Code14 - *4729, Use G729 Only, set($Cdm1,4)

Code15 - *56, Enable Call Waiting, set($Cwa,1)

Code16 - *57, Disable Call Waiting, set($Cwa,0)

Code17 - *62, Cfwd Busy, coll($Cfbn), set($Cfb,1)

Code18 - *63, Disable Cfwd Busy, set($Cfb, 0)

Code19 - *67, Block Caller ID Once, set($Bci1,1)

Code20 - *68, Unblock Caller ID, set($Bci,0)

Code21 - *69, Call Return, call($Lcn)

Code22 - *70, Disable Call Waiting once, set($Cwa,1)

Code23 - *60, Redial *60, call(*60)

Code24 - *72, Cfwd All, coll($Cfan), set($Cfa,1)

Code25 - *73, Disable Cfwd All, set($Cfa, 0)

Code26 - *74([1-9]|[1-9]x), Set Speed Dial, coll($Spd[$Code])

Code27 - *75([1-9]|[1-9]x), Check Speed Dial, say($Spd[$Code])

Code28 - *76([1-9]|[1-9]x), Clear Speed Dial, set($Spd[$Code],)

Code29 - *77, Block Anonymous Call, set($Bac,1)

Code30 - *78, Do Not Disturb, set($Dnd,1)

Code31 - *79, Disable DND, set($Dnd,0)

Code32 - *81, Block Caller ID, set($Bci,1)

Code33 - *82, Unblock Caller ID Once, set($Ubci1,1)

Code34 - *86, Block last Caller, blst

Code35 - *87, Unblock Anonymous Call, set($Bac,0)

Code36 - *92, Cfwd No Ans, coll($Cfnn), set($Cfn,1)

Code37 - *93, Disable Cfwd No Ans, set($Cfn,0)

Code38 - *96, Barge In, set($Bar1,1)

Code39 - *98, Blind Transfer, coll($Bxrn)

Code40

Most star codes are handled internally by the Obi unit, like *05, etc.
Where a star code requires interaction with the PP network, like an IVR platform, the digit pattern has to be entered into a Digit Map.
After dialing the star code, the call is completed to the IVR platform in order to establish Rx and Tx audio paths.
The three prime examples are *21 (taken care of via Star Codes table), *60 and *83:

PP IVR Feature Codes;

*60 - Selective Call Rejection IVR
*60 + #01# = Reject
    + 3 = Toggle service ON or OFF
   + #11 digit number (1+10D)# = ADD
   + #10 digit number (10D)# = ADD
   + *11 digit number* = REMOVE
   + *10 digit number* = REMOVE
   + 1 = LISTEN
   + 0 = REPEAT
   
*83 - Selective Call Forwarding IVR (*83 plus what?, 10 or 11 digit number?)
   
Currently *60 and *83 go to an intercept message, "The number you have dialed has not been recognized". Really?!! Still trying to get PP to get their IVR platform working. *60 and *83 will be sent to PP via the Outbound Call Route. The digit map below is customized for an Obi located in Toronto, Canada, area codes 416 and 647. Even though PP state they customize to Canadian N11 type service codes, they don't. Some work on their side, some don't.
Entering the codes into the Obi will ensure that when changes are made to a number, you can easily update it. Take for example code 811. In Ontario it is a call before you dig service.
In the province of Quebec, 811 will get connected to a Medical teleservice for help. N11 service codes are geographical and controlled by the monopoly local service provider, Bell Canada.
What PP hasn't done yet is create routing tables to accommodate customers in Canada by matching their tel number to their local N11 services.

Phone? Port (used for PP) - PHONE Port - Digit Maps

Note:
Fixed digits 0 -9 are screened first in order 0, 1, 2 .... to 9
Star codes are screened next
Wild card digits are screened last
Certain digit patterns are for calls made via the AutoAttendant via the PP SP? route

DigitMap - (!0[2-9]S0|!0[0-1]0S0|!011[2-9]|!011[2-9]x|!011[2-9]xx|!011[2-9]xxx|011[2-9]xx{L=5}xx.<#>|011[2-9]xxxxxxxxxxx<#>S0|1-9]S9|x#S0|xx#S0|[1-9]x?*(Mpli)|!1900S0|!1976S0|!1[2-9]11S0|!1[2-9]xx[0-1]S0|1[2-9]xx[2-9]xxxxxxS0|*60S0|*83S0|**31[2-9]xx[2-9]xxxxxxS0|**41[2-9]xx[2-9]xxxxxxS0|<111:7862668989>|<211:4163974636>|<311:4163922489>|411S0|<511:8669294257>|611S0|711S0|<811:8004002255>|911S0|<999:4168082222>|!900S0|922S0|933S0|944S0|!950S0|955S0|966S0|!976S0|977S0|988S0|[2-9]xx[2-9]xxxxxxS0|**3[2-9]xx[2-9]xxxxxxS0|**4[2-9]xx[2-9]xxxxxxS0|**0|***|#|##|**70*xx|**0|***|#|##|**1(Msp1)|**2(Msp2)|**3(Msp3)|**4(Msp4)|**70(Mli)|**81(Mbt)|**82(Mbt2)|**9(Mpp)|(Mpli))

OutboundCallRoute - {(011([2-9]x.#)):sp1},{([1-9]):sp1},{([1-9][1-9]#):sp1},{([2-9]11):sp1},{933:sp1},{([1-9]x?*(Mpli)):pp},{(<##:>):li},{(<#:>):ph2},{(<**70:>(Mli)):li},{(<**82:>(Mbt2)):bt2},{*21:sp1},{*60:sp1},{*83:sp1},{(<**81:>(Mbt)):bt},{**0:aa},{***:aa2},{(<**1:>(Msp1)):sp1},{(<**2:>(Msp2)):sp2},{(<**3:>(Msp3)):sp3},{(<**4:>(Msp4)):sp4},{(<**8:>(Mbt)):bt},{(<**9:>(Mpp)):pp},{(Mpli):pli}



Hope this clears up a few things for you. I would HIGHLY suggest that you DEFAULT your Obi, upload FW build 5898EX, reboot and start from scratch by going through the provisioning process via Obihai, saving the initial file and then manually making the necessary changes after and saving the new file with the PP specific data. This way once you enter your SIP credentials, your device should be "Registered" on the Obitalk platform.
Google Voice services, up to three, will be "Connected" when provisioned properly via existing Google Voice accounts.
I have had no issues by doing it that way and my PP has been working pretty much flawlessly when other users are complaining. There are two elements at a minimum that have to work in conjunction, the ATA and the VoIP service provider. Issues with your ISP and whether or not you decide to register on the Obihai server are other factors.
Logged
madhouse
Newbie
*
Posts: 4


« Reply #27 on: September 30, 2018, 10:20:07 pm »

Well, followed your setup Abestock and it certainly made some changes from the default. I did not register with OBiTalk and left provisioning disabled to prevent getting an update. My MWI seems to be working ok without it. I'll have to try your new setup and see if I am still dropping calls. Thanks for the Post!!!  Cheesy
Logged
Abestock
Newbie
*
Posts: 11


« Reply #28 on: October 01, 2018, 11:19:10 pm »

Noticed some errors in my data, here is an update.

The CORRECT Star Code profile for PP:

Star Code Profile B - star codes are in numerical order *03, *04,*05 .... etc

Star Codes

Code1 - *03, Loopback Media, set($Lbm1,1)

Code2 - *04, Loopback RTP Packet, set($Lbp1,1)

Code3 - *05, Repeat Dial, rpdi($Ldn)

Code4 - *06, Cancel Repeat Dial, rpdi()

Code5 - *07, Redial Last DN, call($Ldn)

Code6 - *10, Day Mode, set($Opm,0)

Code7 - *11, Night Mode, set($Opm,1)

Code8 - *12, Auto Night Mode, set($Opm,2)

Code9 - *21, VM-Redial *21, call(*21)    <------ This is VM *21 !!

Code10 - *27, run OBiWiFi as Access Point, wifiap()

Code11 - *28, OBiBT Discoverable, btdscvr(0)

Code12 - *29, OBiBT Discoverable, btdscvr(1)

Code13 - *4711, Use G711 Only, set($Cdm1,3)

Code14 - *4729, Use G729 Only, set($Cdm1,4)

Code15 - *56, Enable Call Waiting, set($Cwa,1)

Code16 - *57, Disable Call Waiting, set($Cwa,0)

Code17 - *60, IVR-Redial *60, call(*60)  <--- optional, is in Digit Map

Code18 - *62, Cfwd Busy, coll($Cfbn), set($Cfb,1)

Code19 - *63, Disable Cfwd Busy, set($Cfb, 0)

Code20 - *67, Block Caller ID Once, set($Bci1,1)

Code21 - *68, Unblock Caller ID, set($Bci,0)

Code22 - *69, Call Return, call($Lcn)

Code23 - *70, Disable Call Waiting once, set($Cwa,1)

Code24 - *72, Cfwd All, coll($Cfan), set($Cfa,1)

Code25 - *73, Disable Cfwd All, set($Cfa, 0)

Code26 - *74([1-9]|[1-9]x), Set Speed Dial, coll($Spd[$Code])

Code27 - *75([1-9]|[1-9]x), Check Speed Dial, say($Spd[$Code])

Code28 - *76([1-9]|[1-9]x), Clear Speed Dial, set($Spd[$Code],)

Code29 - *77, Block Anonymous Call, set($Bac,1)

Code30 - *78, Do Not Disturb, set($Dnd,1)

Code31 - *79, Disable DND, set($Dnd,0)

Code32 - *81, Block Caller ID, set($Bci,1)

Code33 - *82, Unblock Caller ID Once, set($Ubci1,1)

Code34 - *83 - Selective Call Forwarding IVR, call(*83)  <--- optional, is in Digit Map

Code35 - *86, Block last Caller, blst

Code36 - *87, Unblock Anonymous Call, set($Bac,0)

Code37 - *92, Cfwd No Ans, coll($Cfnn), set($Cfn,1)

Code38 - *93, Disable Cfwd No Ans, set($Cfn,0)

Code39 - *96, Barge In, set($Bar1,1)

Code40 - *98, Blind Transfer, coll($Bxrn)

Most star codes are handled internally by the Obi unit, like *05, etc.
Where a star code requires interaction with the PP network, like an IVR platform, the digit pattern has to be entered into a Digit Map.
After dialing the star code, the call is completed to the IVR platform in order to establish Rx and Tx audio paths.
The three prime examples are *21 (routed via Star Codes table), *60 and *83 (routed via Digit Map for now):

PP IVR Feature Codes;

*60 - Selective Call Rejection IVR
This feature allows you to reject selected inbound callers.

*60 + #01# = Reject last inbound caller
    + #(10 or 11 digit number)# = ADD entry
   + *(10 or 11 digit number)* = REMOVE entry
   + 0 = REPEAT the instructions
   + 1 = LISTEN to the entries already entered
   + 3 = Toggle service ON or OFF
   
*83 - Selective Call Forwarding IVR (*83 plus what?, 10 or 11 digit number?)
This feature allows you to add or delete phone numbers in the Selective Call Forwarding Settings.
   
*83 - Selective Call Forwarding IVR
*83 + #01# = add last inbound caller
    + #(10 or 11 digit number)#1 = ADD entry (the DTMF digit 1 at end confirms entry)
   + *(10 or 11 digit number)* = REMOVE entry
   + 08* = remove all entries
   + 09* = remove anonymous entries
   + 0 = REPEAT the instructions
   + 1 = LISTEN to the entries already entered
   + 3 = Toggle service ON or OFF

   
Currently *60 and *83 go to an intercept message, "Sorry, your request can not be accepted". Still trying to get PP to get their IVR platform working. *60 and *83 will be sent to PP via the Outbound Call Route. The digit map below is customized for an Obi located in Toronto, Canada, area codes 416 and 647. Even though PP state they customize to Canadian N11 type service codes, they don't. Some work on their side, some don't.
Entering the codes into the Obi will ensure that when changes are made to a number, you can easily update it. Take for example code 811. In Ontario it is a call before you dig service.
In the province of Quebec, 811 will get connected to a Medical tele-service for help. N11 service codes are geographical and controlled by the monopoly local service provider, Bell Canada.
What PP hasn't done yet is create routing tables to accommodate customers in Canada by matching their tel number to their local N11 services.

As for MWI working without registering on Obitalk, try this. Leave a message on your VM, see if the MWI turns on. If it does, then retrieve message and verify that MWI turns off. The MWI can be manually turned on/off by locally logging into your Obi, going to Voice Services - SP? Service - MessageWaiting. Checking this enables (turns on) your MWI. DOn't forget to hit submit. Unchecking will then turn MWI off on your phone. Also, if the flag is enabled (turned on) and your MWI is not on, then your phone is out of sync with the MWI status. Power cycle your Obi, see if your MWI flag comes back on.
Logged
Abestock
Newbie
*
Posts: 11


« Reply #29 on: October 02, 2018, 12:22:13 pm »

Had to reboot my Obi as I was working on an issue that existed with Google Voice. Apparently it's a non-issue, software design intended. However, after my reboot, my FW was updated from 5898 to:

SoftwareVersion   3.2.2 (Build: 5921EX)

At no time did I see the yellow reboot icon via local Obi or Obitalk. Interesting. Pays to reboot every once in a while since auto updates are disabled.
Logged
jman19
Newbie
*
Posts: 2


« Reply #30 on: November 01, 2018, 08:25:47 pm »

Hi all,
I have been running my config for a while now and everything seems stable. Madhouse, sorry for not replying sooner, as things have been a bit busy. I did get most of the config info directly from the PhonePower support people.
Meanwhile, does anyone know if the latest build mentioned (5921, I think) fixes the PP issues without a lot of manual configuration?
Logged
Abestock
Newbie
*
Posts: 11


« Reply #31 on: November 20, 2018, 11:15:31 am »

I've been on 5921EX for months now, working with PP. NO PROBLEMS. Without manually setup? Why do you think I posted the setup in the previous post. With PP support techs, you will get different answers from different people. I have my own Obi202 with the special deal that was available thru Obi to function on PP on one line/port only for a reduced price. After multiple Obihai provisioning failures, we discovered that the issue lay with Obihai by defaulting my unit because PP did not provide a template for my unit. Why, I used my own Obi202. So, a real knowledgeable tech along with myself went through every parameter and got it functioning. After many more months of use, I also added more tweaks. I've had no problems whatsoever on 5898 or the current 5921 version. It does require manual tweaking. And, I've carried mu Obi unit while on travel, plugging into different routers, different locations thru ethernet routers, service works perfectly. Only had to change NTP time server ip address for accuracy.
Logged
Pages: 1 [2]
  Print  
 
Jump to:  

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