Setting X_InboundCallRoute to block direct calls to forwarding number on Obi200

[wpaobi200]

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.

[drgeoff]

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.

[wpaobi200]

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.

[SteveInWA]

See Robert's answer here:  http://www.obitalk.com/forum/index.php?topic=10466.msg68939#msg68939

[drgeoff]

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?

[Taoman]

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.

[SteveInWA]

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

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.

[drgeoff]

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?

[SteveInWA]

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.  

[Taoman]

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?

[drgeoff]

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.

[Taoman]

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.

[SteveInWA]

OK guys, I know how much you love calling out my mistakes, so I'll give you this one.  

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.

[drgeoff]

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.

[SteveInWA]

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:      It's what happens when I post before drinking my morning four shots of espresso.

[wpaobi200]

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?

[wpaobi200]

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.

[wpaobi200]

...
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...

[SteveInWA]

. . .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,

Code Select Expand


From 'BROOKFIELD VET' SP1(14258958888)


The phone number shown here is the Vet's office number, not my Callcentric number.

[wpaobi200]

. . .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,

Code Select Expand


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.