Can anyone anyone point me to greater detail on using the context option in PrivacyManager. I’m currently revamping my extensions.conf in a move from *1.4 to *1.8. What documentation I have been able to find says that the context allows for pattern matching in the specified context. None of the documentation I have been able to find makes clear if PrivacyManager reports “FAILED” if the pattern entered matches a pattern in the specified context. A short example of the context would shorten the work greatly.
Howdy,
Looks like there’s a quick example of using PrivacyManager to fail out here:
the-asterisk-book.com/unstab … nager.html
It should only report FAILED in the event that it didn’t find an extension in the specified context that matches what the user enters.
If you’ve got a context that’s like:
[mysearchcontext]
exten => 1234,1,NoOp()
exten => 5678,1,NoOp()Then if the user enters anything other than 1234 or 5678, FAILED will be returned. If the user enterst either of those, SUCCESS will be returned.
The example linked to should give you an idea how what to do with the FAILED and SUCCESS variables.
Thanks for the example. Now I know how to set up the context option. Unfortunately it won’t be much use to me. To protect privacy (to me) it would have been better if the design was to report failure on matching to unacceptable patterns such as the caller entering my number or numbers such as xxx5551212 or 1234567890.
So reverse the logic then and put those numbers as patterns in the context you specify.
Thanks Malcolm: That occurred to me but what do I do then with CID that is a valid ten digits long but not specified in the context. Currently in 1.4 this is what I have in
[incoming]
include => parkedcalls
exten => s,1,Zapateller(answer|nocallerid)exten => s,n,PrivacyManager()
exten => s,n,GotoIf($["{PRIVACYMGRSTATUS}"=“FAILED”]?bad,s,1)
exten …
[bad]
;failed privacy check
exten => s,1,Playback(privacy-unidentif)
exten => s,n,Playback(vm-goodbye)
exten => s,n,Hangup()
Maybe I’ll just put unacceptable CID into my BLACKLIST
You can do pattern matches in that context, e.g. _800XXXXXXX
Cheers.
HI Malcolm: I’ve tried your four digit example and it fails ie PRIVACYMGRSTATUS = “FAILURE”
exten => s,n,PrivacyManager(3,1,BadPatterns)
allows me the three tries on input of 1234
then reports FAILURE
if I do a pattern match: _XXX5551212
how do I determine if it matches the 10 digit requirement or if the pattern is matched?
There’s a typo on the wiki page, and thus in the documentation. It seems as though the “options” option doesn’t exist in 1.8 as it did in 1.4, and all of the code relative to the “options” option didn’t get removed. So, until we get that corrected, you can call it like:
PrivacyManager([maxretries[,minlength[,,context]]])
See the two commas before “context” there.
That should work just fine.
e.g.
[myinboundcontext]
exten => s,1,Set(CALLERID(all)="")
exten => s,n,PrivacyManager(1,4,,testnumbers)
exten => s,n,NoOp(${PRIVACYMGRSTATUS})
exten => s,n,GotoIf($["${PRIVACYMGRSTATUS}" = "SUCCESS"]?pm-success:pm-fails)
exten => s,n,Hangup
exten => s,n(pm-success),Background(demo-congrats)
exten => s,n,Hangup
exten => s,n(pm-fails),Background(goodbye)
exten => s,n,Hangup
[testnumbers]
exten => 1234,1,NoOP()
exten => 5678,1,NoOp()Here a call comes in, I’m forcing the CID to nothing so that PrivacyManager gets triggered (I’m calling from a SIP phone in my test, so I have to do this otherwise PrivacyManager doesn’t run), I run PrivacyManager with 1 try for 4 digits and I check the testnumbers context (notice the two commas as mentioned above…that’s a documentation issue). I then do a GotoIf and check the PRIVACYMGRSTATUS channel variable. If it’s true (SUCCESS) then I jump to the pm-success label. If it’s false (FAILED) then I jump to the pm-fails label. If success, I Background demo-congrats and hangup. If failure, I Background goodbye and hangup.
The extensions that I check for in testnumbers are 1234 and 5678. Here’s what happens if I punch in 1234 from a SIP peer called malcolm. Note that I mapped this to extension 115 for my test (I was in a hurry).
-- Executing [115@testing:1] Set("SIP/malcolm-0000000f", "CALLERID(all)=""") in new stack
-- Executing [115@testing:2] PrivacyManager("SIP/malcolm-0000000f", "1,4,,testnumbers") in new stack
-- <SIP/malcolm-0000000f> Playing 'privacy-unident.ulaw' (language 'en')
-- <SIP/malcolm-0000000f> Playing 'privacy-prompt.ulaw' (language 'en')
-- <SIP/malcolm-0000000f> Playing 'privacy-thankyou.ulaw' (language 'en')
-- Changed Caller*ID number to '1234'
-- Executing [115@testing:3] NoOp("SIP/malcolm-0000000f", "SUCCESS") in new stack
-- Executing [115@testing:4] GotoIf("SIP/malcolm-0000000f", "1?pm-success:pm-fails") in new stack
-- Goto (testing,115,6)
-- Executing [115@testing:6] BackGround("SIP/malcolm-0000000f", "demo-congrats") in new stack
-- <SIP/malcolm-0000000f> Playing 'demo-congrats.ulaw' (language 'en')
-- Executing [115@testing:7] Hangup("SIP/malcolm-0000000f", "") in new stack
== Spawn extension (testing, 115, 7) exited non-zero on 'SIP/malcolm-0000000f'And here’s what I get if I punch in 7777, something that doesn’t match from the specified context:
-- Executing [115@testing:1] Set("SIP/malcolm-00000010", "CALLERID(all)=""") in new stack
-- Executing [115@testing:2] PrivacyManager("SIP/malcolm-00000010", "1,4,,testnumbers") in new stack
-- <SIP/malcolm-00000010> Playing 'privacy-unident.ulaw' (language 'en')
-- <SIP/malcolm-00000010> Playing 'privacy-prompt.ulaw' (language 'en')
-- <SIP/malcolm-00000010> Playing 'privacy-incorrect.ulaw' (language 'en')
-- Executing [115@testing:3] NoOp("SIP/malcolm-00000010", "FAILED") in new stack
-- Executing [115@testing:4] GotoIf("SIP/malcolm-00000010", "0?pm-success:pm-fails") in new stack
-- Goto (testing,115,8)
-- Executing [115@testing:8] BackGround("SIP/malcolm-00000010", "goodbye") in new stack
-- <SIP/malcolm-00000010> Playing 'goodbye.gsm' (language 'en')
-- Executing [115@testing:9] Hangup("SIP/malcolm-00000010", "") in new stack
== Spawn extension (testing, 115, 9) exited non-zero on 'SIP/malcolm-00000010'So…try it again, toss in an extra comma.
HI Malcolm: Thanks for filling in and providing all the detail. I’ll try that (tomorrow unfortunately). I’m running a test-bed set-up as I switch to *1.8 using an internal context (via DAHDI). I was forcing CALLERID to null but I note that somewhere I read that in 1.8 the following is required
exten = s,1,Set (CALLERID(num)=)
I note that your snippet uses:
exten => s,1,Set(CALLERID(all)="")
Is mine correct for my example and is yours “” because you’re setting all (name and num) to null?
Only num is important for PrivacyManager; I used all in my example for no particular reason.
Cheers.
Hi Malcolm: Adding in the comma made PrivacyManager use the context to check for valid patterns.
However inverting the logic i.e. testing for “SUCCESS” after PrivacyManager(3,10,BadPatterns) checks the patterns in [BadPatterns] doesn’t give the functionality I was looking for.
I wanted to use PrivacyManager in two situations:
First in the case where no CID is received:
1.Suppose the caller enters a valid number (i.e. as defined by BadPatterns) then testing for “Success” could send the caller to a bad call handler.
2.Suppose the caller enters a non-valid number(not in BadPatterns) PrivacyManager allows the other tries. HOWEVER THE NUMBER ENTERED WAS REALLY A TRUE NUMBER.
It could work if only one try was allowed but it wouldn’t allow for the situation where someone genuinely slipped in entering a number. That situation is more relevant to the second case where I wanted to use PrivacyManager.
Second case when a CID of “BLOCKED” is received and for which I test. Locally I get Blocked numbers from Cell-phone users
- I force CID to a null.
- I force the caller to input a number using PrivacyManager
- They get three tries because the opportunity to mis-enter a number especially on a cell-phone is high.
- If the number entered on the first attempt, for example, is the caller’s true number PrivacyManager fails and allows a retry. They would have to enter the number three times before the call could proceed.
In both cases calls are coming in on a POTS line.
To me the functionality of PrivacyManager using the context option would have been much greater if the test had been for invalid patterns and PrivacyManager failed on a match to an invalid pattern being specified in the context option,BadPatterns in my example.
Maybe the design team would consider for a future release adding an option to toggle the functionality of PrivacyManager to what I have described.
Malcolm, thanks again for clarifying the syntax for PrivacyManager.