I don’t understand how the X_SkipCallScreening with GV is supposed to work

[ccclapp]

By doing the above OB does not directly receive Google voice calls, but instead receives them via the new sip, etc. line.  

I believe that this is what you have described as the call flow:

Leg    1     2      3
Call->GV->sip->OBi

The only way that CID can pass from the second leg to the third leg (OBi) is if the sip provider allows spoofing the CID number. Most voip services providers don't allow this. Once the call reached the OBi, I would expect to see the DID number of the SP and not the original CID. You may be using a SP that does allows spoofing. Who is your voip SP? Call Centric is one provider which allows spoofing.

pc44 has described such a call strategy here:
Callcentric and Google Voice Setup Guide (with CNAM)
http://www.obitalk.com/forum/index.php?topic=3640.msg24230#msg24230

Hi
I admit to not yet testing ( phone on obi doesn't have CID capability, will test soon with another ), but im not sure this is correct:

Isn't the obi connection to a sip more like a soft phone's connection than a forwarding connection?  If so, the Obi would see the incoming CID of the call to the sip (which in this case is the person calling GV), not the sip CID...again just like a sip soft phone client does not get it's own sip CID.  Where is the flaw in this thinking?

As to the CC/GV thread, that was all about getting MORE CID info than GV ever provides...CNAM.  I agree if you want ADDITIONAL CID info than GV natively provides you would select a sip which supports CNAM.  That is by no means CID "spoofing", it's just a lookup service to give more INCOMMING CID info.  SPOOFING is tricking ones OUTGOING CID.  Per the above, because of how obi connects to sip clients ( like a sip soft phone) it receives INCOMMING not OUTGOING CID info.  This incoming CID info can be further enhanced beyond what GV provides by using a sip that provides CNAM.

Am I wrong?


By the way, curiously the GV / CC thread did not discuss ( or I didn't see it) the topic of this string:  enabling Caller Name Announce from GV on ones Obi.  To me that is huge and I believe my proceedure above gives us that with no downside.

[jimates]

I think you are correct with your assumption.

Spoofing, in this tense, means displaying information that is different from the identity of the service that placed the call. Normally all forwarded calls carry the identity of the service you receive the call on, in this case CC. If CC allows "spoofing" it will display the identity from the call that was forwarded to it, which is what everyone wants.

[ccclapp]

I think you are correct with your assumption.

Spoofing, in this tense, means displaying information that is different from the identity of the service that placed the call. Normally all forwarded calls carry the identity of the service you receive the call on, in this case CC. If CC allows "spoofing" it will display the identity from the call that was forwarded to it, which is what everyone wants.

But my underlying point is CC is not "forwarding" a call to Obi.  Obi is directly receiving the incoming call to the sip, just like any sip soft phone.  Is anything is "spoofing" it's GV which transmits the original call CID, not it's own.  Clearly GV is "forwarding", whereas the sip is not.

Having said that, I acknowledge a sip can "process" an incoming call and the info passed to its native ( answering) client, be it soft phone, obi or dedicated app/dashboard.  Again that is not spoofing as the term is always used.

None of this really matters, this is just semantics.  What matters is that ( subject to further verification ) if one 1) disables google talk in GV, 2) forwards GV to a sip/Skype etc, 3) configures obi to directly that sip/Skype etc...ONE WILL RECEIVE BOTH CID (at least as much as GV provides and more if sip is configured for CMAN lookup) AND CALLER NAME ANNOUNCE GV FEATURE.  Isn't that the point of this thread and what we want?

Ps:  what you two are saying about "spoofing" would be more accurate if the sip forwarded to another phone ( vs native access via soft phone/ obi).  In that case the sip would be forwarding the incoming CID as it makes an outgoing (forwarding) call, rather than it's own CID.  Please note, this is exactly what GV does.

[QBZappy]

ccclapp,

Title of this thread:
Re: I don't understand how the X_SkipCallScreening with GV is supposed to work

... AND CALLER NAME ANNOUNCE GV FEATURE.  Isn't that the point of this thread and what we want?

I just realized what you are talking about. "CallScreening" in this context means pressing "1". It is NOT the CALLER NAME ANNOUNCE GV FEATURE as you are suggesting. It is easy to mix the two concepts as they indeed use similar nomenclature.

[jimates]

ccclapp,

Title of this thread:
Re: I don't understand how the X_SkipCallScreening with GV is supposed to work

