I have a Google Voice number set up on SP 1 and regular VOIP services on SPs 2 and 3. The Google Voice number forwards to the number of SP 3. We don't use the actual number on SP 3, so in the interest of cutting down on random junk calls I'd like to block calls to this number. It seems possible but I can't quite get it to work. Apparently you can filter based on "callee" in the X_InboundCallRoute for the SP setup. Additionally, the callee for a forwarded call seems to be different from a directly dialed number, as I'd hope and expect. So what am I doing wrong? Do I need to change any other fields? If the forwarding number is 15555551212, then I set X_InboundCallRoute as follows:
{>15555551212:},{ph}
For testing I tried this:
{>15555551212:aa},{ph}
When I dial the direct number, i.e. 15555551212 in the example, I do indeed get the auto attendant. But calls to the forwarded GV number do not ring through, and eventually go to voice mail. Any help would be appreciated.
Why are you forwarding GV to the SP3 number? If on the Settings page at google.com/voice you untick that SP3 number and tick the 'Google Chat' box, calls to the GV number will go directly to your OBi. Then you can either disable SP3 completely or if you want it for outgoing only, block incoming calls using X_InboundCallRoute.
There are at least a couple reasons for the forwarding. One is to get CNAM provided by the VOIP service. It's nice because it can also read entries directly from your personal phonebook, as well as look up entrees that aren't there. The other reason is to be able to use GV's call screening, which I believe doesn't work if you receive calls directly from Google Voice on the Obi device.
I'm still puzzled why I can't get the Obi phone port to ring with these simple rules. It's got to be something trivial. I tried reversing the logic, putting the pass-through number first, like a whitelist. So if 111-123-4567 is the GV number, the new rule is:
{>11111234567:ph}
This correctly blocks direct calls to the forwarding VOIP line, but does not ring the phone port when 11111234567 is called, so it ends up at GV voicemail. But the default "ph" rule lets all calls ring through just fine.
See Robert's answer here: http://www.obitalk.com/forum/index.php?topic=10466.msg68939#msg68939
Perhaps I misunderstand but how are you expecting your OBi to differentiate between a call coming in to SP3 directly from a caller and one coming in to SP3 as a forward from GV?
Think about what you're doing here. On the one hand you're trying to block calls made directly to your VoIP provider's DID (presumably Callcentric). But you also want calls made to your GV number (that forwards to that same Callcentric number) to ring through. ???
Ask yourself this question. What number is Google Voice using to forward incoming calls to your Callcentric DID? It's the one you're blocking so why would you expect incoming GV calls to ring through?
There are different methods to try and accomplish your goal. You could make a block list of individual numbers on your OBi itself (see link in post above). Personally, I would do it with Callcentric's phone book, groups, and call treatments.
Keep in mind that Google Voice "ignores" (you're welcome, Steve) early media. This means that "most" of the Callcentric call treatments won't work for incoming GV calls. However, they will all work for incoming calls directly to your Callcentric DID number.
Quote from: drgeoff on October 08, 2015, 09:23:37 AM
Perhaps I misunderstand but how are you expecting your OBi to differentiate between a call coming in to SP3 directly from a caller and one coming in to SP3 as a forward from GV?
Google Voice users can control the caller ID that is sent to forwarding phones. You can decide to either have GV send the calling party's CID (the phone number of the person who called your GV number),
or you can have GV send its own number (your GV number) as the CID.
This is useful for people who want to know, for example, if someone calling their forwarding cell phone number is calling them directly on the cell phone, or forwarding from GV.
You can toggle this setting here: https://www.google.com/voice#callsettings (https://www.google.com/voice#callsettings)
So, you'd set GV to send the calling party's CID, and, on the OBi, block the SIP ITSP's CID.
The only "monkey wrench" might be an obscure issue whereby calls forwarded over SIP contain two numbers: the CID of the original calling party, and the CID of the number that is forwarding the original party's call (this is in the "SIP diversion header" field). I don't know if OBi devices see this information, which could cause all calls to be discarded, but a simple test should determine if it does or doesn't matter.
Quote from: SteveInWA on October 08, 2015, 09:40:54 AM
So, you'd set GV to send the calling party's CID, and block the SIP ITSP's CID.
From your explanation I expected you to say "Set GV to send your GV number as CID and set the OBI's X_InboundCallRoute to reject everything else."
But then the CNAM ability is gone which was the whole point of forwarding to SP3 in the first place.
So, if GC sends the calling party's CID, back to my question of how does the OBi distinguish?
Quote from: drgeoff on October 08, 2015, 09:47:29 AM
Quote from: SteveInWA on October 08, 2015, 09:40:54 AM
So, you'd set GV to send the calling party's CID, and block the SIP ITSP's CID.
From your explanation I expected you to say "Set GV to send your GV number as CID and set the OBI's X_InboundCallRoute to reject everything else."
Well, that would work, too, but then all inbound calls would have the same (GV number's) CID, which is pretty useless from a "who is calling me?" perspective. :P
Quote from: SteveInWA on October 08, 2015, 09:40:54 AM
So, you'd set GV to send the calling party's CID, and, on the OBi, block the SIP ITSP's CID.
How would you block the ITSP's CID on the OBi? ??? Wouldn't the calling party's CID be coming through and not the ITSP's CID?
And what does SteveInWA mean when he writes "SIP ITSP's CID"?
I understand the "SIP" bit is to mean "not GV" but what is different about the CID that GV will send and the CID that the ITSP that SP3 is registered to will send.
There is no magic in azrobert's post. It is just a straightforward routeing based on incoming CID.
Quote from: drgeoff on October 08, 2015, 10:14:48 AM
And what does SteveInWA mean when he writes "ITSP's CID"?
Exactly. Clearly neither of us realized he was referring back to a previous post (Robert's method) when he made the blanket statement of "block the SIP ITSP's CID."
Of course Robert's method of maintaining a block list on the OBi will work as will using Callcentric's groups and call treatments. If it's just a few repeating numbers I would use a block list on the OBi. If it was a variety of changing numbers I would block them at Callcentric.
OK guys, I know how much you love calling out my mistakes, so I'll give you this one. ;D
Geoff: I meant, the caller ID of the OP's SIP telephone service provider's inbound (DID) number.
Personally, I think the original issue isn't worth solving anyhow. I almost never get unwanted calls on my Callcentric forwarding DID; thankfully, the random robo-callers haven't found it yet, although I can see where somebody else's number could be an unfortunate victim.
Everyone (I'm in that basket too) makes mistakes sometimes. Leaving erroneous posts unchallenged is unhelpful and frustrating for noobs who otherwise can't understand why things do not work despite their concerted efforts to faithfully follow what is written.
Quote from: drgeoff on October 08, 2015, 10:50:46 AM
Everyone (I'm in that basket too) makes mistakes sometimes. Leaving erroneous posts unchallenged is unhelpful and frustrating for noobs who otherwise can't understand why things do not work despite their concerted efforts to faithfully follow what is written.
Agreed. So, here are three shit-eating grins: ;D ;D ;D It's what happens when I post before drinking my morning four shots of espresso. :o
Thanks for the various responses. Unfortunately I'm still confused. Why is the calling party's CID relevant? We are interested in screening based on the number that was dialed ("callee"), which the Obi device does appear to recognize as different for the two cases. Robert's solution seems to involve a custom digit map for rejecting calls from certain numbers. Does a custom map do something special compared to just putting the list directly in the rules?
Here is what really bugs me. This NOP rule works as expected:
{>15555551212:ph},{ph}
All calls ring through. But change the first destination to the Auto Attendant, and suddenly no calls ring through:
{>15555551212:aa},{ph}
You do get the Auto Attendant if you dial 15555551212, but other calls eventually go to voicemail, with no action on the phone port. Why?
Quote from: drgeoff on October 08, 2015, 09:23:37 AM
Perhaps I misunderstand but how are you expecting your OBi to differentiate between a call coming in to SP3 directly from a caller and one coming in to SP3 as a forward from GV?
I'll reiterate: I didn't originally assume this would be true, but the "callee" number available in the Obi rules seems to be different depending on whether the call was made to the Google Voice number (and forwarded) or made directly to the CallCentric number. This suggests that the original "callee" number survives the forwarding by Google Voice.
Quote from: SteveInWA on October 08, 2015, 10:24:30 AM...
Personally, I think the original issue isn't worth solving anyhow. I almost never get unwanted calls on my Callcentric forwarding DID; thankfully, the random robo-callers haven't found it yet, although I can see where somebody else's number could be an unfortunate victim.
Since we're using GV's call screening/treatments the CallCentric number is basically unprotected. Rather than cross my fingers and hope there's not much junk on the CC number, I'd rather be proactive, and I thought it would just be a simple rule change...
Quote from: wpaobi200 on October 08, 2015, 12:56:11 PM
. . .We are interested in screening based on the number that was dialed ("callee"), which the Obi device does appear to recognize as different for the two cases. . . .
Where do you see that? I don't see the "callee" number in my device's call history.
I see, for example,
From 'BROOKFIELD VET' SP1(14258958888)
The phone number shown here is the Vet's office number, not my Callcentric number.
Quote from: SteveInWA on October 08, 2015, 03:11:04 PM
Quote from: wpaobi200 on October 08, 2015, 12:56:11 PM
. . .We are interested in screening based on the number that was dialed ("callee"), which the Obi device does appear to recognize as different for the two cases. . . .
Where do you see that? I don't see the "callee" number in my device's call history.
I see, for example,
From 'BROOKFIELD VET' SP1(14258958888)
The phone number shown here is the Vet's office number, not my Callcentric number.
The "callee" field is described in the Obi Device Admin Guide. But as for it being different in these two situations, forwarded vs direct, apparently I've entered (or left) bizarro world, as the behavior I observed above is no longer happening. Instead, "callee" is now the CallCentric DID number all the time.
Ok, I think figured it out. I confounded myself by having varying GV settings for the cell phone number I was using to test. Apologies for believing that "callee" could vary in this situation; there wouldn't actually be a mechanism for preserving the value across forwards, would there?
The original problem remains, but I guess without a solution--assuming you're not willing to give up CID.
At risk of stepping in it again, might I speculate that we actually have the hardware to handle this blocking, but probably not the software/firmware? With the GV forwarding as described, we disable forwarding to Google Chat because we're forwarding to the CallCentric DID number on the same device. But, if we enabled this Chat forwarding then wouldn't we be receiving the same call on two SPs? And if this condition could be detected then that would differentiate from the case where the call comes in only on the CallCentric SP. The reality of having slightly different timing on the two SP calls would make things a little messy, but an exercise in speculation isn't necessarily meant to be practical.
Quote from: wpaobi200 on October 08, 2015, 06:44:49 PM
But, if we enabled this Chat forwarding then wouldn't we be receiving the same call on two SIPs? And if this condition could be detected then that would differentiate from the case where the call comes in only on the CallCentric SIP.
An interesting idea and one that I'm sure would be technically possible.
I'm all for being proactive but I would suggest you are trying to solve a problem where none exists. I'm with SteveInWa on this one. I've had my free CC DID for years and in all that time I've had exactly 2 numbers that called my CC DID directly more than once. So I made a block list on the OBi and the problem was easily and quickly solved.
It is also easy to do on Callcentric's superb web portal with call logs, phone book, groups, and call treatments. Once you've made your group and call treatment it is just a few mouse clicks to add a "junk caller" from your call history to your phone book and then add the record to your junk callers group. Done.
As an aside, just to be on the same page regarding jargon you're not really receiving the same call on "two SIPs." SIP is a VoIP signalling protocol. On the OBi you would be receiving the same call on two SP (service provider) trunks. The Callcentric trunk uses SIP as its signalling protocol. The Google Voice trunk uses XMPP as its signalling protocol.
Quote from: Taoman on October 08, 2015, 07:42:19 PM
As an aside, just to be on the same page regarding jargon you're not really receiving the same call on "two SIPs." SIP is a VoIP signalling protocol. On the OBi you would be receiving the same call on two SP (service provider) trunks. The Callcentric trunk uses SIP as its signalling protocol. The Google Voice trunk uses XMPP as its signalling protocol.
Thanks for the correction, Taoman. Obviously a newbie here; not sure why the fingers typed "SIP" given that I was seeing "SP" every time I fiddled with the settings. In any case, I edited the offending posts.