Hi All,
Any help would be greatly appreciated. It appears that both of my OBI 200s were updated automatically with software yesterday [3.2.1 (Build: 5794EX)]. After the update neither of my SIP phones will connect - found this way when I entered my office this evening. After research of forum see that updates to OBI 200 were pushed yesterday. My last call received on my phone was yesterday. I verified and current s/w seems to match. Both OBIs external lines are connected just fine (2 goggle voice and one Anveo). I am getting Failed(Authenticate) errors on Cisco phones. I have two OBI 200s with two lines each. I have Cisco SPA514G phones connected to them - I believe one line of each OBI to each phone (2 lines programmed on each phone). I have been using these without any trouble for years and have made no changes to config. I did try rebooting my router, phones and Obi devices with no resolution. Thanks in advance for any advice.
Wow. :( Did you happen to have a backup of the .xml config for the Obi's? You could make a new backup and then compare/diff it to the old one.
Quote from: BlakeN on January 21, 2018, 05:58:11 PM
Thanks in advance for any advice.
Not exactly a "fix" (just a workaround), but it seems that adding fw.obihai.com to your bind RPZ zone(*) (to prevent the device from updating) and then force loading one of the previous firmwares is a workaround for now. SIP phones work again.
We will have to wait and see if this was an accidental breakage that will be resolved with a further firmware update, whether one will be forced to stay on the older firmware (forever?), or whether one will need to investigate alternative solutions (other than the OBi devices).
(*) bind (named) RPZ zones can be used to block DNS requests for specific or generic targets. They are used by some to block lookup to known bad actors (or advertisement sources). As is typically the case, there are typically many ways to accomplish the equivalent thing, but when one is already using RPZ, it becomes an obvious choice in these cases.
Hi All,
Thanks for the ideas. I do have a backup. I set this up in 2015. I don't see any real differences in the configuration. Everything carried through. As I said I tried reseting passwords on both sides in case that did not carry through. Thats not saying there is some obscure setting somewhere. There are lots of parameters as you know. The XML formatting changed between exports in 2015 and now so the diff is a bit hard to read - meaning it is not easy to see the differences.
Is the November 3-2-1-5757 (10.4MB) version the one I want?
Can I blacklist fw.obihai.com in my router to accomplish the same thing? I am not familiar with RPZ zones.
Thanks for the help!
Same problem here. Something happened this weekend. My 202 is on firmware 3.2.1. and my SIP phone does not register anymore.
Quote from: BlakeN on January 22, 2018, 12:29:01 PM
Is the November 3-2-1-5757 (10.4MB) version the one I want?
The 5757EX version is working for me (I suspect the non-EX version works too, but I have not tested it).
Quote
Can I blacklist fw.obihai.com in my router to accomplish the same thing?
Individual routers vary in terms of their capabilities. Blocking the DNS name (in my case via RPZ) appears to work for me for now. Blocking the IP address probably would work too, but may or may not work long term (the DNS name may change to a different IP at some point). Removing the OBI from the portal entirely also reportedly works to prevent auto-firmware updates.
If one presumes that one only needs a temporary solution (i.e. OBi will address the issue), any solution is probably adequate for today (and sometimes it is all about the now).
Reverted to Nov 5757EX version and that solved the issue. It is goofy they both have the same version number. No config change needed. Just loaded software and it all came back to life. Now to see if my black list in my router firewall will keep software from updating again. Fingers crossed for now. Thanks again for the support. I sent in a support ticket to Obi. Hopefully they will resolve in new code.
hmmm - I got the "Your OBi device doesn't have a valid support coverage so we're unable to view anything further on this device." response. I sent a very nice reply even though after spending about 4 hours of my time troubleshooting this I was not real happy with the response. If one of you have a device under warrantee or have Premium support it may be worth putting a ticket in. It appears Obi may still not be aware of the issue.
Quote from: Blake4913 on January 22, 2018, 01:41:47 PM
hmmm - I got the "Your OBi device doesn't have a valid support coverage so we're unable to view anything further on this device." response.
Pretty sure that is the new normal response (close to reflexive?) for any device without a support contract.
Quote
It appears Obi may still not be aware of the issue.
Possibly. My guess (with zero evidence) is more likely that internal engineering is aware of it one way or another (as OBi once documented how to do the configuration (in a blog post long ago taken down) one would think they would expect some people were doing what they said to do), but that the support group has a policy to not invest support resources to even check unless you have a support contract.
If I had the time to invest (I certainly did not invest anywhere near 4 hours like you did) I might pay the $10 just to force a response, for $10 is less than two designer coffees.
Trust me - I thought about saying I would be happy to pay them $10 to fix it. I put this together about 3 years ago. It probably took me 2 hours just to remember what I had done even though everything was backed up and I had drawn diagrams and tables of IP addresses, etc. It sucks to get old. But hey, it is better than paying Verizon $70/month for a POTS line. Thanks again for your insight!!
Quote from: BlakeN on January 22, 2018, 04:23:18 PM
Trust me - I thought about saying I would be happy to pay them $10 to fix it.
There is the rub. Paying them $10 means they will answer the question, not that they will fix anything (everyone paying for service deserves an answer, sometimes the answer is no, and sometimes the answer is hell no).
[conjecture (zero value)]
I think some (including I) hope the answer will be another firmware update that restores the functionality they themselves documented, but times change, and perhaps that is no longer a supported configuration (in which case it would be nice if they said that, but they have no requirement to do so). That the blog entry was disappeared does raise an eyebrow, but given the complexity of the configuration (and I am guessing the support cost to help people work through it (that you and I and a few others managed it probably show the exception that proves the rule that it was not trivial)) that may have simply been a prudent business decision. Of course, OBiPLUS made it easy to configure one/two SIP phones. But they explicitly removed that too (at least for the "free" service).
[/conjecture]
Since the update I get the following on my phone log:
Registration failed User: xxxx, Error Code:480 Temporarily not available
Is there a log on the obi202 side?
Same issue with OBi 202 and 2 Polycom IP335 phones not registering. I made no change. Obi, what's the fix?
Same issue with OBi 202 and 2 Polycom IP335 phones not registering. I made no change. Obi, what's the fix?
What firmware was in your 202 before? I believe a couple of users reported they were able to (re) load 5757 to correct the issue. You may need to permanently remove the Obi from the portal to make the change "stick" though. If you remove it from the portal be sure and disaable all of the auto provisioning and disable obitalk.
Quote from: LarryDP on January 25, 2018, 08:32:03 PM
Obi, what's the fix?
OBi staff (at least in the general case) does not read/respond on this forum (yes, there are exceptions, but do not count on it).
If your device is still under a warranty or a support contract (or you are willing to pay the $10 fee to obtain a new contract) open a case to get some sort of formal response.
Or you can try to approaches reported to be successful earlier in this thread (although, as with all else, your results may vary).
FWIW (in case someone has an open ticket with OBi, and wants to send some addtional info), I took a look at the traffic on the wire (well, actually the logs).
It appears that the new firmware is responding to the first unauthenticated registration request with the expect 401 (not authenticated), asking for authentication with an interesting WWW-Authenticate string of the form:
WWW-Authenticate: Digest algorithm=MD5,nonce="37b7b4ad3BCEF40E",opaque="f66fc17e4fff9789",realm="pnn.obihai.com",nonce="5E7F538C",response="5E7F538C5E7F538C5E7F538C5E7F538C"
The old firmware replies with:
WWW-Authenticate: Digest algorithm=MD5,nonce="7fdddb54F4FF4579",opaque="5aafd8f577bcdc0d",realm="pnn.obihai.com"
Note that the new firmware is sending two nonces (which it really should not), along with a response value (which should not exist) which is just the second nonce value repeated 4 times. It would appear my SIP phone is replying using the second nonce value (which is arguably correct (use the last value, based on Postel's law))), but I am guessing the OBi is calculating the values with the first.
Anyway, I see a bug.
Great detective work looking at the WWW-Authenticate.
BTW, how did you guys downgrade? I went back to 3.1.1 (Build: 5774) but that did not resurrect my phone.
Did you have to reset to factory the 202 before the update?
Reverted to Build 5757 available at fw and problem solved. This doesn't say much for Obi QA and customer care that this has gone on for a week. Polycom needs to fix or I'll go elsewhere.
Quote from: LarryDP on January 29, 2018, 08:54:14 AM
This doesn't say much for Obi QA and customer care that this has gone on for a week.
Well, has anyone actually opened a support case with a supported (under contract) OBi? I have not (I don't have any OBi's under contract). You can't expect fixes if there are no open support tickets (and OBi seems to have been rather consistent recently in closing tickets with no further process if you do not have a valid support contract; even if they agree there is a bug (unknown), you don't prioritize such fixes if no one that is paying for support is asking for it).
As far as QA, from long experience, I know you that it is not atypical to tend to test in QA things that are normal/expected cases, and a few you think could be issues, and then tend to add things only later that you failed to test in the past and had caused issues with new releases. It is possible configuring an OBi with SIP phones was not in the test harness (it just worked). Perhaps they will add it to future QA testing.
And (to play devils advocate), if they do have a QA process, you can't expect a new release before the fixes have gone through QA. A week might be quick for their QA process (in the telco world an agile development methodology has not been typical).
Personally (again, since I have a fairly trival workaround) I am willing to wait for a few weeks with a possible new firmware update to see what happens before escalating.
Pretty sure that the (required) firmware upgrade for the new GV connectivity means preventing firmware upgrades for a OBi to support SIP phones has a short remaining viable lifetime (XMPP is dead, long live XMPP).
Anyway, I have opened a support ticket with OBi about the issue, and if I get any response I'll post it here.
<off topic and conjecture>
IFF the implications that were posted over on the GV support forum come to fruition, I can fantasize that it might be possible for SIP endpoints to directly connect to GV in the future (there was hints regarding standards compliance and that there may be ways for other solutions (*cough* asterisk? *cough*) to connect, but I would presume that may require an application password for the phones as many of the existing SIP phones are not going to be able to support OAUTH2). I guess we will see what happens (maybe some info will come out of I/O this week).
</off topic and conjecture>
Hi All,
I guess I did not do a good enough job blocking the updates. Took another auto update last night (5859EX) and lost my SIP phones again. It now looks like with the change to GV we will have to have new firmware. Anyone get any response to cases open or more information on how to solve this issue?
Thank you!
Quote from: BlakeN on May 10, 2018, 05:54:27 AM
Hi All,
I guess I did not do a good enough job blocking the updates. Took another auto update last night (5859EX) and lost my SIP phones again. It now looks like with the change to GV we will have to have new firmware. Anyone get any response to cases open or more information on how to solve this issue?
Thank you!
Explain what you mean by your "SIP phones."
If your IP phone can call without registration, just uncheck X_Proxy.
Inbound calls can't be routed to local_client, use the IP address of the phone.
Quote from: LTN1 on May 10, 2018, 06:05:32 AM
Explain what you mean by your "SIP phones."
Cisco SPA514G - I have two Obi 200s (one with Anveo 911 and GV) the other with just GV. Two Cisco SIP phones run lines off each Obi 200. See first post - issue occurred in Jan.
Quote from: azrobert on May 10, 2018, 06:12:31 AM
If your IP phone can call without registration, just uncheck X_Proxy.
Inbound calls can't be routed to local_client, use the IP address of the phone.
Thanks for the response. Where does the IP address of the phone go?
Change the X_InboundCallRoute of your provider to:
ph,spx(AuthUserID@xx.xx.xx.xx:port)
spx is the SP number where X_Proxy was checked
AuthUserID is the Auth UserID of the Cisco phone
The rest is the IP and port of the phone
You don't need ":port" if the port is 5060
I've played with X_Proxy yesterday and Softphones Phonerlite on a PC and Zoiper on a smart phone register to my OBi200, but CsipSimple on an Android and an OBi110 fail.
Quote from: azrobert on May 10, 2018, 06:36:30 AM
Change the X_InboundCallRoute of your provider to:
ph,spx(AuthUserID@xx.xx.xx.xx:port)
spx is the SP number where X_Proxy was checked
AuthUserID is the Auth UserID of the Cisco phone
The rest is the IP and port of the phone
You don't need ":port" if the port is 5060
I've played with X_Proxy yesterday and Softphones Phonerlite on a PC and Zoiper on a smart phone register to my OBi200, but CsipSimple on an Android and an OBi110 fail.
Thanks for the details. Does not seem to work for me. Made changes and also on the Cisco phone side changed register to no and make and Rx calls without reg to yes. I get green on the line but fast busy when trying to dial.
Anyone have the firmware 5757EX for Obi200? I have seem to lost it and the Obi site does not seem to be responding.
To BlakeN: I have 5757EX. PM me and I can send you a link. I thought Obi fixed it so you can't downgrade but I've never tried.
Quote from: BlakeN on May 10, 2018, 07:37:14 AM
Anyone have the firmware 5757EX for Obi200? I have seem to lost it and the Obi site does not seem to be responding.
Just download it:
fw.obihai.com/OBi202-3-2-1-5757EX.fw (http://fw.obihai.com/OBi202-3-2-1-5757EX.fw)
The fast busy indicates the call is getting to the OBi200, but is not getting routed to your provider.
The same routing should work whether the phone is registered or not.
Temporarily change the X_InboundCallRoute to: ph
This should cause the phone port to ring.
This test is to check if the call is getting to the OBi200.
Before making this change please post the X_InboundCallRoute of the dummy trunk.
You can't downgrade the firmware. You get a checksum error.
Quote from: azrobert on May 10, 2018, 08:04:48 AM
You can't downgrade the firmware. You get a checksum error.
Thanks for confirming this, azrobert. I was afraid to even try as both of my OBi200s are working perfectly with 3.2.2 (Build: 5859EX).
Did you make any changes to block scanners, access list or block unregistered calls?
Quote from: azrobert on May 10, 2018, 08:04:48 AM
The fast busy indicates the call is getting to the OBi200, but is not getting routed to your provider.
The same routing should work whether the phone is registered or not.
Temporarily change the X_InboundCallRoute to: ph
This should cause the phone port to ring.
This test is to check if the call is getting to the OBi200.
Before making this change please post the X_InboundCallRoute of the dummy trunk.
You can't downgrade the firmware. You get a checksum error.
Turns out I have two problems. One of my GV numbers after the upgrade is not registering properly - comes up with connecting to an IP address. The other one after changes above received inbound calls (did not realize until my wife called) but fast busy on outbound. Will work to debug.
On other question - don't remember changing any of those - where are they buried in the config?.
I am getting invalid number on the Cisco phone along with fast busy when dialing. Are the dialing rules bypassed for some reason with the new settings? I tried 7,10 and 11 digit dialing and all gave same invalid number.
Thanks again for the help.
I'm tired of saying "The trunk where you had X_Proxy checked", so I'm assuming it's SP4.
The routing rules will be in the SP4 X_InboundCallRoute.
It should look something like:
{userid>(Msp1):sp1}
The userid is optional and must match the phone's userid. This is really for security. The (Msp1) is to validate the outbound number and is also optional.
You could change the sp4 inbound route to ph or sp1
ph will send the call to the OBi200 phone port. You don't need to have a phone attached to determine if it's ringing, the phone LED will flash.
sp1 will route the call with the outbound number unchanged to sp1.
When you send the call to the phone port, a call history entry will be created and you can see if the phone is using a different userid when unregistered.
Same with sp1, but an entry won't be created if it's not connected to GV.
I "think" the stuck in "Connecting" is a Google server problem. I'm having the same problem after a reboot. Just try another reboot. A power cycle might work better.
SP4 is a good example - that is the phone / line I am using to debug
Works fine for inbound calls PSTN to GV to (SP1) Obi200 (SP4) to Cisco phone line 2 (user 1002)
Here is my config for SP4 X_InboundCallRoute {1002>911|933:sp2},{1002>(Msp1):sp1}
Replace with {1002>Ph} and still fast busy and no call history
Even tried to dial 933 - same outcome
On the other issue - tried unplugging and replugging in device / reconfiguring through Obi Dashboard and still have - Connecting to 64.9.242.172 in status and no inbound calls on that GV line
Thanks again for the help
Oh - and about pulled what little hair I have left out before I remembered that call log is only available when you log directly into the device. I guess I am getting too old to try to dive into this stuff only once a year. The memory is not what it use to be and I have a nice map drawn out.
Is it possible that when new GV upgrade is rolled out we can connect direct from SIP phone?
Quote from: BlakeN on May 10, 2018, 02:12:36 PM
SP4 is a good example - that is the phone / line I am using to debug
Works fine for inbound calls PSTN to GV to (SP1) Obi200 (SP4) to Cisco phone line 2 (user 1002)
Here is my config for SP4 X_InboundCallRoute {1002>911|933:sp2},{1002>(Msp1):sp1}
Replace with {1002>Ph} and still fast busy and no call history
Even tried to dial 933 - same outcome
On the other issue - tried unplugging and replugging in device / reconfiguring through Obi Dashboard and still have - Connecting to 64.9.242.172 in status and no inbound calls on that GV line
Thanks again for the help
Oh - and about pulled what little hair I have left out before I remembered that call log is only available when you log directly into the device. I guess I am getting too old to try to dive into this stuff only once a year. The memory is not what it use to be and I have a nice map drawn out.
Is it possible that when new GV upgrade is rolled out we can connect direct from SIP phone?
If your 200 series device(s) has/have firmware 5859EX or higher, and you are using Google Voice, then your Google account has been converted to use Google's new infrastructure. You can't go back, and you can't down-level the firmware. There are various reports of problems (e.g. no audio on one or the other or both directions, or server connection problems). So far, a few bugs have been identified and fixed, including one fixed yesterday. It's difficult to identify the root cause of a problem, given that this is a moving target, and the universe of devices being updated includes many that have been user-modified locally.
I see an assortment of issues reported today, but no clear pattern. The previous users' issues have mainly been caused by user modifications to their device configurations. So, it's worthwhile, if you can't figure out your issue, to just factory-restore the device and start over, and stick with the defaults loaded by OBiTALK until you get it working, and optionally make changes later.
No, the Google Voice upgrade does not enable connecting to any non-OBi SIP phones.
Quote from: BlakeN on May 10, 2018, 08:52:29 AM
The other one after changes above received inbound calls (did not realize until my wife called) but fast busy on outbound. Will work to debug.
Try unchecking X_EnforceRequestUserID under SIP Credentials.
:o Wow
So I have two Obi 200s and 2 GV lines. One is our home phone. Connected to a traditional cordless system. It still works great. Because I have two SIP phones and 911 service I actually have both 200s connected to the same GV account. Both are connected just fine. With some coaching from the great people on this forum I have inbound calls from that same line to my SIP phones (no love on outbound dialing).
The second GV line is for me. It routes to only one 200 but connects to both sip phones. It will not connect to GV at all.
So here is the real kicker. I have been debugging an ugly echo problem that is very intermittent (posted in GV area). I got a message from somewhere that prime members get a great deal on a 1062. I can use it to help troubleshoot my issue and have a phone to take to my folks house when I am there. So it arrived this evening. Out of the box no modes, no expert mode, just Obi dashboard config of GV accounts. No love on either GV account. It is giving me the backing off message. I am betting your going to tell me that the firmware for the 1062 does not support the new GV connection yet.
And they ask me why I drink? :)
Quote from: Taoman on May 10, 2018, 05:25:47 PM
Try unchecking X_EnforceRequestUserID under SIP Credentials.
Still no love. It does give me a new message on the phone. Service not available. Inbound calls still work.
Thanks for the idea.
Quote from: Blake4913 on May 10, 2018, 05:39:35 PM
:o Wow
So I have two Obi 200s and 2 GV lines. One is our home phone. Connected to a traditional cordless system. It still works great. Because I have two SIP phones and 911 service I actually have both 200s connected to the same GV account. Both are connected just fine. With some coaching from the great people on this forum I have inbound calls from that same line to my SIP phones (no love on outbound dialing).
The second GV line is for me. It routes to only one 200 but connects to both sip phones. It will not connect to GV at all.
So here is the real kicker. I have been debugging an ugly echo problem that is very intermittent (posted in GV area). I got a message from somewhere that prime members get a great deal on a 1062. I can use it to help troubleshoot my issue and have a phone to take to my folks house when I am there. So it arrived this evening. Out of the box no modes, no expert mode, just Obi dashboard config of GV accounts. No love on either GV account. It is giving me the backing off message. I am betting your going to tell me that the firmware for the 1062 does not support the new GV connection yet.
And they ask me why I drink? :)
The 1062 certainly supports everything the 200/202 models do (except for an analog RJ-11 phone jack, of course). This includes full support for up to six Google Voice accounts.
Your device has been sitting in a warehouse for a long time. You just need to follow the **5 xxxx procedure to add it to the OBiTALK web portal. When you do that, after some time, it will automatically upgrade to the new Google Voice firmware.
As of today, the 1000 series should be at version 5.1.11 (Build: 4858EX.1311) or higher.
Before making any custom changes to any parameters at all, just add it to OBiTALK and walk through the standard Google Voice setup for each SPx you want to use with Google Voice.
Quote from: SteveInWA on May 10, 2018, 05:50:08 PM
The 1062 certainly supports everything the 200/202 models do (except for an analog RJ-11 phone jack, of course). This includes full support for up to six Google Voice accounts.
Your device has been sitting in a warehouse for a long time. You just need to follow the **5 xxxx procedure to add it to the OBiTALK web portal. When you do that, after some time, it will automatically upgrade to the new Google Voice firmware.
As of today, the 1000 series should be at version 5.1.11 (Build: 4858EX.1311) or higher.
Before making any custom changes to any parameters at all, just add it to OBiTALK and walk through the standard Google Voice setup for each SPx you want to use with Google Voice.
Thanks for the feedback. Done and done. This is like my 4th or 5th Obi device along with SIP phones - been doing this since google shut things back on years ago. One of the selling points of the 1062 is that I did not need to spend my life in the expert config. Current code on phone is 5.0.6 and it says when I select the update on the phone that there is no update available. Phone has been on and sitting there for a couple of hours with no update. I am calling it quits for the day. I will dream of firmware downloads that fix all my problems.
Quote from: BlakeN on May 10, 2018, 02:12:36 PM
Here is my config for SP4 X_InboundCallRoute {1002>911|933:sp2},{1002>(Msp1):sp1}
Try this:
{>911|933:sp2},{>(Msp1):sp1},{ph}
Build 5859 supports GV on both XMPP and SIP, although there is no way to define a new GV account as XMPP. I did not wait for my OBi200 to be automatically updated. I downloaded 5859EX and manually upgraded my OBi200. 5859EX is no longer available for download. Both GV accounts on my OBi200 did not convert to SIP, but both connected. One account was switched to SIP when I deleted and redefined it. The OBi200 now had one account as SIP and the 2nd as XMPP. I verified this 2 ways. The 1st account showed as OBiTalk device in GV list of forwarding numbers and the 2nd as Google Chat. I sent an SIP URI call to the 1st account on the OBi200 and it was successful, but the same call sent to the 2nd account was rejected. I have since converted the 2nd account to SIP.
A GV account that has been converted to SIP will also connect to XMPP. I have the same GV account defined on an OBi200 as SIP and on an OBi110 as XMPP. Both are connected and working.
Quote from: azrobert on May 10, 2018, 06:35:18 PM
I have the same GV account defined on an OBi200 as SIP and on an OBi110 as XMPP. Both are connected and working.
You're getting
incoming GV calls on your OBi110? Since you can no longer forward to Google Chat how is that possible? I knew outgoing still worked.
Quote from: Taoman on May 10, 2018, 07:00:32 PM
Since you can no longer forward to Google Chat how is that possible? I knew outgoing still worked.
You are correct. Only outbound OBi110 works, not inbound. I'm routing inbound from my OBi200 to the OBi110. When OBi110 outbound stops working, I'll route outbound to the OBi200.
Quote from: azrobert on May 10, 2018, 06:10:51 PM
Try this:
{>911|933:sp2},{>(Msp1):sp1},{ph}
Same outcome - fast busy / service unavailable (If I click back on X_EnforceRequestUserID error changes to Invalid number)
Try this:
SP4 X_InboundCallRoute: ph
When you make a call, does the OBi200 phone port ring?
If the phone doesn't ring, the call isn't getting to the OBi200 and I don't know why.
Do not do the following steps,
If the phone rings, do the following:
SP4 X_InboundCallRoute: sp4($1@192.168.1.99)
Dial a number on the IP phone, wait a few seconds and hang up.
You will not hear anything after dialing the number.
Now do this:
SP4 X_InboundCallRoute: sp4($2@192.168.1.99)
Make another call for a few seconds.
$1 contains the IP phone's userid and $2 the outbound number.
You should be able to see these in the OBi200 call history.
To access Call History:
Log directly into the OBi using the local interface.
Key the IP address of the OBi into a Web Browser and hit Enter
The UserID and default Password are both "admin".
Click Status on the left column then click Call History.
What does the call history show for those calls?
Obi 200 here. Was converted to new firmware several days ago.
My problem is this:
Inbound calls, my cordless phone rings once and then stops. The caller on their end is hearing a type of "number not in service" message.
I have no problem making outbound calls, I get a dialtone and everything works normally.
My GV status shows as connected on the Obitalk dashboard.
Any ideas?
Quote from: lottamoxie on May 11, 2018, 05:33:15 PM
Obi 200 here. Was converted to new firmware several days ago.
My problem is this:
Inbound calls, my cordless phone rings once and then stops. The caller on their end is hearing a type of "number not in service" message.
I have no problem making outbound calls, I get a dialtone and everything works normally.
My GV status shows as connected on the Obitalk dashboard.
Any ideas?
Hi there:
The "...not in service..." message takes a bit of problem isolation to determine what's wrong.
Using a desktop/laptop computer's web browser, sign into your Google / Gmail account and then go here:
https://voice.google.com/settings (https://voice.google.com/settings)
Delete all the linked telephone numbers off of the list. Turn on "do not disturb" mode. Call your inbound Google Voice phone number from some other phone number. What happens, exactly? The expected behavior is that the caller will be immediately sent to your Google Voice voicemail greeting.
Quote from: azrobert on May 11, 2018, 08:58:27 AM
Try this:
SP4 X_InboundCallRoute: ph
When you make a call, does the OBi200 phone port ring?
If the phone doesn't ring, the call isn't getting to the OBi200 and I don't know why.
Do not do the following steps,
If the phone rings, do the following:
SP4 X_InboundCallRoute: sp4($1@192.168.1.99)
Dial a number on the IP phone, wait a few seconds and hang up.
You will not hear anything after dialing the number.
Now do this:
SP4 X_InboundCallRoute: sp4($2@192.168.1.99)
Make another call for a few seconds.
$1 contains the IP phone's userid and $2 the outbound number.
You should be able to see these in the OBi200 call history.
To access Call History:
Log directly into the OBi using the local interface.
Key the IP address of the OBi into a Web Browser and hit Enter
The UserID and default Password are both "admin".
Click Status on the left column then click Call History.
What does the call history show for those calls?
With forcing user ID unchecked call does get to OBI. I get the following in the call log. I have not had any time to further debug. I will try your suggestion above when I have time (It has been a busy weekend).
Call 1 05/11/2018 11:06:16
11:06:16 From SP4(1002) To SP1(1234567890)
11:06:18 Call Ended (488 Not Acceptable Here)
BTW - I put a ticket in on the 1062 - no upgrade of code and no GV. They upgraded code and now both GV on 1062 seems to work. They said to delete and add the GV one on the 200 that would not connect. It still does not work - same connecting to 63.9.242.172.
Thanks again for the help
Quote from: BlakeN on May 12, 2018, 01:36:07 PM
I will try your suggestion above when I have time (It has been a busy weekend).
Don't bother doing those tests. Your call history shows everything is being routed correctly. I don't know why you're getting the 488 error. Can you make a call from the phone port?
Quote from: azrobert on May 12, 2018, 01:53:55 PM
Quote from: BlakeN on May 12, 2018, 01:36:07 PM
I will try your suggestion above when I have time (It has been a busy weekend).
Don't bother doing those tests. Your call history shows everything is being routed correctly. I don't know why you're getting the 488 error. Can you make a call from the phone port?
yes, the phone port works great in both directions. Probably would be hard to sell devices if it did not. There is likely no incentive for Polycom to allow a Cisco phone to work or any SIP phone for that matter. I submitted a ticket and included all three of my issues. They jumped right on the 1062 issue (its fixed), tried to give some advice on the one 200 that won't connect to GV (no luck to fix) and ignored the SIP phone issue. Even gave the issue that one of the others in this chain figured out by sniffing the packets.
It seems the 488 error is a codec problem.
See:
https://supportforums.cisco.com/t5/ip-telephony/message-sip-with-488-not-acceptable-here/td-p/2077189
The link suggests forcing G711a, but I know GV works with G711u. I checked my OBi200's codec profile and the G711a codec is disabled. I don't remember if I disabled it. Check which codec profile your GV is using then see whether any codecs in that profile are disabled. See if you can force G711u in your Cisco phone.
Quote from: azrobert on May 13, 2018, 07:22:27 PM
It seems the 488 error is a codec problem.
See:
https://supportforums.cisco.com/t5/ip-telephony/message-sip-with-488-not-acceptable-here/td-p/2077189
The link suggests forcing G711a, but I know GV works with G711u. I checked my OBi200's codec profile and the G711a codec is disabled. I don't remember if I disabled it. Check which codec profile your GV is using then see whether any codecs in that profile are disabled. See if you can force G711u in your Cisco phone.
Thanks - I goofed with it a bit and setting Use Pref Codec Only to yes in the Cisco phone seemed to solve the issue. I tried it with both G711u and G711a as the preferred vocoder - both worked. In my 200 config I have both 711 codecs enabled, G729 and G726R32 enabled. I tried to disable G711a and that did not solve issue.
I will work with my other phones/lines and try to document all changes to enable working SIP phone with latest connection.
BTW - what are the down sides to not having registration? I assume you don't know if the 200 dies until you try to pick up the phone and dial?
Quote from: Blake4913 on May 13, 2018, 04:41:29 PM
There is likely no incentive for Polycom to allow a Cisco phone to work or any SIP phone for that matter.
If this was a request for a new feature, I would have no reason to have believed that Obihai would invest in development to add it. In this case, however, some changes broke a capability that Obihai, themselves, documented. Hanlon's razor suggests it is a bug introduced accidentally (perhaps due to other changes, such as support for the GV changes?). An alternative is that violating RFC specified authentication process was introduced intentionally to break downstream SIP clients. Only Obihai knows for sure, and as you say, they have so far not even answered the question(s).
Quote from: BlakeN on January 22, 2018, 04:23:18 PM
Trust me - I thought about saying I would be happy to pay them $10 to fix it. I put this together about 3 years ago. It probably took me 2 hours just to remember what I had done even though everything was backed up and I had drawn diagrams and tables of IP addresses, etc. It sucks to get old. But hey, it is better than paying Verizon $70/month for a POTS line. Thanks again for your insight!!
So: this thread is about five months old and three pages long, and you're still trying to experiment with those Cisco phones. Think of how much time you've spent so far. Are you employed? If so, how much is your time worth per hour? You could have bought a case of OBi IP phones by now for that much money. I know people love to experiment and mod stuff, be it cars, boats, musical instruments, or whatever, but I can think of better things to do than play with old, discontinued, ugly-UI Cisco phones.
Clearance sale:
https://smile.amazon.com/Obihai-Gigabit-Phone-Built-Bluetooth/dp/B00TEFGVD2/ref=sr_1_1?ie=UTF8&qid=1526348107&sr=8-1&keywords=obi+1062 (https://smile.amazon.com/Obihai-Gigabit-Phone-Built-Bluetooth/dp/B00TEFGVD2/ref=sr_1_1?ie=UTF8&qid=1526348107&sr=8-1&keywords=obi+1062)
Quote from: SteveInWA on May 14, 2018, 06:36:09 PM
So: this thread is about five months old and three pages long, and you're still trying to experiment with those Cisco phones. Think of how much time you've spent so far. Are you employed? If so, how much is your time worth per hour? You could have bought a case of OBi IP phones by now for that much money. I know people love to experiment and mod stuff, be it cars, boats, musical instruments, or whatever, but I can think of better things to do than play with old, discontinued, ugly-UI Cisco phones.
So, first let me say that Obi has been good to me. They created a fantastic product and have evolved it over time. Not sure about Polycom but I am starting to get the picture.
So, I did buy a 1062 and so far I am not feeling the ease of configuration. I had to submit a ticket to get it upgraded to the latest code so that it would connect to GV (it would not upgrade). Even thought I put in a very recognizable label for GV it shows on the phone as some long string of characters. I attached my iPhone to the phone in hopes to download my contacts. Said yes to the allowing access to my contacts but no download. It is not intuitive on how to add my iPhone to line key so that I can use it as a speakerphone for my iPhone. I have spent some time with the manual but not feeling any savings in time so far. Is there a quick start configuration guide somewhere that I am missing?
So, for several years I have been using the Cisco phones with no issues. The investment was outstanding. A few bucks to Anveo, the hardware (which you needed anyway other than the Obi200) and no need to pay Verizon big money each month for antiquated service. The Cisco phones are solid (Fantastic speaker phone and super durable and a simple straight forward UI). So, in January Obi or Polycom forced my unit to upgrade software and broke my system. I downgraded code and went back to my life. Last week it happened again and low an behold this time someone figured out a way to ensure that you can't downgrade and maybe tossed in a new bug with the codec. So, by incompetence or plan he we are.
So, sure I am willing to shell out some bucks for a couple of 1062s to replace my Cisco phones but give me some motivation. Convince me they are easier to configure, new and better features and they won't be orphaned by Polycom or rendered useless by a forced software upgrade.
BTW - why is the 1062 on "clearance"
So, yes I have a job and yes I am a geek and kind of like doing some of this stuff. But I rather be fishing.. ;D
Hi All,
To make it easier to follow I have tried to document the items I changed in one place for the Obi 200 work around for SIP phone connectivity issues with latest code (2 issues - registration bug & codec issue). It appears that the registration issue was introduced in Jan and I am making an educated guess the codec issue in this latest release (I am making a leap here as others are complaining of no outbound calling but inbound still works).
I am coming from 5757EX and as of last week was updated automatically to 5859EX. As of 5757EX I had Obi 200 with GV line and Cisco SPA514G SIP phone that worked perfectly with registration and no forced codec.
For reference I have GV coming in on SP1 and my SIP phone on SP4.
To work around the registration issue we are basically not requiring registration:
On Obi200 SP4 or the SPX service connected to the SIP phone
Uncheck X_RegisterEnable
Uncheck X_EnforceReguestUserID
Uncheck X_Proxy
For X_InboundCallRoute take out reference to user ID
Mine had {1002>(Msp1):sp1}
I changed to {>(Msp1):sp1}
On Obi200 SP1 or the SPX service connected to GV
For X_InboundCallRoute add @IPaddr:SIP port where the IP address is the IP address of the SIP phone/line and the SIP port
Mine had {sp4(1002)}
I changed to {sp4(1002@192.168.4.50:5064)}
On Cisco SIP phone using admin advanced login on the line tab that is connected to SP4
Change Register to No
Change Make Call Without Reg to yes
Change Answer Call Without Reg to yes
To work around the codec issue I am forcing the Cisco IP phone to only use one codec (in my case the G711u):
On Cisco SIP phone using admin login on the line that is connected to SP4
Change Use Pref Codec Only to yes (note that In the 3 slots for preferred codecs I only have the first filled in with G711u)
I assume there are downsides to this configuration over what I had. If you have a connectivity failure or your Obi devices fails I do not believe you will know that until you pick up the phone and dial a number. I am not sure there is any downside to forcing only one codec.
Thanks again to azobert, Taoman and SteveInWA efforts in helping me stumble through putting this workaround.
I know, old topic..but just wanted to know that this procedure still works.
For reference, I did the "OBi-VoIP-Device-Attach-Legacy-IP-Phone-Workbook-v1-0.pdf" procedure.
I have an Obi200 and a Cisco SPA504G. I followed the PDF directions using option two (for any Obi).
Then I found this thread and changed the appropriate things.
Only mistake I made was before I found this article...and deleted the entry in Ext4>Dial Plan... so I don't know what the default is...but I put "xx." (minus quotes) from the first attempt (prior to the PDF procedure).
It dials out and rings with inbounds...so as far as I am concerned...it is a win!