... AND CALLER NAME ANNOUNCE GV FEATURE.  Isn't that the point of this thread and what we want?

I just realized what you are talking about. "CallScreening" in this context means pressing "1". It is NOT the CALLER NAME ANNOUNCE GV FEATURE as you are suggesting. It is easy to mix the two concepts as they indeed use similar nomenclature.

I pointed that out in reply #14. I also said that the name of the feature used to be called "call announce", now it is just call screening.

Some get confused because on the google end there is only one process, when enabled at google voice, all recipients get the same greeting. But depending on whether the call is delivered to a forwarding phone or to google chat (aka Obi) the announcement is different for the person making the call. You can turn off the call screening at google voice. This will prevent the recipient from getting any greeting. This will also prevent the call maker from getting the screening prompts; EXCEPT when using google chat (aka Obi). With google chat you can't turn it off, therefore the Obi can handle it for us, or not.

When we used to have to set the Obi to press 1 for us, most people were aware of the feature and the difference between the two. Now that the Obi defaults to pressing 1 for us, no one realizes it is there, and when they do they think the Obi is suppose to control the call screening feature at google.

I don't use the call screening my self, but I think Obi should not change the function of a google voice feature by default. They should have left it for the user to change.

Basic concept, but hard to explain to some.

[J4545]

Impressive analysis and workaround, thank you. I really like how the "Call Screening" (announce) works on my landline and am disappointed that there is not an option for that with OBi... would really like to make the choice of announce or not.

For me, CID with number only is not very useful compared to having GV tell me who it is or "unknown caller."

So far I have added Callcentric "Pay Per Call" in order to get cheap 911 service. Now it sounds like I need to add Callcentric "Pay Per Minute Phone Number" to get a non-GV number that will behave like my old landline.

If this does not work, I have an unopened Ooma sitting here and the OBi will go back... but Ooma is $5/month plus much more expensive to buy... I want to send it back not the OBi.

This is a great example of how "tightly integrated" (GV + OBi) without full control of options can be less useful than non-integrated (GV + landline + cheap Tracfone cell + work phone) at least for some people.

My first day of OBi has been early adoptor paradise... caveat emptor. I have to say the basic setup is mind-bogglingly easy.

[CoalMinerRetired]

I'm not clear what CallCentric number plans you are referring to. What seems to be the accepted (on here) and least expensive way to go is what CC has listed as Receive Calls > Free Phone Number. It's totally free if you do not use their E911. If you use E911, it's $1.50 per month, plus $1.50 one-time set up fee.

[J4545]

As stated in quotes: "Pay Per Minute Phone Number"

I thought the free number was only "available in parts of NY state" but now understand it is available everywhere... you just get that area code.

So I will use the free number instead. Thanks very much for your help!

Later: OK, so I got a free New York 845 number to receive calls on. I currently have

1. GV
2. a 777 number for my 911 service on my OBi 110

Do I need a 3rd SIP or can I forward the 845 to the 777? I tried that and Callcentric says the customer is not available when I call the 845 number.

Thanks!

[jimates]

the 777 is your callcentric number and account number. You only use it to set up your callcentric service on the Obi.

check your preferences at callcentric to enable caller id with name an tweak your other settings.
put the 845 number as a forwarding phone in your google voice. Calls coming into your google voice will be forwarded to the 845 # which will ring your callcentric account and the Obi.

You need to change some settings so that calls to google voice are not also routed to the phone port via google chat. If both sp1 (GV) and sp2 (CC) are delivering to the phone port, sp1 will win and you still won't get the caller id with name from sp2.

You can either uncheck google chat as a forwarding phone in your google voice settings, or you can change the setting for the SP service you have google voice set up on so that it doesn't ring the phone.

I suggest just changing your SP1 inbound call route to this {(1yourgvnumber):ph1},{}
Google voice will still forward all calls to the Obi, but the {} rule will prevent the Obi from delivering the call to the phone. this will allow SP2 to deliver the call to the phone which will result in the caller id with name.
The {(1yourgvnumber):ph1} rule will allow calls from google voice that have your google voice caller id to ring the phone port. This will allow you to use Click2Call.

And since you are answering calls on sp2 (CC) instead of on GV, your call screening feature from google voice will work.

[J4545]

It works, thanks very much for the help!

[Shinelikethunder]

