Google Voice call waiting not working on Obi 200

[mo832]

I don't know how long this has been happening, but I only became aware of it today. If I place an outbound call from my Obi handset thru my Google Voice primary line on SP1, and then I receive in inbound call while the first call is active, the inbound call will not ring or beep for call waiting and the caller will immediately be sent to the Google Voice attendant voicemail greeting. I know this always worked properly before.

But the following scenarios DO work.
1. Outbound call thru GV, inbound call on SP2 to the same handset >> call waiting prompt
2. Inbound call to GV, 2nd inbound call to GV >> call waiting prompt

Additional setup (shouldn't matter, didn't matter before)
- Outbound calls are placed on SP1 and SP2 thru the "integrated" GV-Obi200 calling setup. SP1 and SP2 are separate GV numbers
- Incoming calls on both GV numbers are forwarded to DID number hosted by Callcentric for caller id name feature.

Any hints?
Thanks

[MSRobi]

Since your inbound calling is through CallCentric, I would scour the Callcentric settings for anything that looks wrong.  It is possible CallCentric changed their interface, maybe added a new setting with a default that isn't right for your needs.  I use personal GV, not Google Workspace GV, and I don't see anything in the settings that matter.

[mo832]

Since your inbound calling is through CallCentric, I would scour the Callcentric settings for anything that looks wrong.  It is possible CallCentric changed their interface, maybe added a new setting with a default that isn't right for your needs.  I use personal GV, not Google Workspace GV, and I don't see anything in the settings that matter.

What would I be looking for? What in Callcentric settings would be related, and how should it look normally? It should be noted that ALL incoming calls on EITHER GV number are forwarded to the SAME Callcentric number for delivery to my Obi box. To Callcentric, the calls all look the same, and it sends them to the same place. If the Call Waiting call properly displays when being sent by the GV 2nd number, it seems like it should display when being forwarded via the main GV number, ultimately to the "hidden" Callcentric "incoming only" number.

I looked at GV settings, and I don't see anything there regarding turning call waiting on or off except do not disturb, which is off.

To put it in different terms, it seems like Google Voice is refusing to forward an incoming call intended for the same Google Voice number when it sees that the number is currently in use. When this is detected, GV intercepts with GV voicemail immediately without processing the incoming call normally.

[MSRobi]

Since call waiting works if the first call is initiated from CallCentric when the second call comes in, but it doesn't when the first call is initiated outbound from GV, I suspect the problem on CallCentric side.  I suspect CallCentric is handing the call off to GV differently when it doesn't know that the line is in use because you initiated the first call outside of CallCentric.

I do not know CallCentric since I don't use it.  And it is entirely possible (even likely) that there is nothing in your control to fix the problem.

[mo832]

Since call waiting works if the first call is initiated from CallCentric when the second call comes in, but it doesn't when the first call is initiated outbound from GV, I suspect the problem on CallCentric side.  I suspect CallCentric is handing the call off to GV differently when it doesn't know that the line is in use because you initiated the first call outside of CallCentric.

I do not know CallCentric since I don't use it.  And it is entirely possible (even likely) that there is nothing in your control to fix the problem.

What you wrote started to make sense, until I thought about it some more. The call intitiated thru GV goes out on SP1. Callcentric doesn't know the "line" is in use. A call waiting to the SP1 GV number is received by GV and then it should forward it to Callecentric. But GV doesn't forward it. GV answers with voicemail immediately. If they *did* forward it, then Callcentric comes into play. In that case Callcentric should send it to my SIP incoming line ON SP3. So it is irrelevant whether there is a call in progress from GV or not, since Callcentric should attempt to send the call to an open SP3, as it does when there is NO call in progress. Assuming Callcentric has some quirk that it "knows" when the line is in use and it "knows" it's a call waiting call, that would be plausible, though weird.... but then why does it not do this when the 2nd call is directed to my SECONDARY GV line? Same exact scenario: Outbound call placed thru GV on line 1, CC not used at all. Incoming call sent to GV line 2 >> forward to CC >> SP3 >> Call waiting ID. The only difference between it working or not is which GV number was dialed before handing off to CC. GV is in control here. CC doesn't even know about the calls until GV tells them. Nobody is direct dialing my CC number which is in a different state and unpublished.

