Re-directing Anonymous Calls

[Diana]

Currently, I setup my OBi110 to not ring the attached phone when "Anonymous" calls come in on SP1, which is setup with Google Voice.  I have VOIP.ms on SP2 and Callwithus on Voice Gateway3.

When an Anonymous (Unknown) call comes in, the call eventually ends up in the GV Voicemail after 5 rings.  Is it possible that I can send these Anonymous calls to another unused GV number which would be setup to go to voicemail immediately, with the announcement that callers who do not allow the delivery of their caller ID or blocked ID will not be accepted.  How do I setup the redirect of these Anonymous calls to another GV Number.  I'm currently using:

"{(?):}" in the "X_InboundCallRoute"

[RonR]

"{(?):}" in the "X_InboundCallRoute"

That's not a valid rule.  Inside parenthesis, a ? is a modifier meaning 0 or 1 occurrences of the previous element (which doesn't exist in this case).

To block an anonymous caller, the rule would be : {?:}

To send an anonymous caller to another trunk (for eample, SP2), the rule would be : {?:sp2(number)}

[Diana]

Thanks RonR:  I made the change on the "{?:}" block.  If I need to send these Anonymous calls out through SP2 with the destination to Goggle Voice #2, NXXNXXXXXX, what would be the proper syntax in the InboundCallRoute and are their any other changes required to send the call to the other GV number?

[RonR]

To redirect anonymous calls out SP2 to another number : {?:sp2(18005551212)}

Place this rule on the approrpiate InboundCallRoute(s) and they should be on their way to elsewhere.

[Diana]

To redirect anonymous calls out SP2 to another number : {?:sp2(18005551212)}

Place this rule on the approrpiate InboundCallRoute(s) and they should be on their way to elsewhere.

Just made the change to the "X_InboundCallRoute" for SP1, which is my Primary Line, but the calls are not getting redirected and I end up with the GV Voice Mail Box.  I try the forwarding GV number with and without the leading 1; 12125551212 [ {?:sp2(12125551212)} ] and 2125551212 [ {?:sp2(2125551212)} ]

The incoming blocked calls are definitely not ringing the Phone and does not show up on the call History of the OBi110.  Is there something else I should modify to get this to work.  Thanks.

[Diana]

Afterfurther testing, I found out why the calls kept going to voice mail of the Google Voice Number of my Primary Line (GV #1).  Apparently after transferring the call, GV #1 some is still in place and that that VM pickups the call and you hear the GV #1 announcement.  The calls do get transferred, via my SP2 SIP Account (VOIP.ms), from GV #1 to GV #2 and shows up in the call log of GV #2, i.e, the VOIP.ms Number is what shows up in the GV #2 log.  

Once I enable "Do Not Disturb" on the latter GV Number (GV #2), the Voice Mail of this GV #2 kicks in immediately and callers does not get any ring tones whatsoever when they call the primary GV Number (GV #1)!!!  This is exactly how I want it to appear to unknown/blocked numbers.

Thanks again for you help RonR!!

[RonR]

You cannot forward calls to your own Google Voice number using the trunk that is that number.  It's the same as calling your own Google Voice number : you end up checking your Google Voice voicemail.  It's the nature of the beast when it comes to Google Voice (it's not the OBi's doing).  If you have two different Google Voice accounts (i.e. one on SP1 and another on SP2), SP1 can call SP2 and vice-versa.

[RonR]

Once I enable "Do Not Disturb" ...

Don't enable Do Not Disturb or Call Forwarding in the OBi on any SP1, SP2, or LINE Port trunks that have any InboundCallRoute rules (other than ph) as there's a bug in the OBi that causes all InboundCallRoute rules to be ignored if you do.  In the case of Call Forwarding, all your blocked anonymous calls will be forwarded to your forwarding number instead of being blocked.

[Diana]

Once I enable "Do Not Disturb" ...

Don't enable Do Not Disturb or Call Forwarding in the OBi on any SP1, SP2, or LINE Port trunks that have any InboundCallRoute rules (other than ph) as there's a bug in the OBi that causes all InboundCallRoute rules to be ignored if you do.  In the case of Call Forwarding, all your blocked anonymous calls will be forwarded to your forwarding number instead of being blocked.

Couple of things:

1) I have two different GV accounts with two different GV Numbers (GV #1 and GV #2)

2) I enable the Do Not Disturb within he Voice Settings of the Google Voice account associated with GV #2, not the OBi110.  You have sensitize us to the pitfalls of engaging it in the OBi110 itself 

3) VOIP.ms is setup on SP2 and is used primarily for e911, so the outgoing calls are going out on a separate trunk than the incoming GV call.

I kept going back and editing my post while you were typing, so it might have been confusing.  Let me know if what I did was correct....it seems to be working the way I envision it to work.

[RonR]

3) VOIP.ms is setup on SP2 and is used primarily for e911, so the outgoing calls are going out on a separate trunk than the incoming GV call.

Just for clarification...

