News:

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

Main Menu

OBI110 and Simonics GV trouble - Unauthorized

Started by TimAtHome, November 10, 2017, 07:16:17 PM

Previous topic - Next topic

SteveInWA

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.


TimAtHome

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.

SteveInWA

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.

TimAtHome

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!

azrobert

#24
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.)

SteveInWA

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.

TimAtHome

#26
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.

mo832

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 ;)

TimAtHome

#28
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...

TimAtHome

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!

SteveInWA

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.

billsimon

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.

SteveInWA

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.

azrobert

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".

azrobert

#34
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.

TimAtHome

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...


BrianNJ

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

SteveInWA

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

Enter port 5060 in both of the fields you left empty.

BrianNJ

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

SteveInWA

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.