Some get confused because on the google end there is only one process, when enabled at google voice, all recipients get the same greeting. But depending on whether the call is delivered to a forwarding phone or to google chat (aka Obi) the announcement is different for the person making the call. You can turn off the call screening at google voice. This will prevent the recipient from getting any greeting. This will also prevent the call maker from getting the screening prompts; EXCEPT when using google chat (aka Obi). With google chat you can't turn it off, therefore the Obi can handle it for us, or not.

I'm really confused. Am I reading this wrong, or do you have "call maker" and "recipient" reversed? Isn't the "call maker" the one initiating the call and the one who receives the "Please state your name" greeting if the Google Voice "screen calls" feature is enabled? Isn't the recipient the one who gets the "Press 1 to accept call" greeting?

[SteveInWA]

Some get confused because on the google end there is only one process, when enabled at google voice, all recipients get the same greeting. But depending on whether the call is delivered to a forwarding phone or to google chat (aka Obi) the announcement is different for the person making the call. You can turn off the call screening at google voice. This will prevent the recipient from getting any greeting. This will also prevent the call maker from getting the screening prompts; EXCEPT when using google chat (aka Obi). With google chat you can't turn it off, therefore the Obi can handle it for us, or not.

I'm really confused. Am I reading this wrong, or do you have "call maker" and "recipient" reversed? Isn't the "call maker" the one initiating the call and the one who receives the "Please state your name" greeting if the Google Voice "screen calls" feature is enabled? Isn't the recipient the one who gets the "Press 1 to accept call" greeting?

You are posting in an eight-year-old discussion, and the comment you quoted is pretty incoherent.  Call screening works differently now than it did in 2012.

What, exactly, are you trying to do, and what, exactly, do you want to know?

[Shinelikethunder]

What, exactly, are you trying to do, and what, exactly, do you want to know?

Sorry. (1) I couldn't find any recent discussion of this, and (2) I was hoping to clarify the concepts, because all of these posts, regardless of age, are important reference material. If you want me to start a new discussion, I can, but I thought it might be better to keep the information in one place. Please let me know what seemed "incoherent" so that together we can clarify these concepts.

I'm trying to suppress the "Call from <name>; to accept, press 1; to send to voicemail, press 2" announcement when "Screen calls" is turned on in Google Voice. I want to know why I can't seem to do so. As far as I can tell by experimenting, X_SkipCallScreening now does nothing. Thanks.

[SteveInWA]

The voice prompt to "press one to accept" comes from Google Voice's optional call screening feature.  It has nothing whatsoever to do with any setting for the OBiTALK hardware.

You can disable Google Voice call screening by signing into the Gmail account that holds your Google Voice number, and going here:  https://voice.google.com/settings.  Scroll down to the "Screen calls" setting and turn it off.

[Shinelikethunder]

The voice prompt to "press one to accept" comes from Google Voice's optional call screening feature.  It has nothing whatsoever to do with any setting for the OBiTALK hardware.

You can disable Google Voice call screening by signing into the Gmail account that holds your Google Voice number, and going here:  https://voice.google.com/settings.  Scroll down to the "Screen calls" setting and turn it off.

I know most of that, but I thought that X_SkipCallScreening was supposed to automatically send a "1" when I answer. How did X_SkipCallScreening work in 2012? Wasn't there a "Press 1 to accept" prompt with or without "Screen calls" back then? I would like to use call screening to deter robocallers and telemarketers without having to press 1 to accept the call. Apparently, that's not possible, and I'm trying to understand why and whether there's any possible workaround. Thanks.

[SteveInWA]

Just disable it in Google Voice settings.

Your proposed scenario makes no sense.  The CALLED party (you) hears the "press one" prompt, not the CALLING party (potential robocaller).  The Google Voice call screening feature is not a robocall blocking solution, nor does the current implementation of Google Voice work as it did in 2012.

If you want to limit robocalls, enable the "Filter Spam" setting in Google Voice settings.

[Shinelikethunder]

No. I've been very polite, and you refuse to even attempt to understand what I'm trying to do. Is anyone else reading this?

[Shinelikethunder]

Your proposed scenario makes no sense.  The CALLED party (you) hears the "press one" prompt, not the CALLING party (potential robocaller).  The Google Voice call screening feature is not a robocall blocking solution, nor does the current implementation of Google Voice work as it did in 2012.

If you want to limit robocalls, enable the "Filter Spam" setting in Google Voice settings.

Sorry, I wrote my previous response before you added this part; all I saw was "just disable it."

