Re-directing Anonymous Calls
RonR:
Quote from: Diana on July 30, 2011, 05:08:56 pm
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 ;D
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!!!
Quote from: VulcanTourist on February 23, 2012, 06:41:04 am
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:
Quote from: Diana on February 23, 2012, 09:20:40 am
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.
Quote from: Diana on February 23, 2012, 09:20:40 am
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page