I just signed up for the Google Voice Gateway on simonics.com and am having trouble getting it to work on my Obi110.
I did all the steps on the pinned post on this forum, and Obitalk is reporting "Register Failed: 401 Unauthorized"
I see under account status on simonics.com that my GV account isn't connecting:
Google Voice account Offline. Register a device or SIP URI.
Devices registered 0
What should I do? I appreciate any help.
If you were able to use your Google Voice/Gmail user ID and password to authenticate on the Simonics GVGW website, and you got to the end of that website's setup, then it should work per my sticky post. This would be indicated by the green check mark next to the words "Google Voice account authorized." The web page must also show "Online" status. Did you click the button to change from offline to online?
Look again at the password on that page. It's possible you clicked the "Regenerate" button to change the password, and then refreshed the page, which may unintentionally change the password again. Type the exact, case-sensitive password into the form on OBiTALK.
Steve, thanks for the quick reply. I appreciate it.
I double checked the password, refreshed, and then copied it exactly -- same error.
I do have the green checkmark on the Simonics page that indicates "Google Voice account authorized." However, Under account status it still says that my Google Voice account is "offline." Where is the button to change its status? I can't find it on that page and I can't find it on the OBiTALK form.
Quote from: TimAtHome on November 11, 2017, 06:16:58 AM
Steve, thanks for the quick reply. I appreciate it.
I double checked the password, refreshed, and then copied it exactly -- same error.
I do have the green checkmark on the Simonics page that indicates "Google Voice account authorized." However, Under account status it still says that my Google Voice account is "offline." Where is the button to change its status? I can't find it on that page and I can't find it on the OBiTALK form.
I don't have that button:
(https://i.imgur.com/PjO4Olx.jpg)
So it seems like I need to register my device -- how and where do I do that?
Many thanks!
Quote from: TimAtHome on November 11, 2017, 07:44:05 AM
So it seems like I need to register my device -- how and where do I do that?
Hi Tim, it means configuring your SIP device (Obi) to register, which is part of SteveInWA's guide. Please double check your settings and note that the passwords we issue are 12 characters long so if you count 13 characters you may have grabbed a space or tab in copy/paste.
Once your device registers with GVGW you will see a status showing Devices Registered: 1 and an Online button, which you can also use to temporarily disconnect the GVGW from your Google Voice account (it just logs you out).
Checked the password again, still no go. Steve's guide is so simple, and it should be so easy, so I'm having a hard time seeing where I could be doing something wrong. So I wonder if maybe the problem has to do with the initial information that I entered -- my Simonics SIP login is my GV number. It's on SP1 and I don't have an x1 after it. Is that correct, or should that be my OBI number or something else? I have the latest 2886 firmware.
The user ID is GV1.......... filling in the dots with the rest of your GV number.
Yes, that's what I have. Still have "Register Failed: 401 Unauthorized" status on my OBI, and on the Simonics page it says "Offline. Register a device or SIP URI."
I have the exact same problem with OBI100
I hope an expert here can help figure this out. It's so strange, I've gone through the exact steps of the pinned post over and over again, to no avail. Rebooted the OBI, also manually removed power and rebooted, and rebooted my modem. Still the same error.
I know it is very unlikely that you made this error but just in case.
The proxy is g v g w . s i m o n i c s . c o m
I've put spaces between every character to highlight that the 4th character is a single 'w'. it is not a pair of 'v' s. Some fonts show little difference between w and vv.
Also if not doing a copy and paste of the password, are you falling foul of the classic 0/O and 1/l confusion?
And you guys are definitely entering the SIP login and SIP password located on the Simonics page under "YOUR SIP SETTINGS?" You're not using your Google Voice password by any chance?
"401 Unauthorized" suggests you're using the wrong SIP credentials.
I do not want to overcomplicate the situation, but there is another possibility that comes to mind. If you have never used the Obi with a SIP service before (only direct Google Voice), it is possible that something on your network or your ISP is interfering. Often this is called "SIP ALG" or "SIP Helper" and is no help in this case. You can try connecting to GVGW over TLS or alternate port 5070 UDP or TCP.
That said, it's still more likely the problem is somewhere in your Obi config. Be sure you don't have any other proxies defined except "gvgw.simonics.com"
As you can see from all the replies, including from Bill Simon himself, this isn't complicated; it's just a few basic values to enter on a form. If you have entered those values correctly, then it should simply work.
This week, I fixed another user's issue that was similar to this one, but with a different SIP service provider. It turned out that there was some sort of left-over configuration junk in his OBi that was interfering with trying to configure the new SIP SP information.
I suggest doing this:
Log onto the OBiTALK web portal. Delete the OBi completely off of the portal. Wait a few minutes while the portal remotely reboots the device. Unplug the power and Ethernet cables. Plug in just the power cable and let it boot up. Then, key in ***8 then 1 to reset it to factory defaults. After it gyrates and reboots a couple of times and the LEDs become stable, plug in the Ethernet cable, and use the **5 procedure to add it back to the portal, skip the invitation to set up Google Voice, and scroll down to the bottom of the page. Click the "OBiTALK Compatible Service Providers" link. On the next page, enter your SIP information, and see if it works.
Quote from: billsimon on November 11, 2017, 02:18:45 PM
I do not want to overcomplicate the situation, but there is another possibility that comes to mind. If you have never used the Obi with a SIP service before (only direct Google Voice), it is possible that something on your network or your ISP is interfering. Often this is called "SIP ALG" or "SIP Helper" and is no help in this case. You can try connecting to GVGW over TLS or alternate port 5070 UDP or TCP.
That said, it's still more likely the problem is somewhere in your Obi config. Be sure you don't have any other proxies defined except "gvgw.simonics.com"
I have on SP2 Callcentric configured (for incoming calls only), but it uses a proxyserver on port 5060 too. The two configuration pages are almost identical and the one from Calcentric works.Does this prevent GVGW from working?
Quote from: AntonS on November 11, 2017, 06:55:15 PM
Quote from: billsimon on November 11, 2017, 02:18:45 PM
I do not want to overcomplicate the situation, but there is another possibility that comes to mind. If you have never used the Obi with a SIP service before (only direct Google Voice), it is possible that something on your network or your ISP is interfering. Often this is called "SIP ALG" or "SIP Helper" and is no help in this case. You can try connecting to GVGW over TLS or alternate port 5070 UDP or TCP.
That said, it's still more likely the problem is somewhere in your Obi config. Be sure you don't have any other proxies defined except "gvgw.simonics.com"
I have on SP2 Callcentric configured (for incoming calls only), but it uses a proxyserver on port 5060 too. The two configuration pages are almost identical and the one from Calcentric works.Does this prevent GVGW from working?
Follow my instructions above to factory reset your OBi and start over. Use the OBiTALK portal's "OBiTALK Compatible Service Providers" tool to configure a generic service provider for SP1 for the GVGW, and then use the same portal configuration tool to set up Callcentric on SP2, using the Callcentric template. It should make the settings you need.
Unfortunately, I am doing this remotely, so removing the unit from ethernet and obitalk portal doesn't seem an option. Any other options, as it might be several weeks before I get to the unit.
Quote from: AntonS on November 13, 2017, 07:27:47 AM
Unfortunately, I am doing this remotely, so removing the unit from ethernet and obitalk portal doesn't seem an option. Any other options, as it might be several weeks before I get to the unit.
Ten minutes or less, with a helper in front of the remote OBi, will solve this.
Steve,
Success! Following your instructions for a complete factory reset has gotten my Obi to work with Simonics. Thanks so much -- I had just about given up on it. But I'm online and working.
I noticed that caller ID gives a number in Washington state now. Can that be overrided or is this what happens when you use the service?
Also, I'm unable to get 7-digit dialing to work. I put in my area code in the box for "7-Digit Dialing for USA & CAN" and it doesn't work -- I've got to dial 1+NPA+xxx-xxxxx even for local calls.
Under the DigitMap for ITSP Profile A, it has the recipe for 7-digit dialing (in this example, a 312 NPA):
(1xxxxxxxxxx|<1312>[2-9]xxxxxxxxx|011xx.|xx.|(Mipd)|[^*#]@@.)
Quote from: TimAtHome on November 13, 2017, 02:14:49 PM
Steve,
Success! Following your instructions for a complete factory reset has gotten my Obi to work with Simonics. Thanks so much -- I had just about given up on it. But I'm online and working.
I noticed that caller ID gives a number in Washington state now. Can that be overrided or is this what happens when you use the service?
Also, I'm unable to get 7-digit dialing to work. I put in my area code in the box for "7-Digit Dialing for USA & CAN" and it doesn't work -- I've got to dial 1+NPA+xxx-xxxxx even for local calls.
Under the DigitMap for ITSP Profile A, it has the recipe for 7-digit dialing (in this example, a 312 NPA):
(1xxxxxxxxxx|<1312>[2-9]xxxxxxxxx|011xx.|xx.|(Mipd)|[^*#]@@.)
The GVGW is providing the caller ID name service (CNAM). CNAM, in general, depends on telephone service providers/carriers to feed their customers' names into the CNAM databases (LIDB). There is a cost to the service providers to use the LIDB. Many VoIP ITSPs don't do that. Some mobile carriers do, and some don't. Google Voice doesn't. So, the LIDB is full of missing information. When that's the case, the CNAM service sends a generic "name", based on the geographic location of that telephone number's rate center (local telephone exchange). So, that's what you are seeing, and no, you can't fix it.
I'll let the digit map gurus discuss the 7-digit dial options. However, I'll point out that more and more locations are now requiring 10-digit dialing, because the original area code(s) was/were depleted, and "overlay" area codes were added, making 7-digits ambiguous. Calls from mobile phones typically need 10 digits. So, you might as well get used to it.
Thanks for the quick reply, Steve. I think these things should be mentioned in the FAQ because this will probably affect people's decisions on whether or not they want to make the switch. People who recognize my caller ID when I call are not going to know it's me when I'm calling.
The 7-digit thing is a pretty big annoyance. I was hoping that there was a digit map fix that would get it working again. Being able to program all this is basically the Obi's big selling point.
Quote from: TimAtHome on November 13, 2017, 02:33:53 PM
Thanks for the quick reply, Steve. I think these things should be mentioned in the FAQ because this will probably affect people's decisions on whether or not they want to make the switch. People who recognize my caller ID when I call are not going to know it's me when I'm calling.
The 7-digit thing is a pretty big annoyance. I was hoping that there was a digit map fix that would get it working again. Being able to program all this is basically the Obi's big selling point.
Perhaps I was confused by your post. Are you describing the caller ID name on inbound calls (calls you receive on your phone attached to the OBi), or are you describing the caller ID name that your called parties will see when you call them?
My answer was about the first case. Before, when you were connecting directly to Google's XMPP servers, and someone called your inbound Google Voice number, NO CNAM at all was being sent to your phone by Google Voice, because Google doesn't subscribe to the service. All you saw was the calling party's caller ID number (CID). Now, you are detouring those inbound calls through the GVGW, which adds the CNAM service, so you'll now see your calling party's name, or generic location, when they call you.
As for what your called parties see when you call them, there is no change. They have always seen, and will continue to see, just your phone number and the generic location name, again, because Google doesn't feed your name into the LIDB. Perhaps you never realized this.
Quote from: SteveInWA on November 13, 2017, 02:38:41 PM
Quote from: TimAtHome on November 13, 2017, 02:33:53 PM
Thanks for the quick reply, Steve. I think these things should be mentioned in the FAQ because this will probably affect people's decisions on whether or not they want to make the switch. People who recognize my caller ID when I call are not going to know it's me when I'm calling.
The 7-digit thing is a pretty big annoyance. I was hoping that there was a digit map fix that would get it working again. Being able to program all this is basically the Obi's big selling point.
Perhaps I was confused by your post. Are you describing the caller ID name on inbound calls (calls you receive on your phone attached to the OBi), or are you describing the caller ID name that your called parties will see when you call them?
My answer was about the first case. Before, when you were connecting directly to Google's XMPP servers, and someone called your inbound Google Voice number, NO CNAM at all was being sent to your phone by Google Voice, because Google doesn't subscribe to the service. All you saw was the calling party's caller ID number (CID). Now, you are detouring those inbound calls through the GVGW, which adds the CNAM service, so you'll now see your calling party's name, or generic location, when they call you.
As for what your called parties see when you call them, there is no change. They have always seen, and will continue to see, just your phone number and the generic location name, again, because Google doesn't feed your name into the LIDB. Perhaps you never realized this.
It's what my called parties see, and there is a change. Instead of my name and number, it has a number from Washington state.
For me the bigger problem is the 7 digit dialing. Right now I'm knee deep in Expert mode looking for a way to get it back ... even though I have the old recipe in place, it seems to be totally ignoring it. On 7-digit test calls, the 1+NPA isn't being added to it at all ... argh!
Quote(1xxxxxxxxxx|<1312>[2-9]xxxxxxxxx|011xx.|xx.|(Mipd)|[^*#]@@.)
You are adding 1312 to a 10 digit number, not 7.
The last 2 rules are not needed.
(1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|<1312>[2-9]xxxxxx|011xx.|xx.)
Quote
It's what my called parties see, and there is a change. Instead of my name and number, it has a number from Washington state.
Google Voice has
never sent CNAM. Your called parties will either see the generic city name, or they will see whatever they have in their own phone's address book/contacts list, via that phone matching the number with their own list.
In some rare cases, and only for numbers that have been ported in from a landline telco, if that telco had submitted your name into the LIDB, it could have been left there for some period of time, and eventually purged.
If you absolutely require that your name be sent, then consider not using Google Voice. Some SIP service providers do feed their customers' names to the LIDB, with the customer's permission. Callcentric is one example.
Just keep in mind: CNAM is becoming less and less useful in general, as more people abandon their land lines, or use VoIP ITSPs that don't support CNAM.
Quote from: azrobert on November 13, 2017, 02:49:53 PM
Quote(1xxxxxxxxxx|<1312>[2-9]xxxxxxxxx|011xx.|xx.|(Mipd)|[^*#]@@.)
You are adding 1312 to a 10 digit number, not 7.
The last 2 rules are not needed.
(1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|<1312>[2-9]xxxxxx|011xx.|xx.)
Thanks so much, azrobert!
You know what's strange? <1312>[2-9]xxxxxx
still does not work. But if I use <1312>xxxxxxx instead, that works.
What are the rules (Mipd) and [^*#]@@. for, anyway? They were part of the default after I reset the machine.
Quote from: SteveInWA on November 13, 2017, 02:57:45 PM
Quote
It's what my called parties see, and there is a change. Instead of my name and number, it has a number from Washington state.
Google Voice has never sent CNAM. Your called parties will either see the generic city name, or they will see whatever they have in their own phone's address book/contacts list, via that phone matching the number with their own list.
I thought I might chime in here, because the way I read TimAtHome's post, it looks like Steve mistook what Tim is describing. I read it as Tim is **NOT** in Washington State, and the CID NUMBER (not name) displays some random number that does not belong to Tim and decodes to WA, where Tim is not located. He seems to be asking why the GVGW is assigning to Tim the wrong phone number that makes his called parties not recognize it.
I don't know if GVGW is the cause of this erroneous number display, but I'll step back and let you guys comment on this issue, and just read the discussion.
And if I'm wrong about what Tim meant, I'm sure he will correct that as well ;)
Quote from: SteveInWA on November 13, 2017, 02:57:45 PM
Quote
It's what my called parties see, and there is a change. Instead of my name and number, it has a number from Washington state.
Google Voice has never sent CNAM. Your called parties will either see the generic city name, or they will see whatever they have in their own phone's address book/contacts list, via that phone matching the number with their own list.
In some rare cases, and only for numbers that have been ported in from a landline telco, if that telco had submitted your name into the LIDB, it could have been left there for some period of time, and eventually purged.
If you absolutely require that your name be sent, then consider not using Google Voice. Some SIP service providers do feed their customers' names to the LIDB, with the customer's permission. Callcentric is one example.
Just keep in mind: CNAM is becoming less and less useful in general, as more people abandon their land lines, or use VoIP ITSPs that don't support CNAM.
CNAM wasn't my big concern, I was just wondering why a completely different number showed up. I tested it with someone who had my number in her contacts, and when I called it didn't display my number and the name she had in her contacts; instead, it had a number we'd never seen before from WA. Giving a different, new number for my calls is pretty much a deal killer. But ... I tried to think what you would advise and the thought occurred to power down, reboot everything, and try again. It's working as normal now. I don't know what that other number was all about, but if it's fixed I'm ready to move on...
Quote from: mo832 on November 13, 2017, 04:02:51 PM
Quote from: SteveInWA on November 13, 2017, 02:57:45 PM
Quote
It's what my called parties see, and there is a change. Instead of my name and number, it has a number from Washington state.
Google Voice has never sent CNAM. Your called parties will either see the generic city name, or they will see whatever they have in their own phone's address book/contacts list, via that phone matching the number with their own list.
I thought I might chime in here, because the way I read TimAtHome's post, it looks like Steve mistook what Tim is describing. I read it as Tim is **NOT** in Washington State, and the CID NUMBER (not name) displays some random number that does not belong to Tim and decodes to WA, where Tim is not located. He seems to be asking why the GVGW is assigning to Tim the wrong phone number that makes his called parties not recognize it.
I don't know if GVGW is the cause of this erroneous number display, but I'll step back and let you guys comment on this issue, and just read the discussion.
And if I'm wrong about what Tim meant, I'm sure he will correct that as well ;)
mo, you're absolutely right. That's what happened. It was strange and disturbing and definitely a deal-killer.
Fortunately after a reboot it's working as it used to, so the deal is on!
It is impossible for Google Voice to send a different phone number than the one from which you are calling.
If you have a Google Voice inbound telephone number, then Google Voice will use that number as your caller ID.
If you have no Google Voice inbound telephone number, then Google Voice will not send any caller ID number at all. The caller will see "UNKNOWN CALLER" or "PRIVATE CALLER" or a similar message instead.
The only way that a WA number could be sent as the caller ID, AND you are using Simonics GVGW, is if you entered the wrong number on the GVGW web site.
Quote from: SteveInWA on November 13, 2017, 04:10:45 PM
It is impossible for Google Voice to send a different phone number than the one from which you are calling.
...
The only way that a WA number could be sent as the caller ID, AND you are using Simonics GVGW, is if you entered the wrong number on the GVGW web site.
Actually the part that matters is the Google account used to sign up. Tim, if you're getting different behavior now than when you were using the Obi, it is probably because you signed up for the GVGW using a different account than you had applied on your Obi.
Quote from: billsimon on November 13, 2017, 04:38:24 PM
Quote from: SteveInWA on November 13, 2017, 04:10:45 PM
It is impossible for Google Voice to send a different phone number than the one from which you are calling.
...
The only way that a WA number could be sent as the caller ID, AND you are using Simonics GVGW, is if you entered the wrong number on the GVGW web site.
Actually the part that matters is the Google account used to sign up. Tim, if you're getting different behavior now than when you were using the Obi, it is probably because you signed up for the GVGW using a different account than you had applied on your Obi.
Thanks, Bill. I should have also mentioned that. This is turning into a fuster cluck. I spend too much time on the Google Voice help forum explaining to people why they can't find their number, and it's always because they are looking at the wrong account. If only people would read what's on the screen.
Quote from: TimAtHome on November 13, 2017, 04:01:20 PM
What are the rules (Mipd) and [^*#]@@. for, anyway? They were part of the default after I reset the machine.
(Mipd) points to User Defined Digit Map1
ipd:
(xx.<*:@>xx?x?<*:.>xx?x?<*:.>xx?x?<*:.>xx?x?|xx.<*:@>xx?x?<*:.>xx?x?<*:.>xx?x?<*:.>xx?x?<*::>xx?x?x?x?)This digit map will convert character string "0*192*168*1*100*5060" to "0@192.168.1.100:5060".
I think rule "[^*#]@@." is meant to match a URi like "tim@company.com".
Quote from: azrobert on November 13, 2017, 06:16:10 PM
I think rule "[^*#]@@." is meant to match a URi like "tim@company.com".
I think I'm wrong about rule "[^*#]@@.". This rule will match any character string that doesn't begin with "*" or "#" and will match an IP address after conversion by (Mipd). The [^*#] will prevent the rule from matching a Star Code or "##". "##" is used to get dial tone on a PSTN line.
Quote from: SteveInWA on November 13, 2017, 04:41:20 PM
Quote from: billsimon on November 13, 2017, 04:38:24 PM
Quote from: SteveInWA on November 13, 2017, 04:10:45 PM
It is impossible for Google Voice to send a different phone number than the one from which you are calling.
...
The only way that a WA number could be sent as the caller ID, AND you are using Simonics GVGW, is if you entered the wrong number on the GVGW web site.
Actually the part that matters is the Google account used to sign up. Tim, if you're getting different behavior now than when you were using the Obi, it is probably because you signed up for the GVGW using a different account than you had applied on your Obi.
Thanks, Bill. I should have also mentioned that. This is turning into a fuster cluck. I spend too much time on the Google Voice help forum explaining to people why they can't find their number, and it's always because they are looking at the wrong account. If only people would read what's on the screen.
I was looking at the right account and used the same number as I did before. It only happened once, I rebooted and it worked fine.
But, you know how it goes -- when it rains, it pours. Today something horrible is happening. I called a 1-800 customer support line for something I needed to do. After the conversation was over, I hung up ... and about five minutes later, I got a call. There was no caller ID. It was the 1-800 number, no one was on the line, and I hung up ... and then the number called back. And it keeps doing that!
The inbound peer number is just identified as "test" and not an actual telephone number.
In the call history it says "End Call (481 Call/Transaction Does Not Exist)"
The calls keep on coming and coming! I am going to log into GV and block the number, because I don't know what else to do...
Hello,
I'm getting a "Backing off TCP Connection failed" notification. I followed the very clear directions, I think. I wasn't sure what the server ports were.
I'm attaching a picture of what my screen looked like.
Thanks everyone who gives there time to help us who are less tech savvy.
Thank you!
Brian
If your problem was any clearer, it would be tattooed on your eyeballs.
See my screenshot here: http://www.obitalk.com/forum/index.php?topic=13147.0 (http://www.obitalk.com/forum/index.php?topic=13147.0)
Enter port 5060 in both of the fields you left empty.
Thanks SteveinWA. I did actually try it with that first and had the same issue, but then wasn't sure.
I went back and did it again. It still says backing off. I see you said it could take a little while so I can be be patient with it, although a guess it isn't more than a few minutes.
If you have any other ideas, please let me know.
Thanks for your patience.
Brian
As you can probably understand, the Simonics GVGW is a gateway, meaning, it is connecting and passing traffic between two different systems. On one side is the old Google Chat/XMPP protocol. You authorize GVGW to access the Chat service on your Google account, via OAUTH 2.0 authentication, when you follow the instructions to set up the gateway. Let's call that the GV side. Entirely separate from that, you are issued a SIP userID and password. You then enter that information on your OBi, and the OBi is simply using a standard SIP service provider. The OBi doesn't know nor care that it's a middleman for GV. Let's call this the gateway side.
The unauthorized error simply means that you've incorrectly entered the gateway user ID and password onto the OBi form, or else you are doing this on an OBi that is somehow still trying to use whatever old configuration parameters it has.
Go back to the GVGW web page. Click the link to change the password. Do NOT refresh or reload that browser page, as it will change the password again! Enter your 1xxxxxxxxxx GV phone number and GVGW SIP password on the OBiTALK form.
Thanks for your help. I got it up and running. I had to wipe out the obi from the system and reconnect the obi. Then the directions worked great.
I appreciate your time.
Brian
Omg thank you so much for your assistance but now some of my calls are being rejected by the service provide so do you have a solution(s) to this.
:-*
Hi, I bought Simonics when first GV/OBI discontinued on OBI110 few months back. It is all working fine since last few weeks. Every now and then I get 'no service configured' message and then I reboot my OBI110 and it starts working again. Any one else having this issue recently? Is this OBI or Simonics? Any fix?
Chiming in here as well with thanks to SteveWA & Bill, my Obi200 lost it's mind apparently and following the full reset instructions fixed the problems
Bizzare that a whole spate of these similar issues have been popping up over the past few months.