Is there any feature to automatically answer calls, especially from the PSTN line, that come with Caller-ID information matching say a telemarketer who has been told, under penalties of telephone harassment, to cease calling here? Some special handling could be to answer and hang up, or answer with a special message, or answer and bridge the call out to the local police or some other appropriate call forwarding destination.
To have the caller ignored (they will hear endless ringing):
Physical Interfaces -> LINE Port -> InboundCallRoute : {12341234567:},{ph}
To forward the caller elsewhere:
Physical Interfaces -> LINE Port -> InboundCallRoute : {12341234567:sp1(18005551212)},{ph}
where 12341234567 is the calling number.
You could always forward such calls to one of the numbers on this page:
http://www.humorhotlines.com/rejectionhotline.asp
Very excellent! I just learned something (very cool bit of programming) and got entertained (again and again - LOL).
I see that there are already some entries in this field related to my circle of trust.
Its not obvious to me how to extend what is there to include a list of unwanted caller ID strings.
Could I please see an example configuration for how to add this new capability to the existing capability?
I am also not quite clear on the terminology for the outbound route, such as if I have an Obi110 with a local PSTN line, a SIP provider, and a Google Voice number. If its an inbound PSTN call I guess the outbound call should go via Google Voice. What would happen if an inbound PSTN call comes in while I am already using the Google Voice line?
Is there any way to improve this with a level of indirection such as to have a table of unwanted numbers to reference within this rule, but the rule remains static? Perhaps one of these rejection hotlines will someday add a full SIP specification that the Obi could use regardless of the state of the SIP or Google Voice virtual ports? And perhaps there is a way to place that SIP call including the true originator's caller-ID, not the Obi's, since its a virtual call?
Quote from: rob613@gmail.com on March 27, 2012, 04:13:17 PM
Is there any feature to automatically answer calls...that come with Caller-ID information matching say a telemarketer...? Some special handling could be to answer and hang up, or ... forward.
Why bother with forwarding? If it is a junk caller, just hang up. (That's what the blocking software on my cell phone does, and what my Callcentric rules do.) At best, if you were unsure, you'd send them to voice mail.
QuoteIs there any way to improve this with a level of indirection such as to have a table of unwanted numbers to reference within this rule, but the rule remains static?
You are looking for functionality that is going to be painful - if even possible with the current firmware - to implement in an OBi. If they specifically added support for user-friendly call routing rules, then yes.
The easy solution would be to use Callcentric, which provides a web UI for creating rules like you want. If you want to "firewall" more than just your inbound SIP calls, then maybe the solution is to have your OBi forward everything to Callcentric, and then have it proxy it back to you. (Obviously this could reduce reliability and quality, as Callcentric's servers will remain in the middle of all calls.)
Aside from various approaches where you outsource things to Callcentric or Google Voice, the only other option that comes to mind is to have the OBi do a SIP hand-off to a SIP proxy that you run on a local server, where you can then implement rules to drop the call, or forward it to someplace where you have voice mail. (In this case you could use SIP forwarding - like an HTTP redirect - so your proxy doesn't have to remain in the middle. But a POTS or GV inbound call would still keep your OBi tied up until the caller is done leaving voice mail.) I'm also not sure where you'd terminate "normal" calls. I don't think you could bounce them back to the originating OBi, so you'd need a 2nd one or another SIP phone.
QuoteAnd perhaps there is a way to place that SIP call including the true originator's caller-ID, not the Obi's...
Should be no problem with SIP forwarding. Any SIP proxy should handle this.
QuoteI see that there are already some entries in this field related to my circle of trust.
Doesn't that also imply that the field is being managed by the Obitalk web UI? And if you are going to customize it, you'd have to uncheck the default checkbox and break the link? Probably not what you want to do if the circle of trust feature depends on that and you are using that functionality.
QuoteIts not obvious to me how to extend what is there to include a list of unwanted caller ID strings.
Post what you currently have (anonymize the numbers as necessary).
The earlier suggestion was to have this for an inbound call route:
Physical Interfaces -> LINE Port -> InboundCallRoute : {12341234567:sp1(18005551212)},{ph}
It was not clear to me how to parse this, and thus how to extend it. Even more complicated is that I already have a customized entry there I think due to the trusted callers.
By inspection it seems that this is a comma-separated list of curly-brace delimited expressions of (a):(b), and where (a) is an '|' separated list of caller-ID's, an (b) can be "aa" for the Obi auto attendant, "ph" [without an (a) part] to ring through to the phone port, or sp1(nnn) to forward out through service SP1 to some number nnn.
I have been able to make it work to forward calls from a handful of repeat offender telemarketers (having used my own test line) to forward to one of the rejection lines. Unfortunately my home phone does ring while the forwarded call is being initiated, but this should provide some improvement.
If there are any SIP specifications of useful intercept recordings to forward to, especially one to use for telemarketers in violation of my clearly explained preferences, please update them here. I think SIP specifications will be useful since they should initiate faster and remain free to operate.
Ideally an SP2(cid:nnn) syntax could be used to place the SIP call with the actual caller's caller-ID with some special symbol to match the caller's CID info. I hope Obi can add this or tell us how to do it.
Quote from: rob613@gmail.com on May 09, 2012, 03:46:29 PM
It was not clear to me how to parse this, and thus how to extend it.tell us how to do it.
See the OBi Device Administration Guide (http://www.obihai.com/docs/OBiDeviceAdminGuide.pdf).
Based on information in another thread I updated my configuration for this matter by adding two custom digit maps. My one map trust and my other map reject.
My line for handling the incoming calls now references through these maps for lists of numbers to trigger upon.
I have two concerns.
1) it doesn't work yet - I need to comb through the other posting better to see if I did something wrong
2) even if it worked, its still to heavy a solution... any minor change such as adding a new number to my list of numbers to reject, the Obi110 requires a reboot for the change to take effect. A map is probably too heavy for what I want here, just a lightweight list of numbers that can be updated without a reboot.
The other thread brings me to seeing a great feature that I think is worth extending, so I'll post about that in another message on this thread.
In this other thread - http://www.obitalk.com/forum/index.php?topic=2327.0 - I see a useful technique for passing on through $1 the caller-ID of the caller whom the auto-attendant should call back.
In my case of wanting to use the Obi110 to answer and dispose of calls that I wish to reject based on CID, I think there is another use for passing an argument of $1, and that is a good case to spoof the caller-ID of the real caller on my PSTN line.
The behavior I want is to generate a custom message with text to voice live on the fly which reminds the caller that they were asked to not call here again in a prior call and that the date and time of the call has been logged for consequences against them.
The behavior I am getting is force-fitting these calls to forward to a rejection hotline using my SP1 call out. Since that is a GV or SIP call I should be able to use the Caller-ID-spoofing technique to just call a special number which speaks the caller-ID of the caller for test purposes even if I cannot customize it to be more scary for the caller. Even better is if I can have a custom scare the caller line set up on some SIP number at some PBX or provider to do that for me and for any others who want this feature.
FEATURE REQUEST:
Obi110 should permit forwarding through sp1 or sp2 not just with a single parameter for the number I wish to forward the call to, but a second parameter for the caller-ID to use when forwarding.
For a trusted caller I might also want this feature so that calls I place for them inherit their caller-ID, and not the caller-ID of my Obi box. The difference would be that they are calling a real number, and not a rejection line.
got it working now - the method works
a few custom digit maps and one short rule
rob613,
Well, how did you do it?
Just to be clear, the part I got working was separating out my long unmanagable rejection forward with an increasing list of brothersome CID's without breaking my list of trusted callers who get the auto attendant, which is now in another list.
Part one:
In the line port configuration for InboundCallRoute I now have:
{(Mreject):sp1(nnn)},{(Mtrust):aa},{ph}
where nnn is a particular rejection hotline number I picked from the list posted earlier
http://www.humorhotlines.com/rejectionhotline.asp by another user
Part two:
Under user-defined digit maps I set up two of them.
First one I called "trust" and the second one I called "reject".
Each is of the form of within a single pair of parentheses, a |-delivered list of numbers such as:
(5672559999|8008291040)
I'm still tinkering with other options for example to see if I can find anyone with an Asterisk server running the "monkeys" audio clip to which I could forward the call. Even better would be a dedicated outbound SIP server, such as tf.callwithus.com, that could be passed the actual caller's CID to generate on the fly a custom message that repeats back the caller-ID that is unwanted.
I dare anyone on this list to do that! Contact me privately for how I think this might be a good business opportunity for someone good at dissuading folks from calling again, such as by collecting under the FCC's rule for the penalty cost per call. It could be a great service to the entire Obi110 community who get unwanted calls on their PSTN line without any upstream filtering capability.
Interesting thread. Aside from length limitations in the Obi, the other is inserting and deleting numbers could be cumbersome and error-prone. As suggested using the resources of a SIP provider (remote) or simply one on a local server (plug computers would be suited for this role).
Adding numbers is easy - just insert at the head, after the "(" and with its own "|" and after callers get the message a few times, delete them off the end if the list is too long.
Unfortunately each new number requires an edit with a form submission after scrolling down the page, and followed by a reboot of the obi.