News:

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

Main Menu

Firmware 3.2.2 Build 5898) breaks PhonePower. Need to revert to 3.2.2 build 5757

Started by rl4265, July 12, 2018, 09:35:58 PM

Previous topic - Next topic

BenE

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.


KevKan

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.






madhouse

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

etta

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


Quote from: KevKan on August 13, 2018, 08:09:03 AM
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.

jman19

Quote from: KevKan 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.


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.

madhouse

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

Abestock

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.

madhouse

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!!!  :D

Abestock

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.

Abestock

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.

jman19

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?

Abestock

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.

civilmann

Hi all,
  Update on this topic with Firmware 3.2.2 (Build: 5932EX) updated with a recently registered Obi200 Via Obitalk portal. Polycom (Obihai) did this to my newly registered device before notifying me via email without my permission mind you. However, this did work out for me in the end. This device was set up with just Google Voice on SP1 via Obitalk. I added Phonepower to SP2 by hand using Obitalk portal. I used the settings from Abestolk (Posted Sept. 27 2018) as a guide. There are some twists and turns with it but is working now for 2 days without stacked registrations on Phonepower. Google Voice is also working as it should. I used a Digitmap supplied to me bay Phonepower tech support (Thanks To Vince @ Phonepower!) here it is:

(**|[3469]11|0|00|1xxxxxxxxxx|<1>[2-9]xxxxxxxxxS0|*21|*50xxxx|*51xxxx|*52xxxx|*53xxxx|*54|*6[013569]|*6[27]xx.|*77|*[789]2xx.|*73|*74[0-1][0-9]*xxxxxxxxxx|*75[0-1][0-9]|*8[137]|90xxxx|*93|*96|011xx.|xx.|(Mipd)|[^*#]@@.)

Long story short 4 days later and many hours with Phonepower tech support with some help via email and auto firmware updates from Obitalk. I now am the owner of an up-to-date device that works the way the old device with locked firmware  3.1.2 (Build: 5997) that had quit functioning with Phonepower then Google Voice then after a reset just Phonepower would work. If you have one of these older devices locked in at firmware3.1.2 (Build: 5997) reset it. It will still work great for Phonepower only. You cannot use it with Google voice and my firmware would never update via Obitalk. The lesson here is to have a backup device new on the shelf unregistered with Obitalk & backup your configurations often! I know this is a bit much but it is what it is ::). I have not used Abestock's star codes as I don't need them just use *21 with my Phonepower to retrieve my voicemail. Thanks to all the above mentioned each played a role. If this is not clear message me I'll try to help.

youbecha

I attempted the 27 sep setup.   My obi is at 3.2.2  , I didn't realize the phonepower was screwed up because incoming calls worked just fine.

So I attempted this step.

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

I can set the ITSP Provisioning to Disabled, and set all the other things in ITSP... after a reboot, the ITSP Provisioning is back to Periodic, and the Proxy addresses in the ITSP settings have changed back.

Any ideas?

drgeoff

The one you needed to disable and didn't was Obitalk provisioning. But many prefer to keep that enabled and make configuration changes using Expert mode on the portal.

youbecha

Fair enough,  but the ITSP settings as also specified, won't stay after the reboot.

Instead of 206.15.130.6  mine stays at sip.lax.phonepower.com  which might be the equivalent, but it is a different IP address...

Also the Outbound proxy stays at 12060.   The other settings either stay or were already there.

For grins, I updated to the latest FW, and no changes good or bad.

civilmann

Hey all, just to chime in on this. Make sure any setting you change from defaults is left unchecked (ie. no checks in Device defaults box or Obitalk Settings boxes) this should keep them in place after reboots!

Abestock

Quote from: civilmann on January 18, 2019, 07:28:26 PM
It will still work great for Phonepower only. You cannot use it with Google voice and my firmware would never update via Obitalk.

I don't get it. I'm on PP. I have SP1 using Phone Power. SP2, SP3 and SP4 are all on Google Voice, I have all 3 GV connected and functioning without any issues. That's 4 SP's working. Yes, once in a while I have to reboot due to Config not in sync. Otherwise, it's a workhorse with the AA feature working. Don't need any cellphone International plan. The Obi has saved me a ton of money. You have to create a SPECIFIC digit plan. The dialing plan that I have was created by me. The goal was to process calls as quickly as possible when an exact digit pattern was met, no timeout. Invalid sequences failed in the Obi, not the network.