The problem wasn't the call going out on the same trunk as the incoming call.  The problem (Google Voice considers it a feature) is that you can't call your own Google Voice number from your Google Voice number and do anything other than check voicemail.  If that's what you were already aware of, my apology for stating it again.

[RonR]

2) I enable the Do Not Disturb within he Voice Settings of the Google Voice account associated with GV #2, not the OBi110.  You have sensitize us to the pitfalls of engaging it in the OBi110 itself 

I only wish Obihai was sensitized to the seriousness of this problem.

[VulcanTourist]

The information in this thread is useful, but only to a point because it's incomplete.  The syntax suggested does in fact re-route anonymous calls, but it also has the effect of not ringing the attached phone for any other calls and instead sending them to voicemail.  This is because the required ,{ph} was not appended to the directive.  Further, accomplishing this feat with only Google Voice accounts apparently requires the creation and use of three accounts and not just two: the first as a primary line and phone number for SP1, the second as an account to enable SP2, and the third to provide a forwarding number distinct from both SP1 and SP2.  (Note that the account used to create SP2 doesn't necessarily need a Google Voice incoming phone number created, if SP2 is only used for this purpose.)  This is in because calling a Google Voice number from its own account or associated forwarding phone(s) automatically drops into voicemail management.  In my experimentation I found that it could be done with just two accounts, if the syntax is modified to {?:sp1(sp2number)},{ph}, but only if one doesn't mind having the attached phone ring ONCE with every forward.  I didn't try a stunt using just two accounts and the syntax {?:sp2(sp1number)},{ph}, simply because that's just so cyclical it seemed destined to fail, but perhaps even that would work.

So the complete syntax to accomplish this using (three) Google Voice accounts is:

SP1 Service | X_InboundCallRoute = {?:sp2(GV3number)},{ph}

where GV3number is the incoming-calls number created for the third Google Voice account, and that third account would also have the Google do-not-disturb feature enabled to send calls straight to voicemail (for the announcement).  This will block anonymous calls to SP1 and ring the attached phone for all others.  If this is the only documentation for this technique, at least it's fully documented now.


P.S. The same could also be done for the PSTN LINE, if that landline has Caller ID service active:

LINE Port | InboundCallRoute = {?:sp2(GV3number)},{ph}

GV3number in this case could probably be replaced by sp1number and still work fine, but if you already have that third GV account and number for the foregoing why not use it there also?

[Diana]

I'm not sure what you are saying here.  I have this setup and working with only two Google Voice accounts and I do not get any ringing on the Phone attached to my OBi110.  I enable the DND on GV2.  The outbound call forward is actually done using the second channel of GV1, so my syntax for SP1 inbound is:

SP1 Service | X_InboundCallRoute = {asterisk:},{sip:},{unknown:},{(xxx):},{(xxxx):},{(xxxxx):},{'asterisk':},{('asterisk'):},{?:sp1(1aaaxxxxxxx)},{ph}

Where aaaxxxxxxx is the GV2 number.  Again, with the DND enable, the caller hears one/half? ring and immediately hears the announcement, with the no ring tones from the OBi110 attached phone  (I will have to confirm this, since I don't remember hearing one).  BTW, I have the same rule for SP2, which is setup with Anveo (previously) VOIP.ms.  I do not get what you are saying about the need for three GV accounts/numbers.  Also, the details reference above was not meant to be exhaustive, hence the missing {ph} and other missing parts of the inbound call route.....kinda obvious that it is needed!

EDIT:  I did confirm that an unknown caller will not ring the Phone port using the scheme described above with two GV Numbers!!!

The information in this thread is useful, but only to a point because it's incomplete.  The syntax suggested does in fact re-route anonymous calls, but it also has the effect of not ringing the attached phone for any other calls and instead sending them to voicemail.  This is because the required ,{ph} was not appended to the directive.  Further, accomplishing this feat with only Google Voice accounts apparently requires the creation and use of three accounts and not just two: the first as a primary line and phone number for SP1, the second as an account to enable SP2, and the third to provide a forwarding number distinct from both SP1 and SP2.  (Note that the account used to create SP2 doesn't necessarily need a Google Voice incoming phone number created, if SP2 is only used for this purpose.)  This is in because calling a Google Voice number from its own account or associated forwarding phone(s) automatically drops into voicemail management.  In my experimentation I found that it could be done with just two accounts, if the syntax is modified to {?:sp1(sp2number)},{ph}, but only if one doesn't mind having the attached phone ring ONCE with every forward.  I didn't try a stunt using just two accounts and the syntax {?:sp2(sp1number)},{ph}, simply because that's just so cyclical it seemed destined to fail, but perhaps even that would work.

So the complete syntax to accomplish this using (three) Google Voice accounts is:

SP1 Service | X_InboundCallRoute = {?:sp2(GV3number)},{ph}

where GV3number is the incoming-calls number created for the third Google Voice account, and that third account would also have the Google do-not-disturb feature enabled to send calls straight to voicemail (for the announcement).  This will block anonymous calls to SP1 and ring the attached phone for all others.  If this is the only documentation for this technique, at least it's fully documented now.


