Is privacy-mgr broken?

Hi,

I just noticed (sadly when the wife called) that privacy manager is still letting calls through even though an invalid number (or no number) was entered - I don’t think it’s supposed to work that way?

I get the ‘That number is invalid’ message but then it drops through and rings normally.

Additionally, how can I get privacy manager to also consider a certain phone number to be invalid? e.g. I find that people tend to enter the number they dialled rather than the number they are calling from.

This is Asterisk 1.4.10.1 + latest freePBX.

Thanks,

Chris.

if asterisk is broken wrt to Privacy manager, I don’t know. (I fixed it many many moons ago when it was broken in 1.2 and they put the fix in there). As far as blacklisting numbers, you could try blacklist but I’m not sure if blacklist gets inserted in the right place in the dialplan to be caught after privacy manager (try it), I never use blacklist.

as far as i know, it only fires if there is NO caller ID at all. people send crap all the time, as well as names like anonymous, unknown, restricted, etc… i don’t check the box for PM in freepbx, instead i have code in extensions_custom.conf that runs an agi script i wrote that does various checks on the name, and if present, nulls out the name entirely. the script then invokes privacy manager and zapateller, and since the name&number will be missing for those bogus inputs, the right thing happens…

Well PrivacyManager fires appropriately it just seems to get lost when it exits. It’s supposed to go to PRIVMGR+101 if it was unsuccessful, but it doesn’t:

[size=10] – <SIP/855046-08fcebd0> Playing ‘privacy-incorrect’ (language ‘en’)
– <SIP/855046-08fcebd0> Playing ‘privacy-prompt’ (language ‘en’)
– <SIP/855046-08fcebd0> Playing ‘privacy-incorrect’ (language ‘en’)
– Executing [[email protected]:9] SetCallerPres(“SIP/855046-08fcebd0”, “allowed_passed_screen”) in new stack
– Executing [[email protected]:8] Goto(“SIP/855046-08fcebd0”, “app-daynight|0|1”) in new stack
[/size]
Additionally, adding the number to blacklist doesn’t block the number - I don’t think that’s because of the above though, I think, as you say, it’s an order thing.

C.

Are you giving the ‘j’ option to PM? Wasn’t always required, but it might now be. Additionally, priority jumping is now deprecated. Check the “PRIVACYMGRSTATUS” variable after PM runs to check for failure…

Yep! that was it (thanks). In the end I had to specify PrivacyMgr(3|10|j) – it didn’t like (||j) for some reason.

I guess this also means that privacy.conf is redundant?

So, should I bug this to provide support for 1.4?

C.

I created bug #2296 - but maybe I’m just missing the point here…

about “missing the point”? the default used to be that priority jumping was the default, and at some point (not sure when), it was change so that you have to specify ‘j’. this is simply a case of freepbx needing to be changed to match the underlying function.

if one of you can do a little investigation and report back we can get this fixed. The following needs to be checked on 1.2 and 1.4:

First, does privacy manager return and channel variables we can use to determine success/failure as we can change to that.

Otherwise, what happens when you call it with the format of:

PrivacyManger(,j) - will it use the values set in the conf file? Since we don’t have any way to configure it from gui at this point, these would be alternatives. The you can put in a feature request to be able to configure this, it would not be hard to set it on the GENERAL tab for now.

Please try with different number of digits set in privacy.conf to make sure it is reading if the latter is used.

and post my results.

  1. First of all, missing arguments have never been allowed, so something like ‘PrivacyManager(3,j)’ would never have been legal.

  2. On success, PRIVACYMGRSTATUS is set to “SUCCESS”, otherwise “FAILED”.

  3. ‘j’ is not on by default.

