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.