I don’t understand how the X_SkipCallScreening with GV is supposed to work
opuletn:
I was able to get the call screening to work when picking up the call on the Obi110. The drawback is that there is 20 seconds delay from the time I pick up the phone until I hear the announcement to press 1 or 2 to accept or send to voicemail.
If I don't pick up the phone right on the first ring it takes too long and GV will end up sending the caller to voice mail.
My settings in GV Call Screening are "On" and "Ask unkonwn Callers to say their name" unchecked.
My setting on Obi is X_SkipCallScreening unchecked.
The 20 sec delay makes it unusable, so I rather not use the call screening.
ccclapp:
if I've understood this thread correctly and done my own tests properly,I reach the following conclusion and solution:
Conclusion: because OBi connects to Google voice via a "Google talk" configuration, the default configuration for OBi will not yield proper call announce/call screening.
Solution: to overcome this the workaround is for OBi NOT to receive calls directly from Google Voice, and instead 1) within Google voice add an additional forwarding phone (a phone Google voice forwards too) 2) have that phone be a sip or Skype number which can be can directly accessed by your OBi. 3) on your OBi set up that sip/Skype line to ring while keeping Google voice as your primary outgoing line. [ 4)OPTIONALLY: uncheck the forward to Google talk box within Google voice as it won't be needed since you're not directly accessing incoming calls from your OB].
By doing the above OB does not directly receive Google voice calls, but instead receives them via the new sip, etc. line. Because this sip line is not accessed through the Google talk method (as a OB does), it properly receives call announce/call screening from Google voice. Because this sip line is directly accessed by your OBi, the call is instantaneously forwarded from Google voice to OBi with full call announce/call screening capability.
I have tried this and do not find any delay nor quality reduction versus direct access through OB to Google voice.
as stated above, Google voice can remain your primary outgoing trunk.
Good luck
QBZappy:
ccclapp,
I think that you may have lost CID. That alone could be the deal breaker. All inbound call routes in the OBi rely on obtaining proper CID in order to manipulate the call route.
ccclapp:
Quote from: QBZappy on August 23, 2012, 02:11:07 pm
ccclapp,
I think that you may have lost CID. That alone could be the deal breaker. All inbound call routes in the OBi rely on obtaining proper CID in order to manipulate the call route.
QBZappy: could you be more specific? I am not having a CID problem that I am aware of. Under the configuration I described, the CID flow would be:
Incoming call CID-> to Google voice [Google voice set to transmit original call CID]-> Sip line [receiving original call CID passed through Google voice]-> Answered on OBi via direct sip connection to the sip line [receiving original CID and call announce/call screening]
Is there something mistaken in my thinking, or do you mean something other than this?
Thanks
QBZappy:
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
Navigation
[0] Message Index
[#] Next page
[*] Previous page