[MSRobi]

If it is irrelevant to Callcentric whether or not the initial call originated or did not originate from Callcentric, then I'm out of suggestions.  I understand that you've narrowed it down to a GV issue (not 100%, but high probability).  I'm not sure I could help even if I had full access to all your hardware and accounts especially if it is a GV issue which is woefully inadequate in exposing advanced options not available to the end user.

[mo832]

I notice this forum is on the quiet side these days, probably terminally so given the developments with the company and their products.

Still, in case anyone else happens to read this, I have additional data points

I am all but certain the problem lies on the GV end, and in particular, the GV interface via the Obi 200 using the endorsed integration facility to link Obitalk directly to GV services, enabling direct dialing of GV on the analog handset.

As noted above, I have 2 separate GV numbers, and each one is given an SP location on my Obi200. The ONLY TIME call waiting does not work is when I dial out on EITHER NUMBER using the handset. If I dial on my primary number, and a new call comes in on the same number, it goes straight to VM. If I dial out on my secondary number and a new call comes in on that same number, straight to VM. However, if I dial out on one or the other, and the new call comes in on the opposite number, the call is allowed, and I get a call waiting tone and the number display.

Also, If I initiate the outgoing call on my browser using the callback feature, and then a new call comes in, call waiting works as normal.

The only constant factor here is using the Obi, with a handset, placing an outgoing call directly using the Obi/GV integration. Google Voice, when calling out from the handset, seems to "commandeer" that line, and any calls that come in to that number are sent straight to voice mail without even attempting to let me answer. But when using Google Voice thru the web app to initiate a call, it leaves the line open for incoming calls to answer manually.

Originally, Google Voice was not a physical line, only a virtual phone number which could forward calls to other numbers. You could not have natively dialed out on a GV line before. Now, it seems like GV has reverted to not playing nice with a physical hardware device occupying the GV phone number/line.

Unless, of course, there is some setting that I can change to enable the expected (and historically enabled) behavior. Which was my original question above.

[Taoman]

How often is this actually an issue for you? Do you have a particular need to answer unknown callers (like running a home business)? If not, I suggest the following:

1>If you haven't done so already, create a custom rule for all your Contacts to route them to Callcentric. (although they won't actually route there)

2>Disable your OBi device in GV settings. This stops unknown callers from ever ringing your OBi device directly. But your Contacts will ring straight thru to your OBi (and not to Callcentric because routing straight to your OBi device is faster than forwarding to Callcentric so Callcentric loses the race).

3>Enter all of your Contacts' names/numbers into your phone's phonebook so you still get name display on your phone for your Contacts (since you won't be getting CNAM from Callcentric for your Contacts)
While you may think this is a hassle, consider that without forwarding to Callcentric you have one less hop in your call path which means less latency and better call quality which you probably want for your Contacts.

If you follow the above steps, call waiting will work normally for your Contacts even if you initiated the call from your OBi. All unknown callers will still be immediately routed to GV voicemail. No getting around that unless you didn't initiate a call in which case unknown callers will still be routed to Callcentric.

[mo832]

How often is this actually an issue for you? Do you have a particular need to answer unknown callers (like running a home business)? If not, I suggest the following:

1>If you haven't done so already, create a custom rule for all your Contacts to route them to Callcentric. (although they won't actually route there)

2>Disable your OBi device in GV settings. This stops unknown callers from ever ringing your OBi device directly. But your Contacts will ring straight thru to your OBi (and not to Callcentric because routing straight to your OBi device is faster than forwarding to Callcentric so Callcentric loses the race).

