I’ve been testing Privacy Manager functionality after a client reported it did not seem to be working. Before I burn too much time I would like to report what I think I’m seeing as a pattern and see if anyone can point me at a known bug or other insights.
When calling in with no CID (*69) it drops into Privacy Manager fine. I enter the phone number fine. It then exits (without saying thank you) and proceeds through the dial plan but the CID name and number are Unknow.
Repeating the test, same thing but hit # after entering the number. It then says thank you and proceeds. This time it has “Privacy Manager” as the name and XXXXXXX as the CID number (what ever I put in). It goes on as you would expect.
I thought I had done some earlier tests where I did not have to hit # but I may be mistaken. In either case, this is clearly incorrect behavior. Please let me know if there is anything known about this. I did some searching around to no avail and don’t want to burn lots of hours before checking here.
thanks,
p
p.s. tested on 1.2.4 and 1.2.5
A couple of other tidbits after further testing. First, in the case where # is pressed, it returns SUCCESS to ${PRIVACYMGRSTATU} and FAILED in the other case, as well as if you don’t leave a number and let it time out 3 times. In both failed cases it jumps to priority +101. (The strange thing is if I hangup at that point (as well as answer and then hangup) the call ends up continuing into my IVR. (But I don’t think that is related to the Privacy Manager - and I haven’t investigated it enough to understnad why?)
Hmm - looks like there is a bug in the Asterisk code in the way they are handling it. It’s late so I’m not thinking straight right now - but it appears they are waiting for either a # or the number of digits the buffer they passed in can hold (30) vs. the length of the phone number. And in either case, when a timeout is detected, they are not checking to see if adequate digits arrived, they are just bagging out. When my mind has rested I’ll re-visit this to confirm so we can get this fixed.
In the mean time - I still don’t understand why on exit, if the Privacy Manager fails and I send the call to a +101 priority (where it correclty goes) and do a hangup (which is executed a the CLI), why it picks right back up and keeps going?
thanks for any insight into the last point. (Maybe I’m just tired?)
OK,
this bug was originally reported by dswartz:
0006641
there is a proposed fix in the bug report that although I do not think it is correct but have posted what I think is the correct fix in the same bug report. (We can discuss it there to resolve the right fix).
OK - I was up too late, after looking again I think the first proposed fix is fine as well. (Sorry dswartz - I need to get some rest:))
p
HOWEVER - The saga continues:
Well,
one thing fixed and the next broken. The fix mentioned here works. However I’m having another problem that I’m wondering if anyone ran into:
Calls are coming in on PRI, if the call comes in with CID, all is good as PrivacyManager lets it go and the SIP INVITE to the phone includes the CID in the form.
However, if the call comes in blocked (*67), Privacy Manager gets the CID input and all is kind of fine. The CLI/logs show the proper caller id, they are posted in the CDR, you can see them when dialparties is being called, etc. HOWEVER- the SIP INVITES always go out as from ‘unknown’ no matter what. I can even do the following:
- Call Privacy Manager
- Hard Code a new Caller ID
- Let it continue
when the call comes in with a CID, the sip invite includes the hardcoded (and different) CID. When the call comes in blocked (*67) the SIP INVITE goes out with ‘unknown’ as the caller. So … something in the channel is being set that is confusing the SIP INVITE to go out as unknown? Any one else experience this? (Or not experience it - on PRI lines coming in going out to SIP extensions?). I’m running 1.2.5 for this test.
p
p.s. I also instrumented app_privacy.c to set the ani as well as comparing it on cid vs. blocked calls to see if there were differentces. Nothing is making a difference!
Fixed - PRI lines set the CallerPres variable which is never changed by the privacy manager. So although the caller id is present, the SIP channel honors the setting and does not pass it on. The privacy manager should change this to allowed_passed_screen (or something similar) which is 1. Patching the application with this fixes the problem.