OBI110 and Simonics GV trouble

OBI110 and Simonics GV trouble - Unauthorized

<< < (5/9) > >>

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!

Navigation

[0] Message Index

[#] Next page

[*] Previous page