P.S. The same could also be done for the PSTN LINE, if that landline has Caller ID service active:

LINE Port | InboundCallRoute = {?:sp2(GV3number)},{ph}

GV3number in this case could probably be replaced by sp1number and still work fine, but if you already have that third GV account and number for the foregoing why not use it there also?

[RonR]

I'm not sure what you are saying here.

I think VulcanTourist missed the fact that our earlier discussion in this thread was about a single rule and not an entire InboundCallRoute set of rules.

SP1 Service | X_InboundCallRoute = {asterisk:},{sip:},{unknown:},{(xxx):},{(xxxx):},{(xxxxx):},{'asterisk':},{('asterisk'):},{?:sp1(1aaaxxxxxxx)},{ph}

There's now a much better way to get rid of all the annonying fake calls from SIP scanners than using all those ugly rules in your InboundCallRoute(s):

Service Providers -> ITSP Profile x -> SIP -> X_AccessList

Place the IP addresses of your service provider and any other legitimate callers (via SIP URI) in this list (separated by commas) and you can remove all those ugly rules.  I've been using this approach for over 6 months now and haven't been troubled a single time by the scum who used to wake me up every night.

[Stewart]

For SP1 Service, changing X_UserAgentPort from 5060 to e.g. 5070 should eliminate calls from scanners.  If you had to forward port 5060 in your router (to work around a router problem), forward the new port instead.

[RonR]

For SP1 Service, changing X_UserAgentPort from 5060 to e.g. 5070 should eliminate calls from scanners.  If you had to forward port 5060 in your router (to work around a router problem), forward the new port instead.

This leaves one with a non-standard setup.  I much prefer to leave things standard and simply block the bad guys by only letting the good guys in.

[Stewart]

This leaves one with a non-standard setup.  I much prefer to leave things standard and simply block the bad guys by only letting the good guys in.

It's only non-standard if you are having SIP requests come into the device directly, without a provider.  Most softphones and some ATAs, e.g. Grandstream, listen on a port other than 5060.  The OBi does, too, for SP2.  Perhaps I should have suggested to the OP to use SP1 for GV and SP2 for SIP, but that would be a much larger and error prone change.

The problem with X_AccessList is that it won't accept domain names, but is limited to numeric IPs, so a change at the provider may cause your system to stop working, without warning.  Also, the documentation is unclear -- it says "... IP addresses that are allowed to send SIP requests ...".  If SIP responses get through anyway, that's good, in the sense that your 911 call won't fail.  But boy, is that an obscure problem "I'm registered ok and can make outbound calls, but incoming calls go to voicemail, after a long delay.  What could be wrong?"

[infin8loop]

Regarding Service Providers -> ITSP Profile x -> SIP -> X_AccessList

If one chooses not to use the above or monkey around with SIP ports, is there any real danger that a scanner is going to do anything other than make an annoying phone call to you?   By this I mean, would they be able to exploit the OBi by making an outbound call on SPx, VGx, line port, etc?  Earlier today when I typed the voip.ms ip address into X_AccessList I thought of the same issue that Stewart mentioned about the ip address possibly changing.  I have no idea how providers handle failovers but it seems plausible they might change the dns entry to point to a different backup server/ip address.     

[Stewart]

is there any real danger that a scanner is going to do anything other than make an annoying phone call to you?

If the InboundCallRoute for the SPx in question just goes to the Phone port, there is no issue.  However, if it lets certain callers make outbound calls on your system, then an intruder could spoof the magic caller ID and drain your account.  With POTS or another postpaid service, your risk could be quite high.  However, this assumes that the attacker knows what number to spoof, and if he does, he could probably rip you off anyway, by simply calling your DID from a spoof-friendly VoSP.

It's conceivable that the OBi has a vulnerability that would allow an unauthenticated attacker to exploit a bridging setup, but nothing like this has yet been reported.

[VulcanTourist]

I am personally not plagued by unwanted SIP or Asterisk or any other high-tech sorts of calls.  I took the discussion to be about blocking calls that simply don't have Caller ID info, and that was what I addressed.  My primary point was that the rule being discussed was partial and incomplete and assumed more knowledge on the part of the audience than is reasonable.  The rule being discussed, if used literally, would fail to be useful because it would never ring an attached phone, even for the wanted calls.  It lacked the necessary ,{ph} to accomplish that.

This is a recurring problem in discussions in this forum: too much is assumed about the knowledge or skillset of the readers.  Some people conversing here seem to forget that this is a de facto public knowledgebase and not a private e-mail conversation.  My post was an attempt to summarize and presume far less, for the benefit of people who don't know anything about ATAs and how to configure them.

The rule I described in detail, used exactly as I described, has been working fine for me to stop unwanted callers from ringing my phone, but still warn them off and give them a chance to leave a message if they're really legitimate.  It also gives me a call history to track in GV and the Obihai, which I wouldn't get if I simply blocked the anonymous calls.  If I had Caller ID service on my PSTN line, I'd also transfer the same rule to the Line service and stop them from getting through there as well.