I have "filter spam" on, and always have. It's as useful as a screen door on a submarine. Call screening does seem to help stop spam callers, because they're asked to state their name when call screening is on, right? At least that's what happens when I call from a number that's not in my GV phone book. My OBi call history shows many calls from unknown callers that appear to hang up after 2 seconds. Isn't that because they've been asked to give their name and declined? When I Google those numbers, I frequently see Nomorobo spam reports for them. Exactly why does my proposed scenario make no sense?

[SteveInWA]

OK, let's start the conversation over.

First:  this thread was from eight years ago.  Google Voice has undergone a complete refresh since then, and many features have changed.  Google Voice now directly supports SIP VoIP calling, without the old XMPP/Google Chat kludge.  That OBi X_SkipCallScreening setting is now non-functional and irrelevant.

Google Voice call screening has been completely replaced, and it now has a different behavior.  Here is how call screening now works, assuming you have turned it on in Google Voice settings:

• All calls, from all callers, will be screened.  "Screened" is defined as:  when you answer the call, Google Voice will always announce "Call from..." and then ask you, the Google Voice user and called party to decide -- press 1 to accept the call and talk to the caller, or press 2 to send the caller to your Google Voice voicemail.
• If the calling phone number is not in your Google Contacts, then that caller will be asked to state their name before the call rings on your end.  Google Voice will play back whatever the caller said, after "Call from..."  It will not save their name, and they will be asked to speak their name on every subsequent call.  Even if they say nothing, your phone will still ring, and it will simply have no recorded speech to play back.
• If the calling phone number is in your Google Contacts, then the caller will not be asked to speak their name, however, their call will still be screened.  Instead, Google Voice will use that contact's information with text-to-speech, to say the name you entered in their contact.

Over the past couple of years, the majority of robocalling has been using "neighbor spoofing", whereby the robocall software spoofs the caller ID of some random number that has the same area code and prefix as your number.  This is a "social engineering" trick to make you think the call is indeed from one of your neighbors or local businesses, doctor's office, etc.  Until the new "STIR/SHAKEN" based caller ID authentication system is more widely supported, there is no defense against this, other than to simply not answer calls from numbers you do not recognize, or to build a cumbersome white-list solution.

Note that you can "fork" inbound calls to Nomorobo, to add its blocking database, and that's been discussed in other threads.

[Shinelikethunder]

That OBi X_SkipCallScreening setting is now non-functional and irrelevant.

Yes, that matches what I've observed.

Google Voice call screening has been completely replaced, and it now has a different behavior.  Here is how call screening now works, assuming you have turned it on in Google Voice settings:

• All calls, from all callers, will be screened.  "Screened" is defined as:  when you answer the call, Google Voice will always announce "Call from..." and then ask you, the Google Voice user and called party to decide -- press 1 to accept the call and talk to the caller, or press 2 to send the caller to your Google Voice voicemail.
• If the calling phone number is not in your Google Contacts, then that caller will be asked to state their name before the call rings on your end.  Google Voice will play back whatever the caller said, after "Call from..."  It will not save their name, and they will be asked to speak their name on every subsequent call.  Even if they say nothing, your phone will still ring, and it will simply have no recorded speech to play back.
• If the calling phone number is in your Google Contacts, then the caller will not be asked to speak their name, however, their call will still be screened.  Instead, Google Voice will use that contact's information with text-to-speech, to say the name you entered in their contact.

Yes, I believe that I understand all of that. I have no complaint with the way GV call screening works. I just was under the misimpression that X_SkipCallScreening sent a "1" when I answered and that it should eliminate the need for me to do so myself. If nobody has a workaround that does what I want, maybe I need to make an OBi feature request. I'm just looking for a way to automatically halt the screening announcement and directly connect to the caller.

Over the past couple of years, the majority of robocalling has been using "neighbor spoofing", whereby the robocall software spoofs the caller ID of some random number that has the same area code and prefix as your number.  This is a "social engineering" trick to make you think the call is indeed from one of your neighbors or local businesses, doctor's office, etc.  Until the new "STIR/SHAKEN" based caller ID authentication system is more widely supported, there is no defense against this, other than to simply not answer calls from numbers you do not recognize, or to build a cumbersome white-list solution.

Note that you can "fork" inbound calls to Nomorobo, to add its blocking database, and that's been discussed in other threads.

Yes, I used Nomorobo for several years and know how to fork to it, but it's no longer effective. I suspect it's because spammers that use "neighborhood spoofing" change numbers as fast as I can blink.