Setting X_InboundCallRoute to block direct calls to forwarding number on Obi200

<< < (4/5) > >>

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

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

SteveInWA:
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,

Code:

From 'BROOKFIELD VET' SP1(14258958888)


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

wpaobi200:
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,

Code:

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page