3>Enter all of your Contacts' names/numbers into your phone's phonebook so you still get name display on your phone for your Contacts (since you won't be getting CNAM from Callcentric for your Contacts)
While you may think this is a hassle, consider that without forwarding to Callcentric you have one less hop in your call path which means less latency and better call quality which you probably want for your Contacts.

If you follow the above steps, call waiting will work normally for your Contacts even if you initiated the call from your OBi. All unknown callers will still be immediately routed to GV voicemail. No getting around that unless you didn't initiate a call in which case unknown callers will still be routed to Callcentric.

Thank you for responding. I don't think you understood my situation correctly. It's not just "unknown" callers that go straight to voicemail, it's ALL incoming callers when the line is in use after dialing on GV from my handset. Unless you by "unknown" you mean everybody who is not a regular caller. But there's lots of people I "know" who I speak to infrequently and don't need or want to put them on my contacts list.

Your method does seem like a hassle. But, if I were to entertain that idea, I don't quite follow how it would work. GV owns my DID number, so GV gets to route the call. How can Callcentric and GV/Obi BOTH be disabled? In other words, I don't understand the last part of #1 and the last part of #2.

And in addition, if you say that this is how it must be if I expect calls to avoid VM on call waiting, WHY is this the case only now, when this was never an issue for the last XX years?

(please also note that AFAIK, GV/Obi is already disabled in GV settings. I have only one forwarding number, and that goes to my DID at Callcentric. The native Obi line on GV number is not used for incoming calls and is only used to dial out)

[Taoman]

By "unknown callers" I meant any callers that were not Google Contacts. Yes, if you are unwilling to add all your known callers as Contacts my solution won't work.

It is a hassle to set up which is why my first question was how often this is actually an issue for you. But once it's set up you're done.
I never said anything about disabling Callcentric. Incoming calls from one of your Contacts would be routed directly to your Google Voice line before ever having a chance to be forwarded to Callcentric. But non-Contacts would continue to be forwarded to Callcentric. This happens because of the integration OBi devices have with Google Voice.

Things changed after the Legacy version of GV was deprecated.

But again, this is all moot if you don't want to add all your known callers to your Contacts list.

Edit: I configure my setup this way because I get the best call quality when talking to any of my Contacts. I live on the West coast. Callcentric is in New York so all calls forwarded to Callcentric traverse the entire country and back so there is a small amount of latency introduced to those calls. So all my Contacts get routed directly to my Obi device and unknown callers (almost always robocallers) get routed to an IVR at Callcentric.
It also allows call waiting to work properly [for your Contacts] even when you're on a call that you initiated.

[azrobert]

I was able to reproduce your problem using another provider's DID, so it looks like you're correct that it's a GV problem and not Callcentric.

It appears that GV won't route inbound calls to a forwarding number when on an active outbound call.

I got it to work by routing inbound calls to both the OBi and my DID. This won't help you because the GV direct to OBi calls should beat the GV to Callcentric, so all inbound calls when line is not busy won't get CNAM. I Think it might work if you delay GV direct calls.

Do you have an open SP on your OBi or another OBi device? I'm thinking routing the direct calls to a 2nd extension on Callcentric and then back to the OBi. Hopefully, this will delay the direct calls long enough.

I never got around to ask you if your zip code 85268?

[mo832]

I was able to reproduce your problem using another provider's DID, so it looks like you're correct that it's a GV problem and not Callcentric.

It appears that GV won't route inbound calls to a forwarding number when on an active outbound call.

I got it to work by routing inbound calls to both the OBi and my DID. This won't help you because the GV direct to OBi calls should beat the GV to Callcentric, so all inbound calls when line is not busy won't get CNAM. I Think it might work if you delay GV direct calls.

Do you have an open SP on your OBi or another OBi device? I'm thinking routing the direct calls to a 2nd extension on Callcentric and then back to the OBi. Hopefully, this will delay the direct calls long enough.

I never got around to ask you if your zip code 85268?

Thank you for the feedback. It's helpful to know you could reproduce the problem.

My zip code is NOT 85268, not even in AZ. Why do you ask? Seems random 

I do have (I believe) at least one unused SP. SP1 is GV line 1, SP2 is GV line 2, SP3 is Callcentric DID incoming for CNAM, with both GV1 and GV2 forwarded to CC on SP3. SP4 might be open.

So, given that GV is doing this and they never did it before, do you have a notion of why this is? I don't think it coincided with the EOL announcement or the removal of the legacy GV site, since this never showed up for me until recently. It seems like it could be no more than a few months.

Can you or Taoman explain how to route contacts to Callcentric ("although they won't actually route there")? Huh?

Also explain how to ring "straight thru to the Obi" even AFTER disabling the Obi in GV settings?

Thanks in advance, and also let me just comment that it's very strange that this is even a thing after it never was before. It's almost like a termination without really explicitly pulling the plug, ala that scene in Office Space where they never told the guy he was fired, they just stopped paying him.

[azrobert]

Enable the GV line by checking it in GV settings. Now the OBi will receive GV inbound calls on 2 lines. The bug prevents the Callcentric line from ringing when the OBi is busy with an outbound GV call, but the call will come in on the GV line and you will get the call waiting tone. I have tested this and it worked.

I think when the OBi is not busy, the call coming in on the GV line will win the race over the Callcentric line and you won't get CNAM. I suggest trying this to make sure this is the way it works. Maybe the Callcentric line wins the race and everything is fixed.

If you're not getting CNAM, you can try delaying the GV line by routing it to Callcentric

Add a 2nd extension (101) to Callcentric.
Register SP4 to extension 101 on Callcentric.
Change SP1 X_InboundCallRoute to:
sp4(1777xxxxxxx101@in.callcentric.com)

You have to route the call with a URI, otherwise the CallerID won't route correctly.

If this works and you want to do the same for SP2, change SP4 MaxSessions to 4.

I have NOT tested this, so after all the trouble of re-configuring, this setup might not work.

A friend asked me to help someone setup GV. His name was Mo. I just wondered if you were the same person.

[Taoman]

Enable the GV line by checking it in GV settings. Now the OBi will receive GV inbound calls on 2 lines. The bug prevents the Callcentric line from ringing when the OBi is busy with an outbound GV call, but the call will come in on the GV line and you will get the call waiting tone. I have tested this and it worked.

Are you sure this isn't working for Contacts only? For me, all non-Contacts get routed to GV voicemail immediately.

sp4(1777xxxxxxx101@in.callcentric.com)

You have to route the call with a URI, otherwise the CallerID won't route correctly.

Callcentric does not support CNAM for URI callers..... except for Callcentric's own phonebook.

[azrobert]

The call is still blocked on the Callcentric line. It does arrive on the GV line and produces the call waiting tone. I have no GV contacts defined.

I know Callcentric doesn't support CNAM on URI calls, but this only comes into play to produce the call waiting tone when the OBi is busy with an outbound call.

[mo832]

I appreciate all the comments. This is interesting, even though frustrating.

I'm still unclear on the following things from earlier. Could either one of you comment?

******* begin quote
So, given that GV is doing this and they never did it before, do you have a notion of why this is? I don't think it coincided with the EOL announcement or the removal of the legacy GV site, since this never showed up for me until recently. It seems like it could be no more than a few months.

Can you or Taoman explain how to route contacts to Callcentric ("although they won't actually route there")? Huh?

Also explain how to ring "straight thru to the Obi" even AFTER disabling the Obi in GV settings?
***** end quote

[Taoman]

So, given that GV is doing this and they never did it before, do you have a notion of why this is? I don't think it coincided with the EOL announcement or the removal of the legacy GV site, since this never showed up for me until recently. It seems like it could be no more than a few months.

I have no idea. It is what it is so we have to deal with it.

Can you or Taoman explain how to route contacts to Callcentric ("although they won't actually route there")? Huh?

Both azrobert and I have explained this to you. If you have GV configured for incoming calls to route to both GV and to Callcentric then it's a race as to who answers first. Since routing directly to your OBi GV trunk is going to be faster than forwarding to Callcentric, even though your GV settings includes routing to Callcentric it "won't actually route there" because it lost the race. (I'm pretty sure you had your GV trunk disabled for incoming calls so this was never an issue for you).
I route my Contacts to Callcentric by making a custom call forwarding rule in GV settings.

You should be familiar with this issue since you've posted about it in the past:
https://www.obitalk.com/forum/index.php?topic=14548.msg92582#msg92582

Also explain how to ring "straight thru to the Obi" even AFTER disabling the Obi in GV settings?

Again, this is due to the special integration that OBi devices have with Google Voice. For me on my OBi202, when I disable my OBi202 in GV settings my Contacts still route directly to my GV trunk and all non-Contacts get routed to Callcentric. This behavior won't happen with any other device like an Android or iOS.

Note: I pulled out my OBi200 to test on and I got different results. With the OBi200 disabled in GV settings, all inbound calls were routed directly to my GV trunk (including non-Contacts).

[azrobert]

Note: I pulled out my OBi200 to test on and I got different results. With the OBi200 disabled in GV settings, all inbound calls were routed directly to my GV trunk (including non-Contacts).

I tested my OBi200 and I get the same results as you. All calls are routed over the GV line to the OBi200.

Calls to my GV number come into the OBi via only the devices that are checked in GV setting when NO CONTACTS are defined. I think this is the way it should work and defining contacts and rules cause a bug.

If calls only arrive via GV line when contacts are defined, how do you get CNAM from the Callcentric line?

Edit:
I get it, I think. You get CNAM from the GV contact definition. Callcentric is useless with this setup. Why have it? Or do I not understand?

[Taoman]

If calls only arrive via GV line when contacts are defined, how do you get CNAM from the Callcentric line?

Good questions. This is why I told the OP for my plan to work he would need to add his Contact names to his phone's phonebook so he would still get name display. It's worth it to me to go through the [one-time] hassle of adding my Contacts to my phone itself so I can get one less hop, less latency, and better call quality when talking to my Contacts.

Edit:
I get it, I think. You get CNAM from the GV contact definition. Callcentric is useless with this setup. Why have it? Or do I not understand?

As mentioned, my OBi200 acts differently than my OBi202 which I don't understand. But my daily driver is the 202. Anyway, for me using the OBi202 and the custom forwarding rule, Contacts route directly to my OBi GV trunk but non-Contacts still route to Callcentric to an IVR. So if someone calls that's not one of my Contacts but needs to speak with me they can either leave a voicemail or "press 5 to connect."

I cannot explain why the 202 acts this way with non-Contacts but the 200 does not. But I agree if my 202 did not do this then Callcentric would be useless to me.

Edit: My mistake, it IS working the same on the OBi200. I was so used to having Callcentric ring on my other handset with the OBi202 I didn't realize when the non-Contact was ringing the phone it actually was going thru Callcentric and not the GV trunk. I had disabled my IVR for testing purposes.

So my plan from above does work as I detailed it and it does also work on an OBi200.

[mo832]

Thanks again you all for chiming in and running your own experiments. Seeing that there's no going back to the "old way" which just "worked", and seeing that the workaround requires lists that can change daily and other tweaks which I don't feel like doing, and even then, only "approximate" the old functionality, I think I'm just going to start using my own workaround which I contemplated would be necessary even before posting this thread.

That is as follows. If I want to make an outgoing call, and I insist on using my handset, and I need to leave call waiting open on my main line, I will use sp2 to make the call (leaving sp2 busy, but not used by many callers). If I want to make an outgoing call, and I need it to show as originating from my primary number, and still leave the line open for call waiting, I will have to initiate the call from my browser to ring back to Callcentric.

At least this way, for ALL cases and all callers, I will have the exact same experience as before re: incoming calls, with CNAM from Callcentric, on open calls and call waiting.

Outgoing calls will be more cumbersome, but it seems like that may happen anyway as Obi/GV integration fades out. I did have to do this exact same thing prior to buying the Obi200 when the Obi100 was phased out and the protocols changed, causing GV to no longer natively work with the Obi100. The were other workarounds at that time, which I milked as long as I could. But ultimately, I got myself used to the idea of dialing from my browser.

I have too many requested, or legitimate but one-time callers that I need to see their name to know what the nature is. If I had to handle any non-pre-screened contact as an unknown, it would cramp my style more than the hassle of dialing from the pc.

I will add that it's reassuring to know that this is considered a "bug". There have been some recent positive surprises as well, such as music-on-hold with GV, but I won't be able to use it if I don't use GV for dialing out.