I don’t understand how the X_SkipCallScreening with GV is supposed to work
ccclapp:
Quote from: QBZappy on August 23, 2012, 08:08:50 pm
Quote from: ccclapp on August 23, 2012, 02:00:54 pm
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:
Quote from: jimates on August 24, 2012, 06:39:12 am
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
Quote from: ccclapp on August 24, 2012, 06:57:54 am
... 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:
Quote from: QBZappy on August 24, 2012, 08:43:32 pm
ccclapp,
Title of this thread:
Re: I don’t understand how the X_SkipCallScreening with GV is supposed to work
Quote from: ccclapp on August 24, 2012, 06:57:54 am
... 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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page