thanks - there are commands that missing arguments are allowed, maybe not this one though.
I’ll create a patch for testing using the PRIVACYMGRSTATUS to see if it is happy on 1.2 and 1.4 with that (so it works whether in ‘j’ mode or not. Will get that into the bug report later today hopefully. (unless someone wants to beat me to it and post it there.)

my wording was sloppy. what i meant was that if you are missing any arguments, you need to be missing all of them from then on. so, for example, in the case of PrivacyManager, you can say:

PrivacyManager (retries, timeout, j)

or

PrivacyManager (retries, timeout)

or

PrivacyManager (retries)

or

PrivacyManager()

e.g. you can’t be missing arguments such that you’d need multiple commans with nothing in between.

Here is a patch to try, can you try it on a failing system and let me know if it fixes it?

[code:1]
Index: extensions.conf

— extensions.conf (revision 4891)
+++ extensions.conf (working copy)
@@ -1032,8 +1031,9 @@
exten => s,n(TESTRESULT),GotoIf($[“foo${TESTCID}”=“foo”]?CLEARCID:PRIVMGR)
exten => s,n(CLEARCID),Set(CALLERID(num)=)
exten => s,n(PRIVMGR),PrivacyManager()
+exten => s,n,GotoIf($["${PRIVACYMGRSTATUS}"=“FAILED”]?fail)
exten => s,n,SetCallerPres(allowed_passed_screen); stop gap until app_privacy.c clears unavailble bit
-exten => s,PRIVMGR+101,Noop(STATUS: ${PRIVACYMGRSTATUS} CID: ${CALLERID(num)} ${CALLERID(name)} CALLPRES: ${CALLLINGPRES})
+exten => s,PRIVMGR+101(fail),Noop(STATUS: ${PRIVACYMGRSTATUS} CID: ${CALLERID(num)} ${CALLERID(name)} CALLPRES: ${CALLLINGPRES})
exten => s,n,Playback(sorry-youre-having-problems)
exten => s,n,Playback(goodbye)
exten => s,n,Playtones(congestion)
[/code:1]

I found that it was useless to me if invoked via the GUI, since it happens too early in the process. e.g. if you want to do things in the custom context for that inbound route, the CID processing is already done. I had to end up turning off CID lookup and PM in the GUI and invoke them in my custom context. also, it would be nice to have zapateller be invokable from the GUI if PM can be…

Of PRIVACYMGRSTATUS being FAILED.

p.s. in the process of testing this, I found out that zapateller is broken. If no callerid was ever present, it works. If there was a CID, but you nulled it by setting CALLERID(all) to “”, there is a cid_num pointer, but it points to a null string, unfortunately, zapateller only checks if the pointer is null. i will open a bug at digium bugtracker.

[quote=“p_lindheimer”]Here is a patch to try, can you try it on a failing system and let me know if it fixes it?
[/quote]

Sorry, I posted a response in the bug. I tested this on 1.4.10.1 (to the extent that I wanted it to work) and it seems to work just fine, i.e. behaves as I’d expect.

Unfortunately I don’t have a 1.2 system any more to test on.

Thanks,
Chris.

Although I have noticed that the CID recorded (or reported in CDR) is ‘asterisk’ not the number I entered to get past the screen… :confused:

I have spent some time today trying to get the privacy manager to work for our line(s). I have taken a look at the information in this thread and applied the above patch to extensions.conf. However, my problem is with the logic. Maybe I am missing something, but the logic to take the callerid number and add one (excluding the + at the start of the number) seems inadequate. The line I am talking about are here:

exten => s,n(TESTRESULT),GotoIf($[“foo${TESTCID}”=“foo”]?CLEARCID:PRIVMGR)

This line assumes that the addition of 1 to the CALLERID(num) will not have any effect, resulting in an empty string if the caller ID is missing? Since the CALLERID(num) is likely to be zero in a lot of cases for a missing number, would it not make sense to also test for zero as a special case? I inserted the following line right after the KEEPCID= line to handle a caller ID number of zero.

exten => s,n,GotoIf($[${CALLERID(num)}=0]?CLEARCID)

With this line present, privacy manager is now catching calls with at least Private Number. Is there a reason that this check was not included in the code by default? Is this not a good check to include? Any insight would be very much appreciated. Thanks.

Mike